I know doing this at the application level is probably going to be a little messy and that's ok for now. Since this is for a video training program, yes the requirement is appropriate. As for handling browser crashes, I'll have to set the timeout to an appropriate time, (1/2 hour or so) but if you are watching videos and testing, or reading docs, you can chew up 1/2 hour easily so I haven't really thought it through fully yet. At the moment, I am using Tomcat's Realm's authentication due to the different roles throughout the program.
Key pairs to the DB is more overhead than I would like to see, and I'd only like to use that if all else fails. That seems to be, no offense, a bit of resource wasting. What do you mean that valves are going kaput? Is that for the TC7 release? Andre, your talking about something like Active Directory for Windows Domain's to use with say Communicator, Outlook, etc, across windows environments with domain authentication? I understand what the Tomcat's and most org's SSO means, but I am trying to translate into something that I can talk about and not have a huge amount of keystrokes in typing. It's looking more and more like a custom code job (for the most part). I'll continue to do some research on this, but I think that coding is going to be the most direct route so far. Thanks everyone. I appreciate the input. - Josh On Mon, Oct 12, 2009 at 9:50 AM, Pid <p...@pidster.com> wrote: > On 12/10/2009 14:37, Peter Crowther wrote: > >> 2009/10/12 Josh Gooding<josh.good...@gmail.com>: >> >>> To my knowledge the Single Sign on in Tomcat is a way for all of your >>> back >>> end applications in your VH to recognize that you have logged in to one >>> place, and all of the apps belonging to that VH will be logged into. >>> >> >> Correct. >> >> What I am trying to do is restrict the login from users to one single >>> session. (i.e. if you are logged in once, you cannot log in again unless >>> your session expires or you log out.) Is this possible with what is >>> included with Tomcat or is this going to take some custom code? >>> >> >> You'll need custom code. >> >> Are you sure this is an appropriate requirement? In particular, how >> do you plan to handle (say) a browser or client crash that loses the >> in-memory session cookie? The user can neither log out from the old >> session nor log into a new session until the server times out the >> session. >> > > The OP could just set a new key value in the session each time a user logs > in, and ensure that any user with an old, invalid key is logged out on their > next request. > > You would need to compare the key in the session, on each request, to the > key associated with the user in storage somewhere, which is an additional > overhead. > > A Filter in each app would be suitable, (or a Valve though these will soon > be going the way of the Dodo, so they're probably not a good long term > choice). > > > > p > > > > - Peter >> >> --------------------------------------------------------------------- >> To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org >> For additional commands, e-mail: users-h...@tomcat.apache.org >> >> > > --------------------------------------------------------------------- > To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org > For additional commands, e-mail: users-h...@tomcat.apache.org > >
