RE: svn commit: r733748 - in /tomcat/trunk: java/org/apache/catalina/ java/org/apache/catalina/connector/ java/org/apache/catalina/core/ java/org/apache/catalina/ha/session/ java/org/apache/catalina/session/ java/org/apache/coyote/ java/org/apache/coyote/

[Mark Thomas <ma...@apache.org>]

> From: Filip Hanik - Dev Lists [mailto:devlists@hanik.com]
> 
> 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.

> 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.

> 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.

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.

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: dev-unsubscribe@tomcat.apache.org
For additional commands, e-mail: dev-help@tomcat.apache.org

Re: svn commit: r733748 - in /tomcat/trunk: java/org/apache/catalina/ java/org/apache/catalina/connector/ java/org/apache/catalina/core/ java/org/apache/catalina/ha/session/ java/org/apache/catalina/session/ java/org/apache/coyote/ java/org/apache/coyote/

[Filip Hanik - Dev Lists <de...@hanik.com>]

Mark Thomas wrote:
>> From: Filip Hanik - Dev Lists [mailto:devlists@hanik.com]
>>
>> 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: dev-unsubscribe@tomcat.apache.org
> For additional commands, e-mail: dev-help@tomcat.apache.org
>
>
>   


---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@tomcat.apache.org
For additional commands, e-mail: dev-help@tomcat.apache.org