eZ Community » Forums » Developer » hanging while trying to create new...
expandshrink

hanging while trying to create new user with SSO

hanging while trying to create new user with SSO

Tuesday 28 June 2011 9:51:52 pm - 13 replies

I have a class that extends eZUser to accommodate a secondary login handler. It includes a function that creates an eZ user object for an authenticated user who is logging in for the first time. It works absolutely fine when called as part of the login process.

I am working on a SSO handler. I want for it to likewise create an eZ user content object if one doesn't exist for an authenticated user. When I call the function to create the user from the SSO handler, the system hangs. Through troubleshooting I traced the problem to where the content object is instantiated.

$class = eZContentClass::fetch( $userClassID );
$contentObject = $class->instantiate( $userCreatorID, $defaultSectionID ); //this is the line that causes the hang

Does anyone have any guesses as to what is different about the SSO process that is causing this script to fail?

Modified on Tuesday 28 June 2011 9:56:26 pm by David Wirth

Tuesday 28 June 2011 10:36:38 pm

Hey David,

 

Sorry I don't have any clue about this. Just want to say that I made the exact same process (user creation in SSO and login of just created user) and it works fine !

Any errors in log that could help ?

Monday 19 September 2011 5:34:29 pm

There were no errors logged and I never did figure out why the server was hanging but I suspect it had to do with an Oracle driver. I will mark this issue resolved for now.

Tuesday 20 September 2011 9:22:38 pm

OK, I determined that it was not an Oracle driver problem and the hanging is still occurring. Just to reiterate: A function that creates a user content object executes without error when called by my login handler. The very same function causes the server to hang when called by the sso handler. There are no errors showing in the apache http error log or the ez error log. This makes no sense to me. Any ideas?

Modified on Tuesday 20 September 2011 9:25:51 pm by David Wirth

Wednesday 21 September 2011 6:44:31 pm

It appears that the hang occurs when eZUser::currentUser() is called. (Apparently eZContentClass::instantiate() calls for the current user in case you didn't supply the owner ID.)

eZUser::currentUser() is basically an alias of eZUser::instance(). I did some testing with that function. A direct call to eZUser::instance(), with no parameter provided, produces the same hanging behavior. If I call it with a known user ID as a parameter, e.g. eZUser::instance( 123 ), it does not hang and, surprisingly to me, it sets that user as the current user without my having to do anything else. If I create the instance using the anonymous user ID, as in eZUser::instance( 10 ), it hangs. My hunch is that every time the eZ engine detects an anonymous user it goes to the SSO handler, and so there is my infinite loop -- ez, detecting an anonymous user, executes the SSO handler, which in the course of creating a content object, makes a call to fetch the current user, which triggers the system to execute the SSO handler. Rinse, repeat.

Is my solution here to come up with a special user stub creation function that carefully constructs a content object while avoiding references to the current user? That seems dumb. Matthieu, I'm curious about how your user creation script works, as it does not seem to have the same problem.

Note: I am still on EZP 4.2. Has the SSO handler logic perhaps been modified after 4.2 in such a way that it resolves this issue?

Thursday 22 September 2011 2:59:28 am

Oh wait, now I get it. Somebody in a discussion about the sso handler said something about the instance but I did not quite get what he meant until now, which is that the sso handler is executed within eZUser::instance(). I just looked at the ezuser.php code and here's where the sso handler gets triggered:

if ( is_object( $currentUser ) and !$currentUser->isLoggedIn() )

So I can't invoke any method that fetches the anonymous user, which limits what I can do. I tried replacing my eZContentClass::instantiate() call with eZContentObject::create() to get around this problem but I am still missing something. The content object is created, a version object is created, a node is created and then something invokes an ezuser instance that runs afoul of that test above again, once again creating an endless loop.  But I'm getting closer to figuring this out. (?)

Modified on Thursday 22 September 2011 3:02:02 am by David Wirth

Wednesday 01 February 2012 11:23:04 am

Hi,

I have exactly the same problem.

Did you find a solution ?

Thanks in advance

Wednesday 01 February 2012 1:11:03 pm

Hi,

I have exactly the same problem.

Did you find a solution ?

Thanks in advance

I actually shelved this piece of our SSO scheme while I worked on other projects but was just about to revisit it this week. I am going to investigate some other support avenues and will let you know if I do figure it out.

Wednesday 01 February 2012 4:52:56 pm

Thanks.

For the time being, i am going to create a cronjob which replicates the users from the directory to ezpublish. It will mean there will be a propagation times but it will work.

Wednesday 01 February 2012 5:30:47 pm

Thanks.

For the time being, i am going to create a cronjob which replicates the users from the directory to ezpublish. It will mean there will be a propagation times but it will work.

Hmmm, I don't like the prospect of adding upwards of 10,000 users who might never log into the eZ site and I'm not crazy about a propagation delay but that is a viable plan B. Thanks for the idea.

Wednesday 01 February 2012 6:19:09 pm

yeah you are right. I thought of another solution but i am not really sure if it can be a working one.

In the SSO handler, you can save a temp login in a table or session and before the return $user/false if the user does not exist, you redirect the user to a module/view which will create all users with the login in the table/session.

Another idea would be to always logged with the same user and to set in session a temp eZUser with the real user information.

What do you think ?

Modified on Wednesday 01 February 2012 6:39:07 pm by Jonathan Bouzekri

Wednesday 01 February 2012 8:00:27 pm

yeah you are right. I thought of another solution but i am not really sure if it can be a working one.

In the SSO handler, you can save a temp login in a table or session and before the return $user/false if the user does not exist, you redirect the user to a module/view which will create all users with the login in the table/session.

Another idea would be to always logged with the same user and to set in session a temp eZUser with the real user information.

What do you think ?

I'm thinking both ideas could work. With the second idea you'd have a problem if you need to assign different roles to different users, though, I think.

I like the first idea. It adds some server overhead but it will only add that for their first page. If I understand correctly, it would go something like this...

  1. Authenticated new user visits your ez site url www.test.com/testpage.
  2. When the sso handler executes, it detects that this is a user for which a user needs to be created, so it stores the login in a session variable and does an immediate redirect to something like www.test.com/createuser/execute. (I think you could do this without specifying a view but I could be wrong.)
  3. The createuser module would create the user with the stored login, set the current user to the new user id with $user->loginCurrent(), assign any relevant roles, and then do another redirect back to the LastURIAccessed (or whatever that session variable is called).
  4. When www.test.com/testpage loads again, the user is logged in.

Yes? I think that's probably my plan B now.

Thursday 29 March 2012 5:07:39 pm

UPDATE: I was just working on upgrading our EZP from 4.2 to 4.6 and tested again and it works now. It appears that the problematic part of kernel/classs/datatypes/ezuser/ezuser.php was rewritten somewhere between 4.2 and 4.6 such that an infinite loop is no longer created when the SSO handler tries to create a new user object. Huzzah!

That might not help out users of an earlier community edition with this problem. Here's a patch that EZ Support provided for EZP 4.2 that may or may not be a solution for older versions:

 --- kernel/classes/datatypes/ezuser/ezuser.php+++ kernel/classes/datatypes/ezuser/ezuser.php@@ -1187,9 +1187,10 @@ static function instance( $id = false )                 if ( $ssoUser !== false )                 {                     $currentUser = $ssoUser;+                    $userId = $currentUser->attribute( 'contentobject_id' );                      $userInfo = array();-                    $userInfo[$userId] = array( 'contentobject_id' => $currentUser->attribute( 'contentobject_id' ),+                    $userInfo[$userId] = array( 'contentobject_id' => $userId,                                             'login' => $currentUser->attribute( 'login' ),                                             'email' => $currentUser->attribute( 'email' ),                                             'password_hash' => $currentUser->attribute( 'password_hash' ),@@ -1200,10 +1201,10 @@ static function instance( $id = false )                     $http->setSessionVariable( 'eZUserInfoCache_Timestamp', time() );                     $http->setSessionVariable( 'eZUserLoggedInID', $userId ); -                    eZUser::updateLastVisit( $currentUser->attribute( 'contentobject_id' ) );-                    eZUser::setCurrentlyLoggedInUser( $currentUser, $currentUser->attribute( 'contentobject_id' ) );+                    eZUser::updateLastVisit( $userId );+                    eZUser::setCurrentlyLoggedInUser( $currentUser, $userId );                     eZHTTPTool::redirect( eZSys::wwwDir() . eZSys::indexFile( false ) . eZSys::requestURI(), array(), 201 );-+                    eZExecution::cleanExit();                 }             }         }

Gah, I give up on trying to format that patch code, sorry.

Modified on Thursday 29 March 2012 5:13:59 pm by David Wirth

Thursday 29 March 2012 7:00:31 pm

nice one. I like it a lot.

expandshrink

You must be logged in to post messages in this topic!

36 542 Users on board!

Forums menu