tomcat-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Andy Nuss" <andyn...@siebel.com>
Subject RE: webapps are useless toys?!
Date Sat, 16 Dec 2000 04:29:15 GMT
So assuming the site requires "single sign-on".  And that there are
several segmentations of the site, each of which could
be handled by a different web-app:

I'm getting the impression that I'm supposed to do some
kind of magic with the session cookie.  Is it necessary
to persist all of the session data, to be shared between
web-apps, in the database?  Or is there a trick for finding
the in-memory session data for another web-app?

What's the rationale behind this architecture?



-----Original Message-----
From: Charles Forsythe [mailto:forsythe@netvoice.net]
Sent: Friday, December 15, 2000 5:40 PM
To: tomcat-user@jakarta.apache.org
Subject: Re: webapps are useless toys?!


Andrew Oliver wrote: 
> From my perspective you should have a secure login.
> if your login is passed from a non-secure area to a
> secure area there's not really that much purpose in
> providing the security in the first place.

No argument, but who said anything about logging in?  Sessions can be
granted to anonymous clients.

> As for a "domain" type session that is another matter. 

To answer another poster's question, if you call
HttpRequest.getCookies(), you SHOULD find a cookie containing the value
returned by HttpSession.getId().  There's nothing stopping the Servlet
container from maintaining some sort of translation between the session
cookie value and the session id... except COMMON SENSE.

Sessions are supposed to scope "within a single web application," but
there isn't a specification of how that's supposed to be enforced.  For
example, these two URLs may invoke the same Servlet context, or they
might not:

	https://foo.company.com/servlet/baz
	http://bar.company.com/servlet/baz

Messing the the session cookie may not be guaranteed to be portable, but
there are other ambiguous issues even if you don't.

-- Charles


Mime
View raw message