struts-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Max Cooper <>
Subject Re: container-managed security and struts
Date Wed, 12 Oct 2005 23:40:25 GMT
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:

and then the app redirects the user to:

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.


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
> "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:
For additional commands, e-mail:

View raw message