Prevent redirect after associate an account

  • Resolved guilhermexrs

    (@guilhermexrs)


    3 months ago

    Hello team

    I am encountering an issue where users are redirected to /wp-login.php after associating their accounts. In my scenario, I only need to retrieve the user’s information (email and username) and prevent the redirect to /wp-login.php, keeping the user on the same page.

    I want something like it:
    add_action('nsl_before_register', function ($provider) {
    add_filter('nsl_registration_user_data', function($userdata, $provider, $error) {
    // get $userdata infos;
    }, 10, 3);
    exit; // to prevent redirect
    });

    Thanks!

Viewing 4 replies - 1 through 4 (of 4 total)
  • Plugin Support Laszlo

    (@laszloszalvak)

    Hi @guilhermexrs

    I think your problem is that you ask extra information from the user before the registration with social login ( e.t. consent to your Terms and Conditions – Privacy tab: https://nextendweb.com/nextend-social-login-docs/global-settings-privacy/ ). By default the WordPress default login form ( /wp-loginl.php ) is where we present the form with this data requested. Once the user finishes the registration there, we will redirect the user back to the same page where the social login was pressed.

    If you don’t want this extra step, so the registration should happen instantly then you need to make sure you don’t request any extra information before the registration with social login, so you should turn off the Terms and Conditions setting as well. But please keep in mind that, this setting is necessary if you want the social login to be GDPR compliant! – https://nextendweb.com/nextend-social-login-docs/gdpr/
    Note: Our Pro Addon also have some options to request even more data, however on this forum we are only allowed to discuss topics about the Free version as per the Forum Guidelines, so if you are a Pro Addon user, then please get in touch with us directly over the ticket system: https://nextendweb.com/contact-us/nextend-social-login-support/

    Or in that case, if you don’t really want to skip this step, just you don’t want the extra data to be requested over the /wp-login.php page, then you should use the “Page for register flow” setting, that you should configure in the following way:

    This way, extra information before the registration with social login would be asked on this page.

    Please make sure you don’t use this page for anything else, since we will try to reserve it for ourselves, and if third parties try to use it that could cause a conflict.

    Thread Starter guilhermexrs

    (@guilhermexrs)

    Hi @laszloszalvak

    Actually, my issue is different. I’m using a shortcode on a page other than /wp-login.php. What I want is to retrieve the user’s email and username information when they associate their account (Google or Facebook) without redirecting them to /wp-login.php.

    Example: when the user login with facebook or google, fill the email field with the retrieved email without redirecting and log in the user in the application

    https://ibb.co/pZXYZTX

    I can achieve it?

    Plugin Support Laszlo

    (@laszloszalvak)

    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:

    1. 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
    2. then the the provider redirects the user back to your site, with OAuth state and codes
    3. using this data we can make another requests to get an access token
    4. the provider returns the access token
    5. 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.

    Thread Starter guilhermexrs

    (@guilhermexrs)

    Thanks, @laszloszalvak!
    I’ll try other approaches.

Viewing 4 replies - 1 through 4 (of 4 total)
  • You must be logged in to reply to this topic.