Eoin Curran wrote:
> The cookies used to track sessions disappear once the browser is closed (For
> Jrun, anyway). So If you need to use a cookie to recognize a user returning
> to your site, this solution will not work.
>
> It is a nice way to work things though. Maybe the way that the session
> variable works (implementation not specified) could be extended to a
> long-living session type object. Then the details of how the cookies are
> used could be implemented by the servlet engine?
>
> Or maybe that's taking the abstraction too far?
It sounds like you don't need to track a *session* across browser invocations,
but rather a way to track *user identity*. If the server is using URL
rewriting, there's no way for the object to persist -- this newer
user-identity tracking has to use cookies. The fact that extending the
session might work seems more related to the implementation of session,
rather than its semantic meaning.
User identity is often secure via various methods, too, so cookies aren't
the only way to go to achieve the required level of persistence.
-Dave
===========================================================================
To unsubscribe: mailto [EMAIL PROTECTED] with body: "signoff JSP-INTEREST".
FAQs on JSP can be found at:
http://java.sun.com/products/jsp/faq.html
http://www.esperanto.org.nz/jsp/jspfaq.html
