Josh Gooding wrote:
Andre,
I am using a realm for this. I decided that the best route to go on this is
if a user is actively logged in and tries to log in again (while already
authenticated) to invalidate the 'other' session and continue on, that way
of the browser dies, they can still get in. I have however not clue one on
how to do this. What is put in the session upon authentication that I could
have my code look for to invalidate the "other" live session?
Josh,
I think that I fail to see what you are trying to achieve.
Assuming you are using "container managed security" as described here :
http://tomcat.apache.org/tomcat-6.0-doc/realm-howto.html#Quick%20Start
then what normally happens is this :
- a user, with his browser, accesses a URL on your server
- Tomcat maps this requested URL to a webapp
- in doing so, Tomcat sees that this webapp is submitted to
authentication/authorization
- Tomcat then wonders whether this user is already authenticated. For
that, it checks if this request is associated with a session (which can
be indicated by a JSESSIONID cookie, or a request attribute coming with
the request).
(*)
- If yes, then Tomcat will retrieve the user-id associated with this
session, and then check if this user-id has the appropriate "role" for
accessing this webapp. If not, the request is rejected, else it proceeds.
- (**) If no, then Tomcat will trigger a user authentication.
Depending on how this is set up, it will either send back a html login
page to the browser, or a 401 status code to trigger the browser's
builtin login dialog.
- The browser will then send back the user's credentials. Tomcat will
check them (using the configured method for that), and if they are ok,
will set the user-id, and record it in the session data. Then we go back
to (*) above. If the credentials are not OK, then it probably loops at
the (**) stage.
Now, how would a user in this case try to login a second time, when they
are already authenticated ?
And, does it matter ? (are you trying to limit the number of times the
same physical user is allowed to run the /application/ simultaneously ?)
Ok, let's say that the user leaves his first session open on workstation
A, and starts another browser session on station B (or, his browser
crashes and he restarts the browser, thus losing the previous session-id
information). He thus accesses the original URL again, and Tomcat
attributes a new session to this other browser.
(Or else, you are doing something like "pre-emptive authentication" :
you start each session by a login page, explicitly. But then, you are
no longer really in the logic of Tomcat's "container managed security".)
Tomcat itself will not provide a way to avoid that (the two or more
individual "sessions" at the Tomcat level), because for Tomcat, these
are really two independent sessions, and the second one has no relation
to the first, and that second session does not indeed contain any
Tomcat-level link to the first session.
If you want to provide such a link, then the only way I see would be at
the application level, for example with a servlet filter wrapping your
webapps, which would store somewhere the fact that this /user-id/ is
already in use (and its associated Tomcat session-id). Then it would be
the responsibility of this servlet filter also, to "destroy" the
previous Tomcat session linked to that same user-id, when this same
user-id shows up with a different session-id.
But I cannot tell you if this is possible using the standard Tomcat API.
You would have to be able to pass another Tomcat jsessionid (than your
own) to the session.invalidate() method, and I'm not sure that this is
possible.
(I think that it would open the door to all kinds of misbehaviours if it
was.)
To summarise, from what I think I understand which you want, it does not
marry very well with Tomcat's "container managed security", and you
should think more about a servlet filter based security mechanism, where
you can do pretty much as you please.
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
For additional commands, e-mail: users-h...@tomcat.apache.org
