Nov. 24, 2010, 09:58 AM
i've bumped into a half-ssl situation where the logout process lands on a 302 that redirects itself to a NON-half-ssl site...
here's the (modified) code for that landed-on 302...
in my half-ssl session, i click the site's (original) logout "button", the process lands on this 302, and it "jumps me out of" half-ssl (and the insuing nag screen when the browser hits an http s :// and thus the very reason i half-ssl to begin with, to avoid them d@&n nags, lol)...
i've fixed "my" problem by writing a filter that replaces the "original" logout 'button' with a half-ssl link that points to where the 302 was non-halving to...
but the question herein is this, "should we rewrite the half-ssl filters so that they "catch" 302 redirects?" (or do they already and my above scenario is a "one-off" rarity?)
here's the (modified) code for that landed-on 302...
Code:
<html><head>
<title>302 Found</title>
</head><body>
<h1>Found</h1>
<p>The document has moved <a href="https://www.insurance.com/WebMdLogOut/logout.html">here</a>.
</p>
</body></html>in my half-ssl session, i click the site's (original) logout "button", the process lands on this 302, and it "jumps me out of" half-ssl (and the insuing nag screen when the browser hits an http s :// and thus the very reason i half-ssl to begin with, to avoid them d@&n nags, lol)...
i've fixed "my" problem by writing a filter that replaces the "original" logout 'button' with a half-ssl link that points to where the 302 was non-halving to...
but the question herein is this, "should we rewrite the half-ssl filters so that they "catch" 302 redirects?" (or do they already and my above scenario is a "one-off" rarity?)