On 12/10/2009 15:16, Josh Gooding wrote:
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.

A single (sensible query) DB hit is not a huge overhead in a modern app, especially if your app is hitting the DB multiple times, producing complex objects, for each page requested.

It needn't be a DB, it could be a suitable synchronised (or not?) map, held in the application scope.

You have to keep things in context. (Hehe, you see what I did there?)


What do you mean that valves are going kaput?  Is that for the TC7 release?

I understand that the goal in TC7 is to replace Valves with Filters configured at various levels.

It has ever been the case that integrating your app with Tomcat internals is a risky strategy, because they are not bound to a spec and thus could change on each release.

p


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





---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
For additional commands, e-mail: users-h...@tomcat.apache.org

Reply via email to