Alan P. Sexton asks:
> Jason Hunter's 2nd edition book, when talking about session IDs,
> mentions (page 221) that "Other implementations, like using SSL (Secure
> Sockets Layer) sessions, are also possible". I cannot find any other
> reference to doing so.
I haven't seen any either.
> Can anyone explain, or even better, point me at references to, what one
> has to do to use SSL sessions (other than run SSL of course) from
> servlets running in Tomcat 4.0 with Apache?
I'm personally very curious about the SSL session-ID based stuff.
But, to clear up a misconception:
At the servlet level there's nothing you need to do to use SSL -
except, maybe, add code to your doGet (or preferably to a servlet spec
2.3 Filter) to check and make sure the user is actually using SSL
(look at the HttpServletRequest api docs for the methods to check
this). However, whatever servlet engine you're using has to have the
SSL support enabled. I'm not sure what Jakarta Tomcat uses, as I
haven't really worked with SSL under Jakarta Tomcat. In the various
commercial servlet engines I've worked with, SSL support comes
bundled.
However, with a little google search on "jakarta tomcat ssl", I
suspect that:
http://jakarta.apache.org/tomcat/tomcat-4.0-doc/ssl-howto.html
might shed some light on the topic :-).
> I assume that using SSL sessions obviates the need for cookie/url
> rewriting/hidden field session handling. Is this true?
Part of the servlet engine's job is to hide all of that from you.
Realistically, it can't really completely hide the URL rewriting
stuff, since to support that, you need to make sure you pump any URLs
in your outgoing pages through the URL-rewriter. However, what Jason
is (I think) talking about is the fact that the SSL session itself has
some continuity built into it, in the form of an SSL-level session
key. Therefore, logically, during an SSL session the servlet engine
could quite easily use this key to support the servlet session.
> Are there any constraints to their use other than the usual when
> running standard sessions?
Not as far as I know.
> What happens when invalidating a session if it is an SSL session? etc.
Again, as far as I know, nothing different. Other than
a) enabling the SSL server (which usually runs on port 443) and
b) starting all your URLs with "https://"; instead of "http://"; and
c) checking to make sure the request came in via SSL (which you
don't *need* to do, but if you've bothered to use SSL you
probably want to make sure the user doesn't accidentally
somehow submit an un-secure request),
...you can just ignore the SSL aspect entirely.
Steven J. Owens
[EMAIL PROTECTED]
___________________________________________________________________________
To unsubscribe, send email to [EMAIL PROTECTED] and include in the body
of the message "signoff SERVLET-INTEREST".
Archives: http://archives.java.sun.com/archives/servlet-interest.html
Resources: http://java.sun.com/products/servlet/external-resources.html
LISTSERV Help: http://www.lsoft.com/manuals/user/user.html
