tomcat-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Pid <...@pidster.com>
Subject Re: [SingleSignOn Valve] Overriding deregister(String) method
Date Tue, 03 Aug 2010 12:44:51 GMT
On 03/08/2010 13:26, DJP JEAN-PROST Dominique wrote:
> Hello,
>=20
>=20
>=20
> I=E2=80=99m porting applications from weblogic to jboss which uses tomc=
at as everybody knows.
>=20
> In weblogic, I used to use the SSO feature which allowed me to logout f=
rom a webapp without invalidating session for all webapps.
>=20
> After reading SingleSignOn Valve documentation, I realize that tomcat d=
oesn=E2=80=99t behave as I would like. So I=E2=80=99m about to code a new=
 SingleSignOn Valve by extending tomcat=E2=80=99s one and overriding the =
deregister(String ssoId) method so that it doesn=E2=80=99t invalidate all=
 sessions bound to the SSO Entry
>=20
> My question is : is it safe for me to do that ? I mean, am I about to w=
reck something in tomcat internal ? Will I introduce such a change that S=
SO 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
>=20
>=20
>=20
>=20
>=20
> /**
>=20
> 484:             * Deregister the specified single sign on identifier, =
and invalidate
>=20
> 485:             * any associated sessions.
>=20
> 486:             *
>=20
> 487:             * @param ssoId Single sign on identifier to deregister=

>=20
> 488:             */
>=20
> 489:            protected void deregister(String ssoId) {
>=20
> 490:
>=20
> 491:                if (containerLog.isDebugEnabled())
>=20
> 492:                    containerLog.debug("Deregistering sso id '" + s=
soId + "'");
>=20
> 493:
>=20
> 494:                // Look up and remove the corresponding SingleSignO=
nEntry
>=20
> 495:                SingleSignOnEntry sso =3D null;
>=20
> 496:                synchronized (cache) {
>=20
> 497:                    sso =3D (SingleSignOnEntry) cache.remove(ssoId)=
;
>=20
> 498:                }
>=20
> 499:
>=20
> 500:                if (sso =3D=3D null)
>=20
> 501:                    return;
>=20
> 502:
>=20
>=20
>=20
>                   /* Remove this part so that only the "current" Sessio=
n is invalidated
>=20
>=20
>=20
> 503:                // Expire any associated sessions
>=20
> 504:                Session sessions[] =3D sso.findSessions();
>=20
> 505:                for (int i =3D 0; i < sessions.length; i++) {
>=20
> 506:                    if (containerLog.isTraceEnabled())
>=20
> 507:                        containerLog.trace(" Invalidating session "=

>=20
> 508:                                + sessions[i]);
>=20
> 509:                    // Remove from reverse cache first to avoid rec=
ursion
>=20
> 510:                    synchronized (reverse) {
>=20
> 511:                        reverse.remove(sessions[i]);
>=20
> 512:                    }
>=20
> 513:                    // Invalidate this session
>=20
> 514:                    sessions[i].expire();
>=20
> 515:                }
>=20
>=20
>=20
>             End of change
>=20
>             */
>=20
> 516:
>=20
> 517:                // NOTE:  Clients may still possess the old single =
sign on cookie,
>=20
> 518:                // but it will be removed on the next request since=
 it is no longer
>=20
> 519:                // in the cache
>=20
> 520:
>=20
> 521:            }
>=20
>=20
>=20
> Consultez nos nouveaux sites internet :=20
> http://www.dexia-sofaxis.com=20
> http://www.dexia-sofcap-sofcah.com
>=20
> Tous ensemble pour l=E2=80=99environnement : n=E2=80=99imprimer ce cour=
riel que si n=C3=A9cessaire.
>=20
> Dexia Sofaxis disclaimer : http://www.dexia-sofaxis.com/disclaimer.html=




Mime
View raw message