Love Fuel?    Donate

FuelPHP Forums

Ask your question about FuelPHP in the appropriate forum, or help others by answering their questions.
opauth + google-strategy is not returning nickname
  • In opauth example
    $user_hash = \Session::get('auth-strategy.user', array());

    'username' => \Arr::get($user_hash, 'nickname'),
    'fullname' => \Arr::get($user_hash, 'name'),
    'email' => \Arr::get($user_hash, 'email'), ));
    When i am doing
    var_dump(Session::get('auth-strategy', array()))
    I get this
    array (size=2)
    'user' =>
    array (size=5)
    'name' => string 'Amit Yadav' (length=10)
    'email' => string 'amityadav4a@gmail.com' (length=21)
    'first_name' => string 'Amit' (length=4)
    'last_name' => string 'Yadav' (length=5)
    'image' => string 'https://lh3.googleusercontent.com/-HsEgUTlIKiU/AAAAAAAAAAI/AAAAAAAABOg/HgLKL83tJuo/photo.jpg' (length=92)
    'authentication' =>
    array (size=6)
    'provider' => string 'Google' (length=6)
    'uid' => string '10158226211236524812' (length=21)
    'access_token' => string 'ya28.1.AADtM_XK3D5dJGijeqQK-EyvPpR4bhmR3kAv-fc_4wNWHTtstzeKO9f8HAlm8Skq7Q' (length=73)
    'secret' => null
    'expires' => string '2014-03-06T13:05:52+00:00' (length=25)
    'refresh_token' => null

    No nickname field is returned.

  • The Fuel Opauth class doesn't do anything with the data received, other than passing it through.
    So it's either an issue of Opauth (the composer package), or of the connection with Google).

    nickname is part of the info collection, with is stored in the session in the 'user' part of the array.
  • Google  OAuth 2.0 Returns
    array (size=10)
    'id' => string '10158226211236524812' (length=21)
    'email' => string 'amityadav4a@gmail.com' (length=21)
    'verified_email' => boolean true
    'name' => string 'Amit Yadav' (length=10)
    'given_name' => string 'Amit' (length=4)
    'family_name' => string 'Yadav' (length=5)
    'link' => string 'https://plus.google.com/+AmitYadav4a' (length=36)
    'picture' => string 'https://lh3.googleusercontent.com/-HsEgUTlIKiU/AAAAAAAAAAI/AAAAAAAABOg/HgLKL83tJuo/photo.jpg' (length=92)
    'gender' => string 'male' (length=4)
    'locale' => string 'en-GB' (length=5)
    ie we don't have nickname to create new user. So we will redirect user to registration. Now if user with same email id is present in our system in this condition we wont be able to create new user or link this account to already registered user.

    Even i can not find any condition in which email id is compared to check if user with same email id is present or not.
  • What do you suggest? Use email if nickname is not present?
  • Yes i think using email will do. As every provider will return email id.

    I have suggestion
    If account is linked to any local account do force_login().

    else if find user with email and if user exist link this account.

    else redirct to registration page.

    There should be a check that login_or_register() should not be called(or redirect back if user is logged in). As if user is logged in and if user logged in to some other social account and by any chance login_or_register() is called it will directly link that account to this local account.

  • I will have a look.

    As to the current behaviour, I believe that is correct. If someone is already logged in, and an attempt is made to login again, it is to link the two. It is up to your application to block access to the login page (a "you are already logged in" message, or a forced logout of the current user) if you don't want this behaviour.
  • According to this multiple account of same provider can be linked. But still that problem of user with same email id persist.

    In case user has used remember me in our application and someone else has logged in to his social account (on same browser) and if this user tries to login to our application using opauth, now this account will get linked.
  • A user with the same email is the same user? Or do I miss your point?

    And I'd say your application design is wrong. If someone is logged in to the application (as user X) and someone else is logged into facebook at the same time (say user Y), nothing happens. Something only happens when the person sitting behind the PC (either user X or Y) clicks on your applications "Login via facebook" link, which should not be there when someone is already logged in (and you don't want this behaviour).

    I'll go even further, if you have users that enable "remember me" on a PC that can be categorized as "public" (given your statement of multiple users of the same browser session), you have a big security issue with your application.
  • Yes same email is the same user. As nickname is not returned we are redirecting user to register but email is already present user wont be able to register.

    Correct I got your point that i have to design application where i will control "Link via Facebook". That Public PC Security need to be controlled by the users of the application.
  • I understand that it has to change to "nickname or email", that should work if you change that code to:

    // did the provider return enough information to log the user in?
    if (($this->get('auth.info.nickname') or $this->get('auth.info.email')) and $this->get('auth.info.password'))
    {
        // make sure we have a nickname
        if (empty($this->response['auth']['info']['nickname']))
        {
            $this->response['auth']['info']['nickname'] = $this->response['auth']['info']['email'];
        }

    Can you see if that works for you? I don't have time to setup a test at the moment.
  • This code works for nickname .

    But if user with same email id is already registered, which opauth returns

    if i am linking two account using this config
    'auto_registration' => true

    ormauth is throwing email address already exists.

    and if 'auto_registration' => false

    Auth::create_user() is throwing duplicate email address.

    I think if we search for email if it is registered, link that.
  • Yes, the code that checks if a nickname exists should also check for the email. Haven't looked at that yet, wanted to fix this first.
  • That can not be avoided, you have the same with providers that do provide a nickname.

    If no user is logged in, and you have auto_registration enabled, it will attempt to do so. It has no way of knowing both users are the same physical person.

    So when this happens, you need capture it, and display a message "an account with this name already exists, please login first before linking your <provider> account" and provide the option to login.

    Once logged in, you have a valid user, and they can use another provider login to link that one.
  • Yes this will work. But user almost use same email to link with different accounts.

    We can show username is not available if same username is found.

    And we can link account with same email ID.
  • What you think as i suggested earlier
    If account is linked to any local account do force_login().

    else if find user with email and if user exist link this account.
    (user almost use same email to link with different accounts.)

    else redirct to registration page
    (On registration page we can show username is not available if same username is found.)

    Will this approach solve this problem?
  • I think that is a very bad idea.

    If you implement something like this, I can create a fake account somewhere that has someone else's email address, with which I can steal that persons account in your application without knowing the password.

    Nobody is stopping you from implementing this in your application, when you get a "register" back you can do the above yourself instead of show a registration page.

    But is will not be part of the Auth package functionality.
  • Yes correct that can be a case. sorry I dint considered that.

    But i think we need to address this problem in auth package

    if user with same email id is already registered, which opauth returns

    if i am linking two account using this config
    'auto_registration' => true

    ormauth is throwing email address already exists.


  • You should only use auto_registration if you don't care about local account, and you don't want to link accounts. It's there for simple "login using twitter" kind of scenario's.

    You shouldn't use it for more complex situations.
  • Sure it will do the work.

    I will go with your solution "So when this happens, you need capture it, and display a message "an
    account with this name already exists, please login first before linking
    your <provider> account" and provide the option to login."

    It should be specified somewhere in documentation or FAQ for such situations when to use auto_registration.
  • Harro VertonHarro Verton
    Accepted Answer
    Not a bad idea. I'll think about it. Or, you can send in a pull request for it?
  • Pull request sent.

Howdy, Stranger!

It looks like you're new here. If you want to get involved, click one of these buttons!

In this Discussion