My memory of all this stuff is a bit foggy, and some of this is just plain speculative, so this post is sort of general (and maybe even wrong in some spots ;-) -- but I hope it might have some value in guiding you toward a solution...
Some browsers (somewhat correctly, though somewhat annoyingly) consider the port number when deciding which cookies to send with a request. So, if your browser gets a session cookie from: server.domain.com:80 and then the app redirects the user to: server.domain.com:443 the browser may choose to not send the session cookie that it got from the server listening to port 80 with the request it makes to port 443. This makes some sense, since there could be completely different and unrelated servers listening to these two different ports. (This seems more likely with ports 7001 and 8080, for example, than it does with 80 and 443, but having special cases for specific port numbers would be even more befuddling.) However, while the "different servers" case is technically possible, the far more common case is that it is one server listening to both ports. I'm torn on what the correct default behavior should be, but it seems clear that you should be able to configure your way toward the behavior you want, whatever the case. For all I know, there *is* a correct answer to what the browser behavior should be, but I don't know what it is. What the app server does for the session cookie cookie domain is the other half of this, and I am not sure if there is a *right* answer for this or not, either. I forget which browsers are picky about the ports when dealing with cookies. I think old Netscape was picky. SSLEXT has some support to avoid this cookie problem by writing the session id into the redirect URL. It may also be possible to override the cookie domain used by your app server to resolve this. Be wary of configuring an explicit cookie domain, however, since it adds the burden of actively making this config change on all your servers, might cause issues with load balancers or web server proxies, could be a pain as you move from dev to qa to prod, etc. I am not entirely sure about this, but one of these might be true: 1) if the cookie does not have an explicit cookie domain specified (watch the HTTP traffic or inspect your browser cookie jar to inspect), the browser might construct it's own and include the port number, in which case you might be able to fix this issue by explicitly setting a cookie domain for the session cookie (a server config option?) 2) the app server might be explicitly specifying a cookie domain that includes the port number (can a cookie domain really include a port number? I'm not sure), in which case you might be able to configure the cookie domain to omit the port number 3) the app server might supply a cookie domain without the port number, but the browser is intent on adding the port number no matter what you do, which seems to leave putting the session id in the redirect URL as the only option It may also be some kind of security feature for the server to not allow non-SSL access to a session that was created (or was transitioned) to be in use by a user via SSL. The idea behind this choice might be that stuff that a user puts in their session while connected with a secure connection should not be available without a secure connection. My first impression is that this is a weird policy, but it might make sense to someone (maybe even me if I considered it more thoroughly, but I doubt it). If this is the case, perhaps this feature can be disabled in the server config. -Max On Wed, 2005-10-12 at 18:22 -0400, Dave Newton wrote: > Adam Hardy wrote: > > > I tried this 18 months ago and if my memory serves me well, in tomcat > > 5, if I switch the request back out of SSL with a redirect or similar, > > I can no longer see the SSL session (and am effectively not logged in > > anymore). > > > > Is there an easy way around this? A javascript encryption routine for > > the password or some trick with ssl-ext? > > <plug-in className="org.apache.struts.action.SecurePlugIn"> > <set-property property="httpPort" value="8080"/> > <set-property property="httpsPort" value="8443"/> > <set-property property="enable" value="true"/> > <set-property property="addSession" value="false"/> > </plug-in> > > From sslext.sourceforge.net: > > "Also added is the ability to configure the "always add Session ID to > URL feature". This feature was added in a previous release to compensate > for older browsers that do not automatically share sessions between the > http and https protocols. If you are sure that this problem will not > exist for you, you can now disable this feature through the "addSession" > property of the SecurePlugIn (or SecureTilesPlugin). Thanks to all who > suggested this enhancement. (Or otherwise complained about the old > behavior :-)." > > Dave > --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
