Forum Discussion
NimbostratusHTTPS redirect looping
I have a virtual server on port 80 with this iRule attached:
when HTTP_REQUEST {
if {[string tolower [HTTP::host]] eq "e1loginl"}{
HTTP::redirect "https://e1login/jde/E1Menu.maf"
} }
And another port 443 virtual server with the same IP address to get the redirected page. The login page comes up just fine but if the user tries logging in, they get redirected right back to the login page where they started. Like the request just gets looped back. If I use Firefox and look at the Web Developer console while I do this I see that the browser is presented with a 302 found message. I also see this:
POST http://e1plogin/jde/E1Menu.maf GET https://e1login/jde/E1Menu.maf
I don't understand the http post. Any assistance would be most helpful.
3 Replies
Cory_50405Noctilucent
The POST is probably for the user submitting credentials to login. The login may have been successful, but the subsequent HTTP request likely contains the specified host, so the redirection back to the login page happens.
Perhaps on your 80 virtual server, just apply the standard HTTP to HTTPS redirect iRule built into the LTM (_sys_https_redirect) and then keep your iRule above applied only to your 443 virtual server.
If this doesn't change the behavior, then the iRule logic will need modified depending on what the server does after authentication.
aspindler34_133Your Findings are accurate. What does the URI look like after the user authenticates? does it change? I'm assuming so since its being redirected back to your https string. After login, does the URI start with "e1login"?
The reason I'm asking is because once the traffic gets back to the host and is sent to the VIP again the Irule is processed again, and it would appear that rule is redirecting it. I am still fairly new to irules myself but look at using something other than eq for that match logic. In your logic you are saying as long as "e1login" comes directly after the host then redirect.
hope this helps in some way.
- aspindler34_133
another thing you could probably try is doing a tcpdump from the F5 while a user trys to authenticate. To see whether or not its the server doing the redirection. Is this problem observed when you bypass the F5 and auth directly against the server?
