"[David Griffin]" wrote:
> I am still I guess a bit confused about what a session is.
>
> The Servlet docs say "The server can maintain a session either by using
> cookies or by rewriting URLs."
>
> Is that for me to choose ? Or does that simply vary from engine to engine ?
Generally, the servlet engine will try cookies first, and fall back to URL
rewriting if that doesn't work. Some servlet engines let you configure the
mechanisms used (in effect forcing one or the other).
>
> And if it uses cookies, is that still hidden from me ? Do I treat it simply
> as a Session and not worry about the implementation ? Or does that actually
> mean "with this engine you are forced to do it yourself with cookies"
>
>From the application perspective, there is something you MUST do and something
you SHOULD do:
* In your doGet() or doPost() method, you MUST call one of the
request.getSession() methods if you want to maintain session
identity across this request (normally you do).
* When you are creating your HTML output, you SHOULD surround
any hyperlink URL with a call to response.encodeURL() like this:
PrintWriter writer = response.getWriter();
...
writer.println("<a href=\"" +
response.encodeURL("/next/page") +
"\">Next Page</a>");
If you do not do this, session state will still be maintained for you
if cookies are used, but not if URL rewriting is used. (If cookies
are being used, the URL is returned unmodified by this call.)
>
> When I try and get my head round how a non-cookie session persists, all I
> can think is that the server remembers the IP address or similar and if a
> user at the same IP address comes back within a certain period, it's
> regarded as the same session.
Saving the IP address is not sufficient. Consider that a multiuser Unix system
might have lots of users. And everyone coming from "aol.com" looks like they
are coming from the address of one of AOL's proxy servers.
What really happens is that the URL is modified to include the session ID. For
example, the HTML generated by the example above might look like this in the
rendered page:
<a href="/next/page;SESSIONID=fdafdajfdkahgyd'sauy8">Next Page</a>
Because the session ID is part of the hyperlink, it is sent back to the servlet
engine when you click the link. The servlet engine can rip it off the URL and
use it to look up the correct session information. If you want to experiment,
just turn off cookies in your browser and use one of the example servlets that
uses sessions -- you can see exactly what the URLs look like by hovering the
mouse over the generated links.
>
> Unless
> - a preagreed time period elapses
> - the servlet chooses to invalidate the session
>
These two caveats are true no matter which mechanism is used -- cookies or URL
rewriting.
>
> But if this was true it wouldn't matter a fig if the user visited 10 other
> pages on other sites in the meantime, as long as they came back within the
> timeout period, with the same IP address.
>
See above -- it is not based on IP address.
If you are using URL rewriting, how the user comes back is important -- if they
just type in a page URL (without a session id), they will be coming in with no
session ID -- your servlet will not recognize the request as part of the same
session, even if it was within the timeout interval. This is one of the many
reasons to encourage your users to enable cookies, where you don't have to worry
about it.
>
> Or is the URL of the page from which the visitor linked to the servlet
> somehow part of the story too ?
>
Nope. It's all in the URL (if rewriting) or the cookie (sent automatically to
the site when you return).
>
> Relying on the timeout period worries me a bit, as a legit (but slow
> reading) visitor could lose their session through inactivity, while a
> subsequent user in an internet cafe could use the session of a legit user
> who has walked off. I guess that's why "logging out" is so important on
> some pages.
>
Yes, both concerns are legitimate.
The reason it's an issue at all is based on the way HTTP works. While you are
reading through a page, there is no live connection between your browser and the
server you got that page from. You can shut down the browser, or reboot your
PC, and the server would never know. That's why timeouts were created.
It's also why logging out is a good idea. If I ever logged in to a
session-managed site from an Internet cafe, I would always do the logoff
procedure for that site, AND shut down the browser (because session cookies are
usually configured to be thrown away when the browser exits). Even then, you've
got to hope that the server application developer programmed it right, and that
nobody has a keyboard interceptor or other booby trap in the cafe's PCs.
Craig McClanahan
___________________________________________________________________________
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
