duplicate rows in Session when using Parse.User.logInWith

[alexmnguyen]

Issue Description

When I sign in successfully with oauth, a new object in Session is always created and createdWith.action is always "signup". The user and installationId are identical among all the objects. I would expect the duplicate user and installationId pairs to not be present, based on the following documentation:

There is one distinct Session object for each user-installation pair; if a user issues a login request from a device they’re already logged into, that user’s previous Session object for that Installation is automatically deleted.

Furthermore, I would expect the action to be 'login' rather than 'signup' every time. The sessionToken is unique among each of the rows. Below is a screenshot from parse-dashboard for Session:

Steps to reproduce

1. Obtain google oauth credentials for id and auth_token.

2. Create a payload for authData:

   var authData = {
     authData: {
       id: profile.getId(),
       access_token: authResponse.id_token
     }
   }

3. use the logInWith function and use the built in 'google' provider:

   Parse.User.logInWith('google', authData).then(function(user){
     console.log(user);
   }, function(error){
     if(error.code === Parse.Error.INVALID_SESSION_TOKEN){
       Parse.User.logOut();
     }
     console.log(error);
   })

4. Repeat this steps 1 - 3 multiple times. For example, 5 times.

Expected Results

There should only be one Session object for this user and installationId combination. The createdWith.action property should be 'login' and not 'signup'.

Actual Outcome

If the Steps to reproduce were run 5 times, there would be 5 new objects in Session, 4 of which should not exist according to the documentation. The createdWith.action property will also be 'signup' for all of them.

Environment Setup

• Server
  • parse-server version (Be specific! Don't say 'latest'.) : 2.2.22
  • Operating System: Centos on Vagrant. Vagrant host is Windows 10 64 bit.
  • Hardware: Virtual Machine
  • Localhost or remote server? (AWS, Heroku, Azure, Digital Ocean, etc): localhost
• Database
  • MongoDB version: 3.2.10
  • Storage engine: WiredTiger
  • Hardware: Docker running in vagrant
  • Localhost or remote server? (AWS, mLab, ObjectRocket, Digital Ocean, etc): localhost

Logs/Trace

You can turn on additional logging by configuring VERBOSE=1 in your environment.

This is the output when I attempt to sign in with VERBOSE=1. I've replaced the actual profile id, access_token and session string with variables.

 REQUEST for [POST] /parse/users: {
  "authData": {
    "google": {
      "id": "profile_id",
      "access_token": "token"
    }
  }
} method=POST, url=/parse/users, host=localhost:1337, connection=keep-alive, content-length=1411, origin=http://localhost:1337, user-agent=Mozilla/5.0 (Windows NT 10.0; WOW64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/53.0.2785.143 Safari/537.36, content-type=text/plain, accept=*/*, referer=http://localhost:1337/, accept-encoding=gzip, deflate, accept-language=en-US,en;q=0.8, cookie=G_AUTHUSER_H=0, id=profile_id, access_token=token
verbose: RESPONSE from [POST] /parse/users: {
  "response": {
    "objectId": "T0YbALsHFN",
    "username": "PtQJbHIr5p1yXk0FSokImxSYE",
    "authData": {
      "google": {
        "id": "profile_id",
        "access_token": "token"
      }
    },
    "createdAt": "2016-10-19T01:48:53.439Z",
    "updatedAt": "2016-10-19T07:13:44.190Z",
    "emailVerified": false,
    "ACL": {
      "*": {
        "read": true
      },
      "T0YbALsHFN": {
        "read": true,
        "write": true
      }
    },
    "sessionToken": "r:session_token"
  },
  "location": "http://localhost:1337/parse/users/T0YbALsHFN"
} objectId=T0YbALsHFN, username=PtQJbHIr5p1yXk0FSokImxSYE, id=profile_id, access_token=token, createdAt=2016-10-19T01:48:53.439Z, updatedAt=2016-10-19T07:13:44.190Z, emailVerified=false, read=true, read=true, write=true, sessionToken=r:session_token, location=http://localhost:1337/parse/users/T0YbALsHFN

[flovilmart]

Thanks for the detailed report! We'll look into the issue when we have some time. Otherwise, if you feel like it, you can propose a fix.

[flovilmart]

@alexmnguyen I managed to find some time to isolate and fix the issue. should be available in next release!