tomcat-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Peter Rossbach ...@objektpark.de>
Subject Re: why is Principal not serialized for clustering replication of ses sion?
Date Wed, 17 Aug 2005 07:58:55 GMT
Hey Dirk,

I thing you have found a strange missing feature inside the cluster 
implementation. Currently
all other realm MemoryRealm, DataSourceRealm,JNDIRealm, JAASRealm and 
JDBCRealm  create a GenericPrincipal that used  inside the 
DeltaRequest.setPrincipal method. The UserDatabaseRealm create a 
o.a.c.users.MemoryUser principal. Very bad thing!! Integrate a spezial 
handling for this is easy, but.... :-(

I have tested with MemoryRealm successfull with basic auth. Sorry, but 
this means that at every request a message is replicated.
The session principal is set at every request. I don't like this 
behaviour. Any ideas to change it are very welcomed!

Please open a bug report that we can work together at this auth topic 
and documened it well at changelog.

Thanks for reporting this.
Peter




Peter Rossbach schrieb:

> Hmm,
> I have look inside source of DeltaRequest
>
> public void setPrincipal(Principal p) {
>        int action = (p==null)?ACTION_REMOVE:ACTION_SET;
>        SerializablePrincipal sp = null;
>        if ( p != null ) {
>            sp = 
> SerializablePrincipal.createPrincipal((GenericPrincipal)p);
>        }
>        addAction(TYPE_PRINCIPAL,action,NAME_PRINCIPAL,sp);
>    }
> ....
>  public synchronized void execute(DeltaSession session, boolean 
> notifyListeners) {
> ...
>                    Principal p = null;
>                    if ( info.getAction() == ACTION_SET ) {
>                        SerializablePrincipal sp = 
> (SerializablePrincipal)info.getValue();
>                        p = 
> (Principal)sp.getPrincipal(session.getManager().getContainer().getRealm()); 
>
>                    }
>                    session.setPrincipal(p,false);
>                    break;
>                }//case
> ....
> ....
>
> and this look like that we explizit replicated the principal.
>
> I will test you use case with the newest 5.5.x code base again and 
> describe
> the results later.
> peter
>
> PS: SingleSignOn is currently not supported at the cluster 
> implementation :-(
>
>
>
> Dirk de Kok schrieb:
>
>> hi all,
>>
>> we are having a problem with our Tomcat 5.5.9 cluster. We run 2 Tomcat
>> instances on physically different machines. For security we use normal
>> container managed security, configured in the web.xml. Session 
>> replication
>> works fine, and session id's are same across the two instances. We 
>> only have
>> trouble with the authentication.
>> For instance, if you are logged in on instance1, if in case of error the
>> load balancer redirects subsequent request to instance2, you have to 
>> login
>> again. Turning on Single Signon did not help.
>> Browsing through the Tomcat source code I noticed that very explicit the
>> security Principal is not saved in a serialized session. Has anybody 
>> an idea
>> why this is not done? What way would we be able to let the security
>> information propagate throughout the cluster?
>>
>> Configuration:
>> - OS: RH 4
>> - App server: Tomcat 5.5.9
>> - Session replication: in-memory, pooled
>> - Load balancing via hardware load balancer (Cisco) with sticky sessions
>>
>> tia,
>>
>> Dirk
>>
>> - Lost Boys creates and delivers internet & mobile solutions -
>> Dirk de Kok | Java Specialist
>> Lost Boys B.V. | Joop Geesinkweg 209 | 1096 AV Amsterdam The 
>> Netherlands |
>> Tel: +31 20 4604500 | Fax: +31 20 4604501 | dirk.dekok@lostboys.nl |
>> www.lostboys.nl
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: tomcat-dev-unsubscribe@jakarta.apache.org
>> For additional commands, e-mail: tomcat-dev-help@jakarta.apache.org
>>
>>
>>
>>
>>  
>>
>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: tomcat-dev-unsubscribe@jakarta.apache.org
> For additional commands, e-mail: tomcat-dev-help@jakarta.apache.org
>
>
>
>





---------------------------------------------------------------------
To unsubscribe, e-mail: tomcat-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: tomcat-dev-help@jakarta.apache.org


Mime
View raw message