Every facebook login creates a new user

[rafapetter]

Issue
Every time I try to login through facebook a new user is created on mongo. I've also noticed there's no column _auth_data_facebook saved on these users.

Prerequisites

• I've migrated to AWS Elastic Beanstalk(64bit Amazon Linux 2015.09 v2.0.7, running Node.js 4.2.3) and MongoLab
• I'm running the 2.1.4 of Parse Server.
• I'm testing on Android SDK

Steps to reproduce on Android

• I've changed the endpoint from parse API to my parse server
• Installed the app
• Tried to facebook login
• After successful facebook authentication a new user is created on mongo with no auth data.

Log from Verbose
Here we can see that authData is sent through POST

POST /parse/users { host: 'parseserver-xxxx-env.elasticbeanstalk.com',
  'x-real-ip': 'xxxxx',
  'x-forwarded-for': xxxxx',
  'content-length': '326',
  'accept-encoding': 'gzip',
  'content-type': 'application/json',
  'user-agent': 'Parse Android SDK 1.13.0 (com.xxx.xxxx/7) API Level 21',
  'x-newrelic-id': 'xxxxx==',
  'x-parse-app-build-version': '7',
  'x-parse-app-display-version': 'xxxx',
  'x-parse-application-id': 'xxx',
  'x-parse-client-key': 'xxx',
  'x-parse-client-version': 'a1.13.0',
  'x-parse-installation-id': 'xxxxx',
  'x-parse-os-version': '5.0.2',
  'x-forwarded-port': '80',
  'x-forwarded-proto': 'http' } {
  "authData": {
    "facebook": {
      "access_token": "xxxxxxxxxx",
      "expiration_date": "2016-05-08T16:31:45.008Z",
      "id": "xxxxxxxxx"
    }
  }
}

Possible Similar Issues

• authData:facebook vs _auth_data_facebook? #755
• beforeSave Parse.User: after facebook sign up clears attributes. #880

[flovilmart]

This is totally normal that authData is stored as _auth_data_facebook in mongodb.

Can you make sure, there is never a POST /users with "authData": {
"facebook": null
}

Does this problem occurs after setting a property on the user?

[rafapetter]

Ok, but I'm saying that there's no column _auth_data_facebook.

I've searched the entire log for this "facebook": null, and it only occurs on GET calls from username/password logins. So to facebook login POST calls this never happen.

The problem occurs weather I set a property or not, I've tested both cases. I assume it's a problem during the ParseFacebookUtils.logInWithReadPermissionsInBackground call in which the user authdata format is being handled different from how is done on Parse API.

[flovilmart]

when you run with VERBOSE=1 and do ParseFacebookUtils.logInWithReadPermissionsInBackground, what is the request that you have. (GET or POST)

Then you say:

I've searched the entire log for this "facebook": null, and it only occurs on GET calls from username/password logins. So to facebook login POST calls this never happen.

This is really important, that means that the Facebook auth gets unlinked when you call login. Could you provide the logs when running VERBOSE=1 as well for this case?

[rafapetter]

Ok, I'm gonna show you 2 cases: 1) user login with facebook for the first time; 2) reinstall app, and the same user try to login again with facebook

1) Login is successful, but missing the authData on mongodb. Here's the Verbose sequence:

POST /parse/users { host: 'parseserver-xxxx-env.elasticbeanstalk.com',
  'x-forwarded-proto': 'http' } {
  "authData": {
    "facebook": {
      "access_token": "xxxxx",
      "expiration_date": "2016-05-08T16:31:45.428Z",
      "id": "xxxxxxx"
    }
  }
}
response: {
  "status": 201,
  "response": {
    "objectId": "xxxxxx",
    "createdAt": "2016-03-09T18:38:40.328Z",
    "sessionToken": "r:xxxxxxxxxx"
  },
  "location": "http://parseserver-xxxxx-env.elasticbeanstalk.com/parse/users/xxxxxx"
}

GET /parse/classes/_User/xxxxx { host: 'parseserver-xxx-env.elasticbeanstalk.com',
  'x-forwarded-proto': 'http' } {}
response: {
  "response": {
    "objectId": "xxxxxx",
    "sessionToken": "r:xxxxxxx"
  }
}

2) Login is successful, but a new user is created on mongodb. Here's the Verbose sequence:

POST /parse/users { host: 'parseserver-xxxx-env.elasticbeanstalk.com',
  'x-forwarded-proto': 'http' } {
  "authData": {
    "facebook": {
      "access_token": "xxxx",
      "expiration_date": "2016-05-08T16:31:45.378Z",
      "id": "xxxx"
    }
  }
}
response: {
  "status": 201,
  "response": {
    "objectId": "xxxxx",
    "createdAt": "2016-03-09T18:41:06.368Z",
    "sessionToken": "xxxxxx"
  },
  "location": "http://parseserver-xxxx-env.elasticbeanstalk.com/parse/users/xxxxx"
}

GET /parse/classes/_User/xxxxx { host: 'parseserver-xxxx-env.elasticbeanstalk.com',
  'x-forwarded-proto': 'http' } {}
response: {
  "response": {
    "objectId": "xxxx",
    "sessionToken": "r:xxxxx"
   }
}

[DrBeak1]

Something weird is happening for sure with Facebook signup/login. I'm getting similar issues trying to login/auth via ios. I have parse-server running on heroku, using the most up-to-date versions of both the parse-ios cocoapod and parse-server.

From what I can tell when I auth w/Facebook I can see that PFFacebookPrivateUtilities (an ios class) is returning valid credentials, but those credentials never make it to mongoDB.

I've found that (a) removing any beforeSave calls in cloud code stops the issue of duplicate users being created when trying to auth with the same Facebook account however, (b) once a user logs in with Facebook they cannot do anything with their associated objects (i.e., edit their user name, edit owned objects, etc); parse returns the error: 'cannot modify user xxxxxxx'. For more details you can see my ticket: #880

[rafapetter]

Hi @DrBeak1, yep I'm having the same issue on iOS too.

[DrBeak1]

Still an issue with parse-server 2.1.5

[flovilmart]

@DrBeak1 your problem is on iOS right? What method do you use for login?

[flovilmart]

@weengo I'm not sure about Android. in case 1) is Parse.User.currentUser() set correctly? Can you access it's objectId? does the objectId match with what you see in the logs? does the session token match with what you see in the logs?

That may be easier to debug for you if you were running locally from the repository directly.
So far, I've tried different things in unit tests, and I can't reproduce at all this issue.

[DrBeak1]

Hey @flovilmart -

Using ParseFacebookUtilsV4 (1.11.1):
logInInBackgroundWithReadPermissions: -- and I'm requesting email, user_location, and user_friends

This method succeeds, returning a user with the correct objectId, a new session token, and an access token for facebook (may be old, it matches the old one stored on my user obj in mongodb. but the one on mongodb is not being updated because my users updatedAt field is a few days old). However, this data does not get relayed to mongoDB. If I go there after login, I can see that the session token is different for this user. Therefore, any attempts to modify user owned data afterwards fails with the 'cannot modify user user_id'

[michaelbina]

I think this is related to my other issue #755

[tanmays]

@flovilmart

This is totally normal that authData is stored as _auth_data_facebook in mongodb.

Can you make sure, there is never a POST /users with "authData": {
"facebook": null
}

I pass authData: {"twitter": null} to unlink a twitter account according to this doc.

For users that have unlinked and linked again database contains _auth_data_twitter as well as authData, where authData is shown as "twitter": null and _auth_data_twitter is correctly populated. However in parse dashboard authData column is incorrectly populated as "twitter": null

Accounts that have not been previously unlinked have only _auth_data_twitter field, the authData field is absent on mongolab database browser in these cases. In the parse dashboard authData column is correctly populated in this case.

This does not cause any issue for me and everything is still working correctly. I think the authData dict should be removed after an unlink request has been passed so that when user links again the parse dashboard will correctly populate the authData field.

[flovilmart]

I just opened #952 that include a 'small' refactoring of the OAuth procedure, as I uncovered a series of weird things there. For the ones running on a local server, please checkout that branch, and run against it.

We definitely could remove the authData dict when you unlink, we could also delete the key