Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Facebook provider stores user's non unique name as strapi unique username #6014

Open
negati-ve opened this issue Apr 30, 2020 · 8 comments
Open
Labels
good first issue severity: low source: plugin:users-permissions status: confirmed

Comments

@negati-ve
Copy link

@negati-ve negati-ve commented Apr 30, 2020

Describe the bug
After going through the facebook provider auth flow via /connect/facebook
the callback stores the user's facebook non unique name as the user's unique strapi username

In strapi-plugin-users-permissions/services/Providers.js > getProfile
line 174

facebook
        .query()
        .get('me?fields=name,email')
        .auth(access_token)
        .request((err, res, body) => {
          if (err) {
            callback(err);
          } else {
            callback(null, {
              username: body.name,
              email: body.email,
            });
          }
        });

There seem to be many Jim Laurie on facebook
This would mean that only one Jim Laurie could ever sign up on the site via facebook
Steps to reproduce the behavior

  1. login through facebook provider with 2 accounts with the same name

Expected behavior
username should be unique in case user logs in through facebook
Ideally, the user's profile url/handle would be the perfect fit for username
Although, this isn't available through graph api.

So the best bet is to use the user's facebook user id as his/her username

Code snippets
quick fix by dropping a customization in extensions/users-permissions/services/Providers.js

facebook
        .query()
        .get('me?fields=id,email')
        .auth(access_token)
        .request((err, res, body) => {
          if (err) {
            callback(err);
          } else {
            callback(null, {
              username: body.id,
              email: body.email,
            });
          }
        });
@lauriejim lauriejim added good first issue severity: low source: plugin:users-permissions status: confirmed labels May 7, 2020
@lauriejim
Copy link
Member

@lauriejim lauriejim commented May 7, 2020

Thank you for reporting this issue.
I ping @Aurelsicoko and @alexandrebodin about this issue.

There is a workaround for this issue.

DO NOT update the extensions/users-permissions/models/User.settings.json to update the require: false of the username field.
This field could be used for the auth.

BUT you can create a new field name for example.
And the use the customization concept to update this function as you did in your Code snippets section.

@Dannymx
Copy link

@Dannymx Dannymx commented Jul 10, 2020

I agree, as I tested the registration I found users when they register they could easily find their username was already taken. An option to make this non-unique or have another field as the username would be nice to have.

@alexandrebodin
Copy link
Member

@alexandrebodin alexandrebodin commented Jul 15, 2020

We already discussed this in another issue (can't find it) I think we should use the email as unique identifier and let the username be whatever the user wants.

@Aurelioolive
Copy link

@Aurelioolive Aurelioolive commented Dec 10, 2020

I think that email could be the unique identifier. It would even be interesting if, when registering a user via Facebook (or other provider), he checked if the same email address already exists in the registered database to associate Facebook Login with the already registered user.

@dotamir
Copy link

@dotamir dotamir commented Apr 23, 2021

Is anyone up to this issue? If not, I can work on this issue if that's okay?

@Aurelioolive
Copy link

@Aurelioolive Aurelioolive commented Apr 23, 2021

Is anyone up to this issue? If not, I can work on this issue if that's okay?

Do a PR =]

MrMossevig added a commit to vulkaza/strapi that referenced this issue May 28, 2021
… not taken. Fixes in a non-breaking way (among others) strapi#6014
@MrMossevig
Copy link

@MrMossevig MrMossevig commented May 28, 2021

I added a PR for this. In short itis an added check in Providers.js that checks if the username is taken. If it is taken it adds a random suffix to the username.
I opted for tilde (~) as the separator as that works best with "real" usernames. Facebook names would look better with a psce and a hash(#) but facebook is not using the "real" username atm, I think it would be better to use the username (the one in the title bar on a profile page) for username from Facebook, but there might be a problem with this?

Anyway if anyone ends up here and want the quick fix:
Create a file: extensions/users-permissions/services/Providers.js
Add this to the top:

const crypto = require('crypto');

// Same random suffix as used in upload
const randomSuffix = () => crypto.randomBytes(3).toString('hex');

And this between "Retrieve default role" and "Create the new user":

        // Check if a user with the username exists
        var usernames = await strapi.query('user', 'users-permissions').find({
            username: profile.username,
          });

        // Add a new #randomsuffix to the username till we find one that is not taken
        var newUsername;
        while(!_.isEmpty(usernames)) {
            newUsername = `${profile.username}~${randomSuffix()}`;
            usernames = await strapi.query('user', 'users-permissions').find({
                username: newUsername,
              });
        }

        // Set the updated username
        profile.username = newUsername;

@derrickmehaffy derrickmehaffy added this to To be reviewed (Open) in Developer Experience via automation Jan 5, 2022
@omkarg01
Copy link

@omkarg01 omkarg01 commented Feb 9, 2022

@derrickmehaffy I would like to work on this issue.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
good first issue severity: low source: plugin:users-permissions status: confirmed
Projects
Developer Experience
To be reviewed (Open)
Development

No branches or pull requests

8 participants