[Beta12] Session/Front calling SSO::onSessionRead just looks wrong - like it won't work for more than one SSO handler

Hello,

I think it probably makes sense to allow more than one SSO handler - for example some users of your platform might have logged into “service-1” and others might have logged into “service-2” and if both services have the potential for SSO login to IPS then you would want two SSO handlers - if the first one succeeds then don’t try the second one (or any other subsequent ones) but if the first one fails then you would want to try the second (and subsequent) in case a later one returns success.

It appears to me that the way that Session/Front works it does not get any signal back from the SSO handler to say either “keep on trying” or “we now have success so stop trying any more SSO handlers”.

The problems…

SSO::onSessionRead() is only called for the first SSO handler in the chain.

foreach( Application::allExtensions( 'core', 'SSO', FALSE ) as $ext )
{
/* @var SSOAbstract $ext */
if( $ext->isEnabled() )
{
return $ext->onSessionRead( $this, $result );
}
}

SSO::onInit() is called for ALL SSO handlers - so if (for example) the first one is successful Session/Front still continues on down the chain looking for further SSO handlers:

foreach( Application::allExtensions( 'core', 'SSO', FALSE ) as $ext )
{
/* @var SSOAbstract $ext */
if( $ext->isEnabled() )
{
$ext->onSessionInit( $this );
}
}

Of course, the order of discovery (in the ‘foreach’) is pretty random so the ‘first’ in the description above is pretty random. Even if you were going to make this controllable (sort order) in the future it would be nice to implement the ‘keep on trying’/’all done’ signal now so that my SSO code does not have to be modified in the future ;-)

Adding to the above — another problem that I ‘discovered’ just before submitting this…

The session data is ‘saved’ BEFORE SSO::onSessionRead() is called and the session data includes details of the logged in member - so, if the SSO module changes the logged in member the session data would be out of date (incorrect). There is no way for the SSO module to update the session data itself as the session data is ‘protected’ and thus only available to variants of Session.

/* Set data */
$this->data = array(
…

Thanks!

John