You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@tomcat.apache.org by DJP JEAN-PROST Dominique <Do...@dexia-sofaxis.com> on 2010/08/03 14:15:11 UTC
[SingleSignOn Valve] Chaning its behaviour
Hello,
I’m porting applications from weblogic to jboss which uses tomcat as everybody knows.
In weblogic, I used to use the SSO feature which allowed me to logout from a webapp without invalidating session for all webapps.
After reading SingleSignOn Valve documentation, I realize that tomcat doesn’t behave as I would like. So I’m about to code a new SingleSignOn Valve by extending tomcat’s one and overriding the deregister(String ssoId) method so that it doesn’t invalidate all sessions bound to the SSO Entry
My question is : is it safe for me to do that ? I mean, am I about to wreck something in tomcat internal ? Will I introduce such a change that SSO valve wouldn't work anymore ?
Thank in advance.
Dom
/**
484: * Deregister the specified single sign on identifier, and invalidate
485: * any associated sessions.
486: *
487: * @param ssoId Single sign on identifier to deregister
488: */
489: protected void deregister(String ssoId) {
490:
491: if (containerLog.isDebugEnabled())
492: containerLog.debug("Deregistering sso id '" + ssoId + "'");
493:
494: // Look up and remove the corresponding SingleSignOnEntry
495: SingleSignOnEntry sso = null;
496: synchronized (cache) {
497: sso = (SingleSignOnEntry) cache.remove(ssoId);
498: }
499:
500: if (sso == null)
501: return;
502:
/* Remove this part so that only the "current" Session is invalidated
503: // Expire any associated sessions
504: Session sessions[] = sso.findSessions();
505: for (int i = 0; i < sessions.length; i++) {
506: if (containerLog.isTraceEnabled())
507: containerLog.trace(" Invalidating session "
508: + sessions[i]);
509: // Remove from reverse cache first to avoid recursion
510: synchronized (reverse) {
511: reverse.remove(sessions[i]);
512: }
513: // Invalidate this session
514: sessions[i].expire();
515: }
End of change
*/
516:
517: // NOTE: Clients may still possess the old single sign on cookie,
518: // but it will be removed on the next request since it is no longer
519: // in the cache
520:
521: }
Consultez nos nouveaux sites internet :
http://www.dexia-sofaxis.com
http://www.dexia-sofcap-sofcah.com
Tous ensemble pour l’environnement : n’imprimer ce courriel que si nécessaire.
Dexia Sofaxis disclaimer : http://www.dexia-sofaxis.com/disclaimer.html
Re: [SingleSignOn Valve] Chaning its behaviour
Posted by Mark Thomas <ma...@apache.org>.
On 03/08/2010 13:15, DJP JEAN-PROST Dominique wrote:
> Hello,
>
> I’m porting applications from weblogic to jboss which uses tomcat as everybody knows.
> In weblogic, I used to use the SSO feature which allowed me to logout from a webapp without invalidating session for all webapps.
>
> After reading SingleSignOn Valve documentation, I realize that tomcat doesn’t behave as I would like. So I’m about to code a new SingleSignOn Valve by extending tomcat’s one and overriding the deregister(String ssoId) method so that it doesn’t invalidate all sessions bound to the SSO Entry
>
> My question is : is it safe for me to do that ? I mean, am I about to wreck something in tomcat internal ? Will I introduce such a change that SSO valve wouldn't work anymore ?
>
> Thank in advance.
Probably more a question for the users list than the dev list.
Mark
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@tomcat.apache.org
For additional commands, e-mail: dev-help@tomcat.apache.org