You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@tomcat.apache.org by DJP JEAN-PROST Dominique <Do...@dexia-sofaxis.com> on 2010/08/03 14:26:32 UTC
[SingleSignOn Valve] Overriding deregister(String) method
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] Overriding deregister(String) method
Posted by Mark Thomas <ma...@apache.org>.
On 03/08/2010 13:49, DJP JEAN-PROST Dominique wrote:
> -----Message d'origine-----
> De : Pid [mailto:pid@pidster.com]
> Envoyé : mardi 3 août 2010 14:45
> À : Tomcat Users List
> Objet : Re: [SingleSignOn Valve] Overriding deregister(String) method
>
>
> Potentially silly questions:
>
> #1 how is one supposed to logout of all apps?
> [Dominique Jean-Prost] I don't need this feature
> #2 what's the reason for using a half functional SSO valve?
> [Dominique Jean-Prost] From y point of view (and from what I need) the SSO valve is aimed at preventing user to enter login/password each time he wants to access a new webapp. It shouldn't mean that because he used this feature he should log out for all the webapp he accessed.
>
> That's why I would like to "enhance" tomcat's valve so that it meets my requirements. My question is : will I introduce such a change so that tomcat wouldn't work (is the fact that the valve runs this way is a requirement for tomcat ?)
Tomcat won't care.
The user won't be able to logout in the normal sense (since the SSO
valve will sign them back in again) but logging out should invalidate
the session associated with that web app which is what I suspect you want.
Mark
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org
RE: [SingleSignOn Valve] Overriding deregister(String) method
Posted by DJP JEAN-PROST Dominique <Do...@dexia-sofaxis.com>.
-----Message d'origine-----
De : Pid [mailto:pid@pidster.com]
Envoyé : mardi 3 août 2010 14:45
À : Tomcat Users List
Objet : Re: [SingleSignOn Valve] Overriding deregister(String) method
Potentially silly questions:
#1 how is one supposed to logout of all apps?
[Dominique Jean-Prost] I don't need this feature
#2 what's the reason for using a half functional SSO valve?
[Dominique Jean-Prost] From y point of view (and from what I need) the SSO valve is aimed at preventing user to enter login/password each time he wants to access a new webapp. It shouldn't mean that because he used this feature he should log out for all the webapp he accessed.
That's why I would like to "enhance" tomcat's valve so that it meets my requirements. My question is : will I introduce such a change so that tomcat wouldn't work (is the fact that the valve runs this way is a requirement for tomcat ?)
Dom
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] Overriding deregister(String) method
Posted by Pid <pi...@pidster.com>.
On 03/08/2010 13:26, 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 ?
Potentially silly questions:
#1 how is one supposed to logout of all apps?
#2 what's the reason for using a half functional SSO valve?
p
> 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