Closed GoogleCodeExporter closed 8 years ago
I forgot to add that we have the SSL certificate installed on the load
balancer. I've also tried baseInsecureUri etc parameters as well
Original comment by vamich...@gmail.com
on 20 Dec 2012 at 10:14
Hi. Make sure you set offloadedSecurityHeaders to match any request header
Rackspace is sending from the LB. Also, if the URL does not get modified by the
LB (other than the lack of HTTPS), you shouldn't need to set the base Uris. If
the port is changed by the LB, you'll need to set both base Uris.
Let me know and I'll gladly help with a little more info.
-Matt
Original comment by vent...@gmail.com
on 20 Dec 2012 at 10:43
How can I discover these request headers from the LB? I admit, I'm not that
familiar with LBs in general
Original comment by vamich...@gmail.com
on 20 Dec 2012 at 11:18
You will likely need to contact/search Rackspace to find out what the header is
and it's value to indicate SSL. A quick search on their site shows the
following for cloud hosting.
"Rackspace Cloud Load Balancers pass a header value to determine the original
protocol used by the request (HTTP / HTTPS). This header is labeled
X_FORWARDED_PROTO. Its value will either be “http” or “https”."
Reference here:
http://www.rackspace.com/knowledge_center/article/configuring-load-balanced-site
s-with-ssl-offloading-using-iis
If the above is accurate for your hosting setup, you'll want to change the
offloadedSecurityHeaders attribute to "X_FORWARDED_PROTO=https".
Original comment by vent...@gmail.com
on 21 Dec 2012 at 1:27
I contacted them and they confirmed that the attribute you specified is
correct. Still getting an endless loop. I'm not sure if it is related, but
when I browse to pages other than Default.aspx, those get served in https or
http accordingly, so it appears that switching isn't working for the pages that
should be unsecured.
Original comment by vamich...@gmail.com
on 21 Dec 2012 at 5:10
There is a chance that another resource on the page is causing the infinite
redirect. Does Default.aspx have local CSS or images on it that may be getting
caught up in the loop?
These types of scenarios are really hard to troubleshoot, however there are
some things you can do. I suggest disabling this module and adding some code of
your own to the page as a quick way to test the state of things.
First, I would write out the request header to verify it is present, then visit
the page from your browser with HTTP and HTTPS manually. Make sure the header
is properly working. For example,
Response.Write(Request.Headers["X_FORWARDED_PROTO"]).
If that appears to be working properly from your manual tests, I would then
attempt to code a very basic redirect on the page. For example (C# and forgive
any compile errors, as I'm writing this inline):
public void Page_Load(object sender, EventArgs args) {
string headerValue = Request.Headers["X_FORWARDED_PROTO"];
if (headerValue == null || headerValue != "https") {
Response.Redirect("https://www.yoursite.com/Default.aspx");
}
}
Remember, disable this module before any of the above tests to ensure it's not
conflicting with your test code.
Original comment by vent...@gmail.com
on 22 Dec 2012 at 1:21
Got it! Turns out the request header is case sensitive. I figured this out by
creating a new test project and adding this to my pages.
Protected Sub Page_Load(ByVal sender As Object, ByVal e As System.EventArgs) Handles Me.Load
Response.Cache.SetCacheability(HttpCacheability.NoCache)
txtHeaders.Text = ""
For Each s As String In Request.Headers
txtHeaders.Text = txtHeaders.Text & String.Format("{0}:{1}", s, Request.Headers(s)) & vbCrLf
Next
End Sub
This showed me all of the headers and the values. Thanks again!
Original comment by vamich...@gmail.com
on 22 Dec 2012 at 5:20
That is great! I'm very glad you got it worked out.
I'm thinking of adding some common headers for popular hosting providers as a
wiki page. Would you please share what the case-sensitive value actually turned
out to be (i.e., "HTTPS", "Https")?
Original comment by vent...@gmail.com
on 22 Dec 2012 at 8:46
[deleted comment]
<securitySwitch mode="RemoteOnly"
offloadedSecurityHeaders="X-Forwarded-Proto=https" bypassSecurityWarning="true">
I discovered the problem by printing out the acutal headers used:
Protected Sub Page_Load(ByVal sender As Object, ByVal e As System.EventArgs) Handles Me.Load
Dim headers As String = ""
For Each s As String In Request.Headers
headers = txtHeaders.Text & String.Format("{0}:{1}", s, Request.Headers(s)) & vbCrLf
Next
Response.Write(headers)
End Sub
Original comment by vamich...@gmail.com
on 24 Dec 2012 at 2:32
Thanks for taking the time to verify the actual header value. I appreciate it!
Original comment by vent...@gmail.com
on 24 Dec 2012 at 3:10
Original issue reported on code.google.com by
vamich...@gmail.com
on 20 Dec 2012 at 10:09