Login Handler Docs incorrect

[Aiwa]

So, I reported this Dev doc, but I'm going to put the information here so others may benefit until the docs get updated. 

The getTitle() method, and the language key that it returns, is not actually used as the title of the login handler, I had plenty of WTF moments over the last day about this.  Instead it's only the base for the _info, etc tags. 

What I've found is that you have to programmatically generate a login_method_{$id} language key right after you insert your login handler into the core_login_methods table.  Keep track of the $id after doing your insert so you can create your language key.  Then make the getTitle() function to do what the name implies.

\IPS\Lang::saveCustom( 'core', "login_method_{$id}", \IPS\Member::loggedIn()->language()->get( \IPS\steam\Login\Steam::getTitle() ) );

A perfect example to highlight this issue... Look at login_method_5.  Value of 'Invision Community'.  Awesome, that's what it says in your ACP...

         

Well.... lets look at the getTitle() method from the Invision login handler...

	public static function getTitle()
	{
		return 'login_handler_InvisionCommunity';
	}

And let's see what the value of that language key really is... 

Whether this is a bug or working as intended, I leave for IPS to decide... What would be nice, however, is either the code or the docs be updated to show what we need to do to actually get our Login Handlers to have a proper title displayed in ACP > Login and Registration, other than 'login_method_X', when we install applications with a login handler, or upgrade applications that add a login handler.

I lost the better part of a day tracking this down, partly because I edited the field, typed in a name, and didn't realize it created an entirely different language key for me... So hopefully others can learn from this.

[Stuart Silvester]

You shouldn't be inserting this manually for customers, you should be allowing them to add it themselves from the 'Create New' button after installing your application. At this point is where they (It's a user supplied value) can add the title for the login handler. -- They'll need to go to there to configure the login handler with their Steam OpenID credentials anyway.

[Aiwa]

@Stuart Silvester So I understand... Your position is that, after application installation you're expecting manual creation of the Login Method by the client, via ACP > Login and Registration.  At which point they can specify a name themselves that would then create this language key for them?  Is that a fair interpretation?

 

With regards to the Steam OpenID 2.0 (separate topic really).  There is no Client ID / Client Secret.  Thus no actual settings for the client to fill out in the Login Method.  All it really NEEDS is a name after inserted into the core_login_methods table.

Here is an example of the code to authenticate for Steam.  Direct the user to the Steam Sign in page, receive a response with a signature, token etc, call the endpoint again with the first response signature, token, etc and get a true or false response for a valid login.

https://gist.github.com/Ehesp/8315084

You're also welcome to download my app and see how it works if you feel so inclined.  \IPS\steam\Login\Steam along with the 20018 upgrade.php and Application.php installOther.

[Aiwa]

14 hours ago, Stuart Silvester said:

You shouldn't be inserting this manually for customers, you should be allowing them to add it themselves from the 'Create New' button after installing your application. At this point is where they (It's a user supplied value) can add the title for the login handler. -- They'll need to go to there to configure the login handler with their Steam OpenID credentials anyway.

After looking at this longer, while I understand your position that you want a client to manually create the handler, your solution creates a wrinkle in my use case... 

I'm converting data from an existing non-functional handler from 4.2 so that those existing linked accounts function out of the box with mine.  I achieve this with a background queue that's triggered after upgrade and install to convert data.  If I don't insert the method programmatically, I can't do the conversion in that manner as I wouldn't have an ID from core_login_methods to insert the members into core_login_links... I'd have to build some other setting and provide the admin with a method to kick off the conversion queue.  If I do create the method programmatically, then I also have to create the associated language bit, and I can trigger the queue as the last step in upgrade / install. 

I appreciate your stance, and it will likely be the best solution for many. I just have to be difficult. ?

Warning to anyone that uses my method, if you're doing this in an upgrade.php, make sure to use an existing language string.  The upgrade steps are run prior to the new versions languages being imported.  ?  If you're just doing this on Install, using Application.php installOther, it'll work just fine with a new language string as the languages are imported prior to installOther running.

[Stuart Silvester]

On ‎5‎/‎17‎/‎2018 at 2:42 AM, Aiwa said:

After looking at this longer, while I understand your position that you want a client to manually create the handler, your solution creates a wrinkle in my use case...  

I'm converting data from an existing non-functional handler from 4.2 so that those existing linked accounts function out of the box with mine.  I achieve this with a background queue that's triggered after upgrade and install to convert data.  If I don't insert the method programmatically, I can't do the conversion in that manner as I wouldn't have an ID from core_login_methods to insert the members into core_login_links... I'd have to build some other setting and provide the admin with a method to kick off the conversion queue.  If I do create the method programmatically, then I also have to create the associated language bit, and I can trigger the queue as the last step in upgrade / install. 

I appreciate your stance, and it will likely be the best solution for many. I just have to be difficult. ?

Warning to anyone that uses my method, if you're doing this in an upgrade.php, make sure to use an existing language string.  The upgrade steps are run prior to the new versions languages being imported.  ?  If you're just doing this on Install, using Application.php installOther, it'll work just fine with a new language string as the languages are imported prior to installOther running. 

I've just had a look at your file, that is really bizarre that they don't require any kind of application authentication to use their OpenID API. I wouldn't be surprised if they change that at some point. Really, this points your login handler in the 'minority' 99.95% (don't we all love fake stats!) will require the user to go in and configure it.

So, to re-cap "login_method_{$id}" is a user-supplied string (it's a node title) that they create when adding the login handler and configuring it. I don't see anything wrong with the way you're working around this (keeping in mind that you want to do this to automatically upgrade user accounts). There isn't a bug or something missing from the dev docs.