"Darryl Miles" <[EMAIL PROTECTED]> wrote in message
news:[EMAIL PROTECTED]
> Michael Decker wrote:
>>>> My problem is, that the application session (set by cookie or url
>>>> parameter) is not associated with the SSL session. And I hope, there is
>>>> an easy way to that.
>>> I dont understand why you want to connect to two (under my definition of
>>> each explained above).
>>
>> Why I want that? If you've an application with session. So you can get
>> the application information by spying (XSS, browser plugin etc.) or
>> copying (URL with session ID).
>>
>> Because of that the idea was to join SSL session id and application
>> session id, you can avoid that.
>
> Understood on what you are trying to do now. Maybe:
> http://java.sun.com/products/servlet/2.1/api/javax.servlet.ServletRequest.html
>
> and :
>
> javax.net.ssl.SSLSession sslSession = (javax.net.ssl.SSLSession)
> request.getAttribute("javax.net.ssl.session");
> byte[] sslId = sslSession.getId()
>
> Will do the trick.
>
Actually, no. This will just result in an NPE :). And, if you think about
it, if Apache is handling the SSL traffic, then there would be no way to get
this.
What does work is:
String sslid =
(String)request.getAttribute("javax.servlet.request.ssl_session");
This will give you the SSL Session-ID even if you are fronting with Apache
(Apache passes it to Tomcat). However, be warned that this is a
Tomcat-specific feature: It won't work if you try and port your app to
another Servlet Container.
>
> Before all HttpSession object usage you want to validate it, maybe a
> Servlet Filter would be a good way to handle this.
> http://java.sun.com/products/servlet/Filters.html
>
>
> The AJP protocol seamlessly conveys the SSL related information between
> apache and tomcat. Although apache+mod_ssl is the SSL endpoint, the
> web-app still have access to it just as-if you had setup SSL on tomcat
> directly.
>
>
>
>>> It is not normal to connect the SSL session in
>>> this way, as the HTTP protocol may (or may not) use the same SSL session
>>> details during the next request, the client may (or may not) support
>>> persistent connections. The SSL session cache is a performance
>>> optimization, not something an application gets to see or use directly.
>>
>> I'm not sure if I completely understand you: The SSL session (ID) can
>> change between two requests?
>
> HTTP is a stateless protocol. So from a pure HTTP perspective, yes sure
> the ID can change between requests. In practice with featurefull browsers
> and a normal usage pattern linking them is probably safe you'll have to
> test with your userbase to be sure.
>
>
> Darryl
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
