У меня есть собственный поддомен, который при использовании Java HttpServletResponse :: sendRedirect () перенаправляется на наш основной (под) домен, и я не уверен, почему. Пользователи на https: // custom.example.com/originUrl/SignOnPage перенаправляются на https: // main.example.com/requestedUrl/GoToReporting, где у них нет сеанса и они выходят из системы.

Мой вопрос: при использовании как F5, так и apache mod_rewrite и / или mod_proxy, где следует управлять обработкой поддоменов, перенаправлением и / или конфигурациями SSL? Без явной записи / удаления конфигураций, специфичных для поддоменов, какие изменения могут привести к тому, что это перестанет работать?

Детали: Моя текущая теория заключается в том, что причиной того, что перенаправление перестало работать, было что-то связанное с SSL / HTTPS / HSTS, вероятно, в F5. Согласно приведенной ниже ссылке, sendRedirect () превращает HTTPS в HTTP, и, похоже, когда это происходит, HTTP-соединение восстанавливается в «основном» домене. У меня нет доступа к конфигурации F5, и я очень мало о ней знаю. Отдел, управляющий F5, настаивает на том, что в F5 ничего не изменилось и что все, что влияет на это перенаправление, должно быть вызвано изменениями кода Java или Apache и должно быть решено с помощью этих средств. Я думаю, они ошибаются. Помогите, пожалуйста, уточнить.

В Apache мы используем mod_proxy, mod_rewrite и несколько других модулей, которые могут повлиять на это, но нет ссылок на какие-либо (под) доменные имена в любых файлах конфигурации apache. Однако я все равно попытался реализовать RewriteConds и RewriteRules, чтобы предотвратить изменение поддоменов, но это не повлияло (я, вероятно, делал что-то не так ... материал [P] / [R, L] сбивает с толку, и я Уверен на 95%, что вокруг этого ничего не изменилось).

Проблема не в коде Java. Ничего в коде Java не изменилось (кроме этого или влияющих на это, проверено тестированием сборки годичной давности). Но я легко могу решить возникшую проблему на Java (см. Альтернативные решения ниже).

Подробности и диагностика: браузер видит:

General
Request URL: https:// custom.example.com/requested/url/GoToReporting
Request Method: GET
Status Code: 302 Moved Temporarily
Remote Address: 172.19.x.189:443
Referrer Policy: no-referrer-when-downgrade

Response Headers
Connection: Keep-Alive
Content-Length: 0
Content-Type: text/html; charset=UTF-8
Date: Tue, 27 Nov 2018 18:29:15 GMT Keep-Alive: timeout=15, max=97
Location: http:// main.example.com/Reporting
Set-Cookie: TS..01=.....dae9; Path=/
Strict-Transport-Security: max-age=16070400; includeSubDomains

Когда запрос, исходящий из https: // custom.example.com/originUrl/SignOnPage, выполняет window.location.href = "/ requestedUrl / GoToReporting", запрос попадает в HttpServlet в приложении Java и содержит следующее:

request url:http:// main.example.com/requestedUrl/GoToReporting request uri:/requestedUrl/GoToReporting
host: jbossappserver05:8080 referer: https:// custom.example.com/originUrl/SignOnPage

x-forwarded-for: 172.17.x.19, 172.19.x.6
x-forwarded-host: custom.example.com
x-forwarded-server: localhost
connection: Keep-Alive

Примечания: В моем примере я заменил доменные имена следующим образом: main.example.com - это основная целевая страница для большинства клиентов custom.example.com - это целевая страница, специфичная для конкретного клиента.

Страница GoToReporting выполняет SendRedirect (" http: //main.example .com / Reporting")

Я помещаю пробелы в URL-адреса примеров, потому что у меня не может быть больше 8 ссылок ... Это не настоящие ссылки ...

Альтернативные решения: одним из «решений» проблемы было бы исключить референт из запроса через Regex и добавить URI запроса вручную, но это неправильно и плохо по нескольким причинам. URL-адрес запроса уже неверен к тому моменту, когда он попадает в Java.

Другой подход может заключаться в изменении кода Java, чтобы не использовать sendRedirect (). Это работает для моей текущей ситуации, но у нас есть и другие места, которые используют sendRedirect (), которые нужно будет решить, желательно не через Java.

Дополнительная литература / ссылки: http://www.knowledgefolders.com/akc/display?url=DisplayNoteMpURL&reportId=1711&ownerUserId=satya

answer

When using both an F5 and apache mod_rewrite and/or mod_proxy, where should subdomain handling, redirection, and/or SSL configurations be managed?

Пока вы решите сделать это в одном месте, неважно где.

Моя личная рекомендация - это F5, так как обычно будет больше веб-серверов и серверов приложений, чем только Apache, и тогда все ваши политики будут согласованы, независимо от возможностей ваших внутренних серверов.