[ProxyConnect) How to extend user details transferred?

judgej

I wonder if you can provide any development advice on something that I am trying to do. It is nearly working, but the execution paths through this plugin is just too complicated for me to follow.

Basically, my CMS is providing additional information on the users in the authorise URL. The information is used to put the users into specific roles, set up a default signature and a few other things. Capturing this information is simple: I have added a line of code in _GetForeignCredentials() to save *all* the response details in the Gdn_ProxyAuthenticator object:

$this->ProxyRequestResponseResult = $Result;

Now, that works, but the problem lies in where to put an event to be able to use that information.

What I need is one or more events that will catch the post-authentication of a user so that I can look at these details and update the user's account accordingly. The Autenticate() method provides one place that works *most* of the time, around line 64:

... Gdn::Authenticator()->Trigger($AuthResponse); if ($AuthResponse == Gdn_Authenticator::AUTH_SUCCESS) { // Everything's cool, we don't have to do anything. $this->EventArguments['ProxyRequestResponseResult'] = $this->ProxyRequestResponseResult; $this->FireEvent('AfterUserAuthenticated'); } elseif ($AuthResponse == Gdn_Authenticator::AUTH_PARTIAL) { ...

This works when an existing user comes to the forum. However, when a user comes to the forum for the first time, and is subsequently created, this event does not fire. I cannot find where in this plugin to place an event that would have access to both the saved ResponseResult details and the newly-created user.

(Edit: I will add, then when a user comes in for the first time and this event does not fire, pressing the browser back button to back out again to the calling CMS will fire this event four times! I have no idea what is going on there, and is one reason why I don't understand the code execution path.)

Do you have any pointer as to where this would be a good place? Once I have this working, would you also consider putting the events into the core plugin so other plugins can extend it?

Alternatively, maybe I am looking to hook the wrong thing? Perhaps there is an event in the core Vanilla that has access to the Authenticator object and fires after a user is logged in, whether they have just been created by your plugin or not?

Thanks in advance! And sorry this is such a long post, but I'm tearing my hair out trying to follow the execution path, and the cookies and redirects and handshakes...

-- Jason

judgej

Any pointers at all? I'm hoping someone who is familiar with the code can point me in the right direction and I can pick it up from there.

Just a tl;dr summary:

On logging in using ProxyConnect for the first time, I would like additional information from the CMS to apply to the vanilla account. I can capture the additional information sent by the CMS, and I can use that information to update the user's account. What I can't see, is where to hook into the ProxyConnect plugin so that the captured information can be used to update the current user's account (the user that has just been created and/or authenticated), in such a way that the update is guaranteed to happen.

judgej

Okay, I'm going to give up on this now. I have wasted enough time on it, and nobody who knows how the authentication works is available to give me any clues.

I will now use a cron job to get my CMS to create users directly in the Vanilla database. It's not ideal, but it should work. It seems to be the only way to get details of users in the CMS into Vanilla.

Tim

Ugh. Give me a minute.

judgej

I have tried putting debug statements in every method of the proxy authenticator in the hope of seeing where the code would need to be hooked in. Not in one single place is both the user authenticated and the remote user information available at the same time (when user logs in for the first time and gets created). There are a couple of HTTP requests and data passed around via cookies, so what is actually happening in that authentication controller is pretty sophisticated and hard to follow.

Tim

If you download the latest Unstable code and use this version of ProxyConnect you should be able to hook the following events:

Gdn_Auth_AuthSuccess_Handler($Sender)
Gdn_Auth_AuthCreated_Handler($Sender)

Tim

Forgot to mention: check the $Sender->EventArguments array for a "UserData" key for your info.

judgej

Cool - I will certainly try that tonight :-) Much appreciated.

I wasn't trying to be critical or impatient when saying I was giving up on this approach - I was just giving in to the realities of deadlines and the time people have available. Now you open another door. Thanks.

judgej

Okay, I'm going to have to sleep on this. I can't actually work out how to pull the unstable branch (is it a branch with a property of being "unstable", or just a branch with the name "unstable"? Just need to get a handle on it. And learn git).

Edit: got it. Pull "master" then merge in "unstable".

judgej

I have given ProxyConnect 1.8.5a a go, and it does now raise the new events. However, only four items of the handshake are passed into the event (email, name, uniqueID and TransientKey). All the other details passed over by the authenticating CMS are discarded.

The method that does the fetching is Gdn_ProxyAuthenticator->_GetForeignCredentials() and it is that which only takes those four parameters. To be useful for extending user details that are passed in, that method needs to record all the additional name/value pairs that the handshake provides.

Edit: so far as I can see, the Gdn_Auth_AuthCreated_Handler is never fired. But then the result is not set to AUTH_CREATED anywhere in the code, so that's no surprise. Unless there is some core unstable code I haven't spotted and included?

judgej

My hack to work around getting the additional user data into my event is to save the full handshake data in _GetForeignCredentials():

if ($Result) { $ReturnArray = array( 'Email' => ArrayValue('Email', $Result), 'Name' => ArrayValue('Name', $Result), 'UniqueID' => ArrayValue('UniqueID', $Result), 'TransientKey' => ArrayValue('TransientKey', $Result, NULL) ); // JDJ: save the full handshake data. $this->ProxyRequestResponseResult = $Result; return $ReturnArray; }

Then passing that data into the event in WakeUp():

$UserEventData = array_merge(array( 'UserID' => Gdn::Session()->UserID, 'Payload' => GetValue('HandshakeResponse', $this, FALSE), 'Payload2' => GetValue('ProxyRequestResponseResult', $this, FALSE), // JDJ send saved data ),$UserInfo);

This just sticks the full authentication handshake data into "payload2" and leaves "payload" unchanged, since other plugins may still expect it to be there in its current form.

I'm trying to use the latest version of your module with the smallest hacks possible, and those two labelled lines do it for me. It doesn't deal with the non-used AUTH_CREATED, but that's the next step.

Tim

I starred this to get back to it when I'm done my current time-sensitive task