New registrations via Oauth causing incomplete members

[David..]

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".

[Marc]

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. 

[David..]

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?

[Marc]

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

[David..]

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.

[Jim M]

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.

[David..]

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');
			//}
			//else
			//{
				$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 */
			//$this->_checkIpAddressIsAllowed();

 

[Marc]

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.

[David..]

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.

[Marc]

Twitter we are seeing no issue with, however googles you dont actually have the option selected, which is why you are having issues.

We cannot assist with modified software, and we would not advise on the above in any case as you are commenting out security related items.

[David..]

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.

Regardless:

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.

[Marc]

Please could you provide step by step as to how you are signing up? I know that sounds a strange request, but we are not able to replicate it on your site. When you attempt signup with twitter, it is indeed asking.

Also, note we cannot assist further with modifications in place