tag:support.appharbor.com,2010-11-23:/discussions/problems/80009-redirect-loopAppHarbor: Discussion 2016-02-03T04:12:10Ztag:support.appharbor.com,2010-11-23:Comment/387684472015-12-24T11:03:48Z2015-12-24T11:03:48ZRedirect loop<div><p>Hi Fidel,</p>
<p>I tried accessing your application using both HTTP and HTTPS and
didn't see any redirect loops in the process. Is this issue related
to a particular endpoint for your application, or did you resolve
the issue in the meantime?</p>
<p>Best,<br>
Rune</p></div>runetag:support.appharbor.com,2010-11-23:Comment/387684472015-12-24T12:36:40Z2015-12-24T12:36:40ZRedirect loop<div><p>Hi Rune,<br>
Thanks for coming to the rescue again. The redirect loop issue
occurs when I try to sign in and access the Admin panel. So<br>
shundagos.apphb.com/admin<a href="http://shundagos.apphb.com/admin">http://shundagos.apphb.com/admin</a><br>
gives a redirect loop<br>
Fidel</p></div>upaelfidtag:support.appharbor.com,2010-11-23:Comment/387684472015-12-25T11:42:08Z2015-12-25T11:45:00ZRedirect loop<div><p>Hi,</p>
<p>Ok got it - it looks like the "custom"
<code>RequireHttpsAttribute</code> filter is never invoked, but I
wasn't able to inspect your code as the application seems to be
prebuilt. I'd need to see a bit more code than the screenshot you
sent above to determine what the cause is. However you may want to
verify the following:</p>
<ul>
<li>The code in the screenshot references the
<code>RequireHttpsAttribute</code> - is this the default attribute
included in MVC? I'm asking since the code that follows contain the
code that handles the <code>X-Forwarded-Proto</code> header, but we
usually recommend creating a <a href="https://gist.github.com/runesoerensen/915869">custom
<code>RequireHttpsAttribute</code> class as in this
example</a>.</li>
<li>If it is the default MVC attribute rather than the custom one
it'd be great if you could verify that this code is actually
executed. You could for instance confirm this <a href="https://blog.appharbor.com/2014/01/23/introducing-trace-logging">by
enabling and writing a trace log message</a> and observe the output
in the log viewer when accessing the page that causes a redirect
loop.</li>
<li>If you're using the custom <code>RequireHttpsAttribute</code>
I'd recommend verifying that this is also the one that is used in
the controllers that require HTTPS to rule out a potential type
mismatch that'd cause you type comparison to fail.</li>
</ul>
<p>By the way, you may <a href="http://www.davidhayden.me/blog/filter-overrides-in-asp-net-mvc-5">find
this blog post on filter overrides in MVC5 (and Orchard 1.8)</a> -
this might actually be a more elegant solution altogether, and it
looks like you're already using MVC 5 (not sure about the Orchard
version) so upgrading and implementing such an override may be a
better approach.</p>
<p>Let me know what you think and if any of this helps
address/isolate the issue.</p>
<p>Best,<br>
Rune</p></div>runetag:support.appharbor.com,2010-11-23:Comment/387684472015-12-25T18:28:12Z2015-12-25T18:28:12ZRedirect loop<div><p>Hi Rune,<br>
Thank you so much for the pointers. This should give me plenty to
look at.<br>
Fidel</p></div>upaelfidtag:support.appharbor.com,2010-11-23:Comment/387684472016-01-08T00:55:55Z2016-01-08T00:56:28ZRedirect loop<div><p>Having the same problem and trying <a href="https://gist.github.com/runesoerensen/915869">https://gist.github.com/runesoerensen/915869</a></p>
<p>Can we trust <a href="https://gist.github.com/runesoerensen/915869#file-requirehttpsattribute-cs-L23">
https://gist.github.com/runesoerensen/915869#file-requirehttpsattri...</a>
to work? What if someone forms a non-SSL request and adds the
header <code>X-Forwarded-Proto:https</code> ? Will that fool this
<code>RequireHttpsAttribute</code> into thinking that the load
balancer has approved this request thus bypassing the 301 to HTTPS
?</p></div>mkocajtag:support.appharbor.com,2010-11-23:Comment/387684472016-01-08T16:05:00Z2016-01-08T16:05:00ZRedirect loop<div><p>Hi,</p>
<p>Yep you can trust it to work :-) It doesn't matter if the
client's request contain the <code>X-Forwarded-Proto</code> header
and the value your application will receive will always be the
protocol used to connect to the load balancer.</p>
<p>Even if a client was able to overwrite the value by setting a
<code>X-Forwarded-Proto: https</code> header I wouldn't be
concerned about it. Mostly because no browsers do that by default,
and the client would only be fooling itself into making an
unencrypted request by doing so.</p>
<p>Best,<br>
Rune</p></div>runetag:support.appharbor.com,2010-11-23:Comment/387684472016-02-01T09:27:16Z2016-02-01T09:27:16ZRedirect loop<div><p>Thanks Rune.</p>
<p>If folks are using Owin, feel free to use this <a href="https://github.com/cottsak/DevCookie/blob/master/DevCookie.Web/App_Start/RedirectToHttpsHelper.cs">
https://github.com/cottsak/DevCookie/blob/master/DevCookie.Web/App_...</a>
by sticking <code>app.RedirectToHttps("ssl-port",
supportSslOffloading: true);</code> in your
<code>Startup.cs</code>.</p></div>mkocajtag:support.appharbor.com,2010-11-23:Comment/387684472016-02-03T04:12:08Z2016-02-03T04:12:08ZRedirect loop<div><p>Hi,</p>
<p>Thanks for sharing your solution! You might also want to take a
look <a href="https://gist.github.com/runesoerensen/921bf766b76d7573fcd4">at
this Owin middleware</a>, which doesn't do the same thing but makes
sure that the application recognizes secure connections in your
local and AppHarbor's environment.</p>
<p>Best,<br>
Rune</p></div>rune