Sorry @guilhermexrs I see what you mean now. Unfortunately that is not possible, and on the other hand it wouldn’t work anyways, since some providers won’t always return the email address – e.g. Facebook gives users an option to hide their email. In our case this isn’t a problem, as we also get the social media ID, that we can link to a WordPress account, and based on this link, we could identify the connection between WordPress and Social media accounts.
And another thing that you need to know is that, our registration and login has nothing to do with the form that appears around the social buttons. So although our button appears there, it won’t have any connection to your form, as we handle the registration and login in our own way and the data that we temporarily store – before the registration/login with the social media account actually happens-, is only accessible within our flow. Once you exit our flow, the temporary data that we retrieved from the API, will no longer be available ( of course if we actually registered an account the data we stored for the account will be there just fine ), so you can not fill out third party registration forms with our data, unless you stored them in some way while you were still inside our flow- e.g. via cookies.
But even if you would do that, you couldn’t avoid the initial redirect:, e.g.:
since that is the endpoint of a Nextend Social Login provider – e.g. the link above is the OAuth endpoint of our Google provider -, that starts the actual OAuth flow, where:
- the user gets redirected to the official authorization endpoint of the provider where the user has to authenticate with their social media account and then authorize your App, so it can make requests on behalf of the user
- then the the provider redirects the user back to your site, with OAuth state and codes
- using this data we can make another requests to get an access token
- the provider returns the access token
- we use the access token to get the user data
Once we have the user data 2 things can happen ( by the way at this point the user is still inside our OAuth flow on an URL like this /wp-login.php?loginSocial=google&state=…&code=…&… ):
- A.) we log the user in to an account ( either to a new account that we registered or an existing one ), and after that we redirect to a page
- B.) we redirect to a page and display an error
So as you can see this 2nd redirect is also mandatory, as this is what leads to leaving the register flow page ( if you ask extra information before the registration with social login ) or the page where the OAuth communication was handled.
Note: The /wp-login.php part of the endpoint can be modified via the “OAuth redirect uri proxy page” feature:
so we can handle the OAuth flow and the background communication with the APIs of the provider on another page that you don’t use for anything else. But the user won’t really perceive anything from this. Changing the /wp-login.php to something else is suggested only if there are conflicts with third parties, e.g. when a plugin hides the /wp-login.php, or modifies its URL, and you don’t want the new URL to be exposed.
This answer become a little bit long, but I just wanted to describe this process a little bit more, so you will see it is more complex than it seems.
Best regards,
Laszlo.