Wednesday 08 June 2011 6:36:13 am

I can't say I fully understand your requirements of elegance, but how about coding a custom template operator and drop it in pagelayout to determine if the user should be logged out? Is that what you're trying to stay away from?

What config.php are you talking about? [ezroot]/config.php? I think maybe an extension would be more suitable and more portable for you.

Hope this helps

Hmmm, I guess I was stuck in a mindset of resolving the current user before it even got to templates. Pagelayout doesn't come into play until after the module and view have been processed so, in the case of a user who should be logged out, I would have to logout the user out and then redirect back to the same requested URL so the module and view get processed with the appropriate current user. I suppose that would work, though, albeit with an added bit of server processing time. I was originally hoping I just had not yet stumbled upon something built-in with the login/sso handlers that does what I'm trying to do but I'll go ahead and try the template operator approach. Thanks.

(There's also a potential issue with having to put the template operator in multiple pagelayouts but I just took a look and page_head.tpl seems to be an include common to all of them, so I can just put it there.)

Wednesday 08 June 2011 8:17:41 am

Hm, is your System B allows you to hook on it's logout event, you could use that to destory the users session in that moment (possibly through a custom module of your extension).

This sounds like the most logical solution since you are doing the same thing (but vice versa) in the eZP's logout handler.

P.S: And what about this case: A user is NOT logged in in the System B, but logs in in eZP. Did you cover this case so that then user gets automatically logged in in System B?

It's pretty much a one-way relationship between System A (the eZP server) and System B, which is managed by another company. B does not send anything to A that A does not ask for. System A can send queries to B that include the capability to log the user into and out of B. So yes, a user logging in to eZP is automatically logged into B. The only hole here is what happens when the user logs out directly from B, because it does not let A know, and I cannot ask for System B to be changed to do that (or at least not without major cost).

Thursday 09 June 2011 1:34:29 am

Ok, then you need a cronjob script that does that, Checks with your System B if the user is logged in, and if it's not logs him out (or deletes it's session) on the eZP part.

This won't be possible as of eZ Publish 4.4 since it uses the default PHP session implementation, and thus doesn't store the users' sessions in the database. 

To me, the only way to go would be to set a short session time for eZ Publish (let's say 30min or less). If user is not logged in any more in the SSO system, then the SSO handler should not log any user in (by returning false).

Friday 10 June 2011 3:56:21 am

@JV: afaik, you cans still enable the custom ez session handler in ezp 4.5 and later, so you get all the goodies you need. Are you sure about statement?

@David: it's quite unfortunate that in system B users can log out, and still you can not have system B send any request to the eZ Publish site to notify it that the user has logged out... after all this is the most common way to set up single-sign-off: the site where the user is signing-off sends a notification to the central authentication system (and I think you figured out how to have eZ notify system B of users having logged out in eZ already). Also it is good practice to have one system used as authentication master for all involved sites, pulling off master-master is complex.

I think it might work with a custom tpl operator in the pagelayout (or some php code in config.php) - you might even skip the standard eZ SSO configuration and use that single operator to do the sso checks for both anon and logged in users.

A few things to take into account:

- you will be sending an sso request to system B for every page view of eZ users, both anon and not. Lots of traffic to system B (can it cope?) and risks of slowing down eZ pages if system B is not very responsive

- high risks of creating loops when users authenticates or deauthenticates himself, esp. if redirects are in use at either site (eg. user starts anon, logs in in eZ, eZ tells system B that user has logged in, user is redirected to new eZ Page, new page checks if user is logged in in system B but gets a stale response => user is logged out from eZ)

Principal Consultant International Business
Member of the Community Project Board

Friday 10 June 2011 4:07:55 am

@JV: afaik, you cans still enable the custom ez session handler in ezp 4.5 and later, so you get all the goodies you need. Are you sure about statement?

I was saying by default.