Jump to content

New registrations via Oauth causing incomplete members

Recommended Posts

If someone visits x website and tries to create a social login account via the Oauth connected to the community, the account creation flow is interrupted and it does not ask for display name, rather just asks to allow the scopes and redirects back to the website.

This in turn seems to cause incomplete members which will eventually be deleted by the system.

When creating a new account via /oauth/authorize/ URL, the account creation flow should still ask for our display name/email. This does not happen when using social logins under "Sign In Faster".

Could contain: Text, Page

Link to comment
Share on other sites

1 hour ago, Marc Stridgen said:

It should indeed ask for a display name. On taking a look at your system, I would advise on disabling all 3rd party items and then testing this again. Especially the OAuth one you have there, as that would touch all the same areas. 

I tried disabling the OAuth you mentioned, and the issue is still present.

Are you able to reproduce on test environments perhaps?

Link to comment
Share on other sites

5 hours ago, Marc Stridgen said:

Please disable all 3rd party items, not just that one. We have many many people use these login methods, so it doesnt appear to be a widespread issue on this one

I did try this. Disabled everything via support and the issue was still present. I am not asked for a display name.

Link to comment
Share on other sites

On 6/25/2022 at 3:05 PM, Jim M said:

Your system is still showing with modified files in this area, you would need to replace the ones from the Client Area in order for us to assist further.

I also attempted restoring the modified files, even though the modifications are minimal, the issue was still present. I recorded a video with the issue as I have to restore the modifications after testing.

The modified contents are as follows. They should not interfere with the sign up flow:

/oauth/authorize/index.php - Comment out 93-98 & 100

		if ( $redirectUri )
			//if ( !\in_array( $redirectUri, $allowedRedirectUris ) )
			//	throw new \IPS\Login\Handler\OAuth2\InitException('oauth_err_invalid_redirect_uri');
				$obj->redirectUri = \IPS\Http\Url::external( $redirectUri );

/oauth/token/index.php 312 - 316
	/* Check we are not IP banned */
	//$ipBanned = \IPS\Request::i()->ipAddressIsBanned();
	//if ( $ipBanned )
	//	throw new \IPS\Login\Handler\OAuth2\Exception( 'invalid_client', "IP Address banned" );

/system/Dispatcher/Api.php comment out line 74
			/* Check our IP address isn't banned */


Link to comment
Share on other sites

Just now, Marc Stridgen said:

You would need to ensure no files are modified in order to gain assistance with your suite. 

Note, we would not advise on commenting out of items as you are above.

That I cannot do.

You can restore the original during testing, but after that I am forced to modify them again.

If you're unable to do that, then I will have to work with a 3rd party on resolving this issue.

Link to comment
Share on other sites

Since you mentioned the above, I am unsure why those options are not selected. I have not changed any settings there, and they should be made mandatory if it causes issues.


Selecting "Ask the user to provide a display name" still skips the display name requirement when signing up/in via OAuth.

Selecting "Google account name" automatically uses the Google account's name when registering via OAuth so that at least solves the incomplete account problem.


The same issue seems to happen with Twitter sign in too.


If we make the user enter a display name when creating a new account in the OAuth login, then the display name is never asked for and just gets redirected back to the OAuth site/app.

Link to comment
Share on other sites

  • Recently Browsing   0 members

    • No registered users viewing this page.
  • Create New...