I've got a custom subdomain that, when using Java's HttpServletResponse::sendRedirect() is getting redirected to our main (sub)domain and I'm not sure why. Users at https:// custom.example.com/originUrl/SignOnPage get redirected to https:// main.example.com/requestedUrl/GoToReporting where they don't have a session and are logged out.
My question:
When using both an F5 and apache mod_rewrite and/or mod_proxy, where should subdomain handling, redirection, and/or SSL configurations be managed? Without explicitly writing/removing configurations specific to subdomains, what change(s) would likely cause this to stop working?
Details:
My current theory is that what caused this redirect to stop working was something SSL/HTTPS/HSTS related, likely in the F5. According to the link below, sendRedirect() causes HTTPS to become HTTP, and it appears that when this happens, the HTTP connection gets re-established at the "primary" domain.
I don't have access to the F5 configuration, and I know very little about it.
The department managing the F5 insists that nothing changed in the F5 and that anything affecting this redirection must be caused by java code or apache changes and needs to be solved through those means. I think they're wrong. Please help clarify.
In Apache, we're using mod_proxy, mod_rewrite, and several other modules that could affect this, but there are no references to any (sub)domain names in any apache config files. However, I tried anyway to implementing RewriteConds and RewriteRules to prevent subdomains from changing, but this didn't have any affect (I was probably doing something wrong... the [P] / [R,L] stuff is confusing, and I'm 95% sure nothing changed around this).
The Java code is not the issue. Nothing in the Java code changed (arond this or affecting this, verified by testing a year-old build). But I can easily solve the problem at hand in Java (see Alternative Solutions below).
Details and Diagnostics:
The browser sees:
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
When a request originating from https:// custom.example.com/originUrl/SignOnPage performs a window.location.href = "/requestedUrl/GoToReporting", the request hits the HttpServlet in the java app and it contains the following:
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
Notes:
For my example, I've replaced the domain names as follows:
main.example.com is the primary landing page for most clients
custom.example.com is the landing page that is specific to a particular client
The GoToReporting page does a SendRedirect("http://main.example .com/Reporting")
I put spaces in the example URLs because I can't have more than 8 links... They're not real links...
Alternative solutions:
One "solution" to the problem would be to chop the referer from the request via Regex and append the request uri manually, but this is wrong and bad for several reasons. The request URL is already wrong by the time it hits Java.
Another approach could be to modify the java code to not use sendRedirect(). This works for my current situation, but we do have other places that use sendRedirect() that will need solved for, preferably not through Java.
Further reading / references:
http://www.knowledgefolders.com/akc/display?url=DisplayNoteMpURL&reportId=1711&ownerUserId=satya
No comments:
Post a Comment