Mark Thomas wrote:
From: Filip Hanik - Dev Lists [mailto:[email protected]]
this implementation may ask for more than is warranted. I would -1
based
on for example
"javax.servlet.request.ssl_session_mgr";
shouldn't extensions be named differently, and not within the
javax.servlet namespace?
We already have custom extensions for SSL attributes in this namespace.
should we still continue down that route? I'm lenient either way, but
would have preferred to separate out the two.
SSLSessionManager.invalidateSession
> not sure why the SSL sessions should invalidated when a HttpSession
is invalidated. I should be able to continue my SSL session even after
I
invalidate my HttpSession
There have been a few requests on the users list for the ability to invalidate
the SSL session. I wanted to see what the code would look like. I'm not against
removing the SSL session invalidation part of this patch. The downside would be
the inability to invalidate the SSL Session, the plus would be simpler code and
the removal of some of the restrictions on when you could use SSL session
tracking.
Some clarification from the EG on what session.invalidate() means when using
SSL tracking would be helpful. The doc on this area is just what is in the
Javadoc and that doesn't really give any insight into the thinking that went on
behind this particualr change.
I can post that question to the EG for you. However, there is nothing
that ties HttpSession behavior to SSL session behavior. The idea is that
you simply use the SSL session Id instead of the JSESSIONID cookie. and
for that, you can get away with using the
javax.servlet.request.ssl_session_id.
This way you also allow mod_jk to work (httpd offload) and other ssl
accelerators that might pass the info to the SSLValve
also, there are so many changes for this, when in fact the request you
already have the SSL session ID in the request attribute
SSL session id -> javax.servlet.request.ssl_session_id of type
java.lang.String
why tracking sessions using SSL is part of the servlet spec, there are
probably many different ways of implementing it, and I think it could
be
simpler than this, so maybe its a good idea to discuss such changes on
the dev list first.
The simple solution, as you suggest, is just to use the SSL Session ID. I had
that working quite quickly with a much smaller patch.
That's what's required for implementation.
As I type and the more I think about this, it really does come down to what
session.invalidate() means when using SSL Session tracking. If you were using
cookies, then the session ID would be reused. That suggests it isn't necessary
to invalidate the SSL session. However, there is a demand from the user
community for this ability and I think it is a useful feature to have.
If there is a demand, and users deem the feature useful, it is still a
separate concern, and should probably be implemented separate all together.
SSL session tracking can be implemented very light weight, and very low
risk.
Filip
On reflection, I might have a way to invalidate the SSL session without all the
extra code. I'll do some testing and post the results.
Mark
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
