Forum Discussion
NimbostratusHTTPS redirects for specific pages only
We have several sites that require HTTPS redirects for only specific pages. Here's an example of the iRule we've applied to the HTTP VS to perform the redirect for the specified pages:
when HTTP_REQUEST { if { [class match [string tolower [HTTP::uri]] starts_with secured_uris] } { HTTP::redirect "https://[HTTP::host][HTTP::uri]" } }
The data group "secured_uris" defines the various pages that need to be redirected (i.e. /admin/login.aspx). This is working to a point. After any of the pages are redirected to HTTPS then all subsequent requests are HTTPS, even if the URI isn't in the "secured_uris" data group list. So we created a 2nd iRule and applied it to the HTTPS VS:
when HTTP_REQUEST { if { not [class match [string tolower [HTTP::uri]] starts_with secured_uris] } { HTTP::redirect "http://[HTTP::host][HTTP::uri]" } }
However, now we're getting back a warning in IE about displaying "insecure content". I've found a few references to using Stream profiles to help prevent the mixed content but not sure how to implement this. Any help would be greatly appreciated.
Thanks!
2 Replies
Hi Jason, the stream profile can help if you have http or https links in the wrong location. (For example. You are on a HTTPS site and the links on the page are to HTTP resources where it should be HTTP). Is this the problem you are seeing?
More info on Stream profiles here as a FYI.
- Kevin_Stewart
Employee
You're going go get this "insecure content" warning in many browsers when you try to access HTTP content where the browser believes it should only be talking HTTPS. It could be as simple as page object references (images, JavaScript, CSS, etc.) getting redirected to HTTP because they don't meet your "secured_uris" requirements. You can observe this behavior from a client side inspection tool like Fiddler or HTTPWatch. Or the browser could actually be choking on the back-and-forth flipping. In any case, this is a browser behavior, and not something you can specifically control with an iRule, other than to try to avoid it. Depending on what you see in your captures, you may need to expand your "secured_uris" list to contain page object references, or simply stay in HTTPS once the user has gone there. One might argue that if you're going to HTTPS to authenticate and then flipping back to HTTP for everything else, you're probably also exposing the authenticated session token (a cookie generated during the logon process to indicate the client's authenticated state) to unencrypted analysis (if that is how you maintain session state).
