JEE-сессии для JavaScript-интерфейса, размещенного на другом сервере - PullRequest
Новая
       60

JEE-сессии для JavaScript-интерфейса, размещенного на другом сервере

0 голосов
/ 21 июня 2019

У меня возникают проблемы с структурированием моего бэкэнда Java JEE для обработки сессий (сервлеты JEE обслуживаются с tomcat)

Мой интерфейс находится на другом сервере, на котором нет Java, только HTML и JavaScript. JavaScript использует ajax для отправки имени пользователя и пароля на внутренний сервер, который создаст сеанс: 

   session = request.getSession();
   session.setAttribute("email", email);
   session.setAttribute("auth", "1");

Когда внешний интерфейс снова связывается с внутренним интерфейсом через javascript после аутентификации, Java не может найти созданный сеанс. Вот как я ищу сеансы после того, как для auth установлено значение 1: 

HttpSession session = request.getSession();
String auth = (String) session.getAttribute("auth");
if (auth == null || !auth.equals("1")) {
   session.invalidate();// destroy any session that they may have
   System.out.println("Invalid Session");
   JsonGenerator gen = Json.createGenerator(response.getWriter());
   gen.writeStartObject().write("status", "expired").writeNull("data")
   .write("message", "Your session has expired").writeEnd();
   gen.close();
   return;            
}

Все работает нормально, когда и передний и задний конец размещены на одном сервере с одним и тем же доменным именем. Но не тогда, когда интерфейс и сервер находятся на отдельных серверах с разными доменными именами. Как я должен структурировать это так, чтобы Java могла проверять, находится ли auth == 1, когда интерфейс связывается с ним?

Вот как я связываюсь с внутренним сервером с помощью Ajax: 

  post_url = 'http://backend.anotherserver.com/api/datapoint'
  $.ajax({
    url: post_url,
    timeout: 10000,
    method: 'POST',
    dataType: 'json',
    success: function (json) {
    if (json.status == 'success' && json.data) {
      // do something
    }
  })

Внешний и внутренний интерфейсы имеют разные доменные имена. После того, как я получу один рабочий интерфейс, я создам второй внешний интерфейс с другим доменным именем, а также третий, четвертый и т. Д. Все они будут использовать один и тот же внутренний интерфейс, и все внешние интерфейсы должны иметь возможность проходить проверку подлинности с помощью внутреннего интерфейса. , Я не хочу использовать oauth-сервер, это слишком много для меня, чтобы справиться прямо сейчас.

1 Ответ

0 голосов
/ 26 июня 2019

Если балансировка нагрузки является вашим требованием, то я думаю, что вы должны пересмотреть архитектуру вашего сервераФайлы внешнего интерфейса, то есть HTML, Javascript и изображения, все загружаются на клиентский компьютер, и именно здесь происходит фактическое выполнение этих файлов.Если у вас есть несколько серверов только для HTML и Javascript, то это избыточный ресурс, потому что эти серверы будут служить только для загрузки файлов HTML и Javascript.В случае, если вам нужно предоставить несколько источников загрузки для ваших файлов веб-интерфейса, вы можете использовать серверы CDN, и содержимое веб-интерфейса можно загрузить из этих источников.

Реальное действие всегда происходит на сервере Tomcat, гдевсе вызовы Ajax с клиентского компьютера приходят и сходятся, где выполнение серверного кода и обработка данных бэкэнда происходит на сервере.Поэтому вам следует подумать о предоставлении кластерных серверов Tomcat для обработки нагрузки.Затем сделайте сеанс закрепленным на этих кластерах Tomcat.Таким образом, это смешивание сеанса не происходит между запросами ваших пользователей.Хранилище сеансов уникально для домена или субдомена.Следовательно, обычно невозможно разделить сеанс между несколькими доменами или поддоменами.Если у вас кластеризованные серверы Tomcat, то липкий сеанс поможет вам избежать этой проблемы.Тогда, естественно, есть балансировщик нагрузки с обратным прокси-сервером для маркировки белым цветом.

Разделение кода внешнего интерфейса и внутреннего кода действительно должно быть реализовано с помощью хорошей архитектуры кодирования, а не предоставления различных серверов для файлов js и backend tomcat.Если у вас нет хорошей структуры кодирования, то даже если у вас есть разные серверы для js и бэкэнд-файлов, вы можете получить коды, переходящие от или между веб-интерфейсом и бэкэндом.

...