You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@tomcat.apache.org by "Extance, Paul" <pa...@spirent.com> on 2002/08/01 01:40:15 UTC

RE: share session between webapps

We have the same requirements, and to agree with Craig, we use the
request.getUserPrincipal()!=null to assert they are
authenticated, and we also use the request.getUserPrincipal().getName() to
get the User Id (or key) so we can use this
in our application.

In addition we've built a variant of the JDBC realm that allows an
additional encryption class to be specified, it will
use this class to encrypt the password before validating it with the
database. (We decided not to add this to RealmBase, but
I'm sure could if you wanted).

Example
    <Realm className          = "org.jaffa.tomcat.realm.JDBCEncryptionRealm"
           debug              = "99"
           driverName         = "oracle.jdbc.driver.OracleDriver"
           connectionURL      =
"jdbc:oracle:thin:@host.domain.com:1521:dbname"
           connectionName     = "dummyuser"
           connectionPassword = "dummypass"
           userTable          = "use1"
           userNameCol        = "userid"
           userCredCol        = "password1"
           userRoleTable      = "usrl"
           roleNameCol        = "role_name"
           encryptionClass    =
"com.domain.applications.user.services.Encryption"
           encryptionMethod   = "customEncrypt" 
    />

It also has some other nice features....

It is being released as part of the http://jaffa.sf.net project, but it you
want an advanced copy of the source, class, jar ,docs etc let me know

BTW: If I have webapp1 deployed on tomcat 4.0x on Linux, and another webapp2
on Tomcat on a W2K box, is there any way to implement single sign on across
the two?

Paul Extance
jaffagroup@yahoo.com


-----Original Message-----
From: Craig R. McClanahan [mailto:craigmcc@apache.org]
Sent: Wednesday, July 31, 2002 9:39 AM
To: Tomcat Users List
Subject: Re: share session between webapps




On Wed, 31 Jul 2002, Michael Remijan wrote:

> Date: Wed, 31 Jul 2002 08:34:34 -0500
> From: Michael Remijan <Mi...@solocup.com>
> Reply-To: Tomcat Users List <to...@jakarta.apache.org>
> To: Tomcat Users List <to...@jakarta.apache.org>
> Subject: share session between webapps
>
> ...
>
> Is there technique to share a session, or objects within the session
> between web applications?

No.  And it wouldn't work even if there was such a mechanism, because each
webapp has its own class loader -- the classes in webapp A's /WEB-INF
directory are not visible to webapp B (and vice versa).

> What I want to do is login or register at a
> site and if the user moves to a different webapp, I want to be able to
> determine, by looking for an object in the user's session, that they are
> already logged in.
>
>  Using realms and single sign on doesn't appear to do what I want
> because it A) doesn't allow me to get me the primary key for the user,

What's wrong with calling request.getRemoteUser() or
request.getUserPrincipal().

> B) doesn't allow me to write any special processing code, specifically
> to md5 encrypt the password before performing the query.

IMHO, if you are using container managed security you have absolutely no
business messing with passwords.  Either let the container manage all of
that or do it yourself.

 C) most
> importantly, it doesn't seem to allow me to carry information accross
> webapps.
>

This is true for *all* information, not just for security credentials.  If
you want to share information across webapps, the standard approaches are:

* Store it externally in a database, EJB, etc. that is accessed
  from each webapp

* (Container-specific, so no portability guarantees) store it in
  a static variable of a class that is loaded from a parent class
  loader of the webapp class loaders.  For Tomcat 4, that means
  putting the class in someplace like common/lib.

> <mike/>
>

Craig


--
To unsubscribe, e-mail:
<ma...@jakarta.apache.org>
For additional commands, e-mail:
<ma...@jakarta.apache.org>

--
To unsubscribe, e-mail:   <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>