User is always being detected as new when logged in through Facebook, Twitter, or Google #7737

Meglali20 · 2021-12-08T00:06:27Z

New Issue Checklist

I am not disclosing a vulnerability.
I am not just asking a question.
I have searched through existing issues.
I can reproduce the issue with the latest version of Parse Server.

Issue Description

-A user is being detected as new when he isn't.
-authData field being deleted for unknown reasons.

Steps to reproduce

Add the following code to the cloud code and try to login using Facebook, Twitter, or Google.

Parse.Cloud.afterSave(Parse.User, async (request) => {
    if (!request.original) {
       "need to perform some actions here when a user has just signed up"
      }
});

Actual Outcome

This issue leads to performing unwanted actions over a non new user.
After a user performs a login/signup through Facebook, Twitter, or Google, the user is always being detected as a new user in afterSave.
When checking again in the database you can see that the same user has just logged in and it's not a new one,
Noticed also something with the authData field, when testing login with different methods the authData is being erased(doesn't happen all the time).

Expected Outcome

Not detect a user as a new one when he isn't.

Environment

Server

Parse Server version: [email protected]
Operating system: Windows 10
Local or remote host (AWS, Azure, Google Cloud, Heroku, Digital Ocean, etc): Local

Database

System (MongoDB or Postgres): MongoDB
Database version: FILL_THIS_OUT
Local or remote host (MongoDB Atlas, mLab, AWS, Azure, Google Cloud, etc): MongoDB Atlas

Client

SDK (iOS, Android, JavaScript, PHP, Unity, etc): Android
SDK version: 1.26.0

Logs

The text was updated successfully, but these errors were encountered:

parse-github-assistant · 2021-12-08T00:06:49Z

Thanks for opening this issue!

❌ Please fill out all fields with a placeholder FILL_THIS_OUT, otherwise your issue will be closed. If a field does not apply to the issue, fill in n/a.

mtrezza · 2021-12-08T00:47:39Z

Can you please correct your example code and provide a full example to reproduce the issue, including user creation.

Meglali20 · 2021-12-08T01:02:27Z

@mtrezza
The code I am performing in afterSave is just the creation of data related to the user in other classes, the code works fine when the user signs up or login/edit his information using the parse-server method, you can just print a message inside the condition where you check if the user is new or no.

Parse.Cloud.afterSave(Parse.User, async (request) => {
    if (!request.original) {
       console.log("user just signed up");
      }
    else{
        console.log("user updated");
      }
});

from the client-side this is a an example of Twitter login

 
    binding.twitterLoginButton.setOnClickListener(view -> ParseTwitterUtils.logIn(MainActivity.this, new LogInCallback() {
            @Override
            public void done(ParseUser user, ParseException err) {
                if (user == null) {
                    Timber.i("Uh oh. The user cancelled the Twitter login.");
                } else if (user.isNew()) {
                 startActivity(new Intent(MainActivity.this, WelcomeUserActivity.class));
                    Timber.i("User signed up and logged in through Twitter!");
                } else {
               startActivity(new Intent(MainActivity.this, HomeActivity.class));
                    Timber.i("User logged in through Twitter!");
                }
                if (err != null) {
                    Timber.e("ERROR TWITTER LOGIN " + err.getMessage());
                }
            }
        }));

From the client-side when a user is already signed up it performs the required action as the user isn't new but from the server-side there is the issue I opend.

mtrezza · 2021-12-08T10:17:46Z

Since you say this is a server issue, are you able to reproduce this solely in Cloud Code (or via the REST API) without using the client? That way you could add a failing test and we can exclude the client as a source of error.

Meglali20 · 2021-12-08T10:56:26Z

@mtrezza is it possible to perform twitter or google login using REST API or in cloud code? if yes, how so I can test it. what made me think that it's a problem from the server side is when I change the information of a normal user from the client-side and save it from the client it's working correctly. also when using (all 3 alternative login methods Facebook, Twitter, and Google) the problem occurs but not with a normal account.

mtrezza · 2021-12-08T18:46:06Z

In Cloud Code you would do it like you'd do it using the Parse JS SDK.

Meglali20 · 2021-12-09T13:12:40Z

I tried Facebook login with the Parse JS SDK, the same issue occurs. Tried to run a fail test but I keep getting this error

npm run coverage

> [email protected] coverage C:\Users\megla\Desktop\Parse\parse-server
> cross-env MONGODB_VERSION=${MONGODB_VERSION:=4.4.10} MONGODB_TOPOLOGY=${MONGODB_TOPOLOGY:=standalone} MONGODB_STORAGE_ENGINE=${MONGODB_STORAGE_ENGINE:=wiredTiger} TESTING=1 nyc jasmine

internal/modules/cjs/loader.js:491
  throw new ERR_PACKAGE_PATH_NOT_EXPORTED(basePath, mappingKey);
  ^

Error [ERR_PACKAGE_PATH_NOT_EXPORTED]: Package subpath './public/extractFiles.js' is not defined by "exports" in C:\Users\megla\Desktop\Parse\parse-server\node_modules\extract-files\package.json
    at applyExports (internal/modules/cjs/loader.js:491:9)
    at resolveExports (internal/modules/cjs/loader.js:507:23)
    at Function.Module._findPath (internal/modules/cjs/loader.js:635:31)
    at Function.Module._resolveFilename (internal/modules/cjs/loader.js:1007:27)
    at Function.Module._load (internal/modules/cjs/loader.js:890:27)
    at Module.require (internal/modules/cjs/loader.js:1080:19)
    at require (internal/modules/cjs/helpers.js:72:18)
    at Object.<anonymous> (C:\Users\megla\Desktop\Parse\parse-server\node_modules\@graphql-tools\links\node_modules\apollo-upload-client\public\createUploadLink.js:13:22)
    at Module._compile (internal/modules/cjs/loader.js:1176:30)
    at Module.replacementCompile (C:\Users\megla\Desktop\Parse\parse-server\node_modules\append-transform\index.js:60:13) {
  code: 'ERR_PACKAGE_PATH_NOT_EXPORTED'
}

=============================== Coverage summary ===============================
Statements   : 8.74% ( 1028/11757 )
Branches     : 0.48% ( 37/7629 )
Functions    : 1.01% ( 23/2277 )
Lines        : 8.84% ( 1027/11618 )
================================================================================
npm ERR! code ELIFECYCLE
npm ERR! errno 1
npm ERR! [email protected] coverage: `cross-env MONGODB_VERSION=${MONGODB_VERSION:=4.4.10} MONGODB_TOPOLOGY=${MONGODB_TOPOLOGY:=standalone} MONGODB_STORAGE_ENGINE=${MONGODB_STORAGE_ENGINE:=wiredTiger} 
TESTING=1 nyc jasmine`
npm ERR! Exit status 1
npm ERR!
npm ERR! Failed at the [email protected] coverage script.
npm ERR! This is probably not a problem with npm. There is likely additional logging output above.

npm ERR! A complete log of this run can be found in:
npm ERR!     C:\Users\megla\AppData\Roaming\npm-cache\_logs\2021-12-09T15_53_34_413Z-debug.log

mtrezza · 2021-12-10T14:27:54Z

Could you open a PR with the failing test that demonstrates the issue?

Meglali20 · 2021-12-10T16:57:16Z

@mtrezza sure I would like to do that, I even tried to do it check my previous comment, I keep getting the same error any idea on how to proceed?

mtrezza · 2021-12-11T00:01:54Z

try to use npm test spec/<filename>.spec.js to run the test; again I suggest you publish your test in a PR so we can take a look at it, maybe the error comes from there

Meglali20 · 2021-12-11T00:10:24Z

try to use npm test spec/<filename>.spec.js to run the test; again I suggest you publish your test in a PR so we can take a look at it, maybe the error comes from there

even when I don't edit anything (trying to run a test over the cloned repo without modification) and try to run a test i get the same error, when I try to run a test on a specific file I get the following error

npm test spec/CloudCode.spec.js

> [email protected] pretest C:\Users\megla\Desktop\Parse\parse-server
> cross-env MONGODB_VERSION=${MONGODB_VERSION:=4.4.10} MONGODB_TOPOLOGY=${MONGODB_TOPOLOGY:=standalone} MONGODB_STORAGE_ENGINE=${MONGODB_STORAGE_ENGINE:=wiredTiger} mongodb-runner start     

  | Starting a MongoDB deployment to test against...Error: Could not find version matching {
  version: '${MONGODB_VERSION:=4.4.10}',
  arch: [ 'x86_64', 'x64' ],
  platform: 'win32',
  target: [
    { value: 'windows', priority: 1 },
    { value: 'windows_x86_64', priority: 10 },
    { value: 'windows_x86_64-2008plus', priority: 10 },
    { value: 'windows_x86_64-2008plus-ssl', priority: 100 },
    { value: 'windows_x86_64-2012plus', priority: 100 }
  ],
  enterprise: false,
  cryptd: false
}
    at resolve (C:\Users\megla\Desktop\Parse\parse-server\node_modules\mongodb-download-url\lib\index.js:153:19)
    at async getDownloadURL (C:\Users\megla\Desktop\Parse\parse-server\node_modules\mongodb-download-url\lib\index.js:245:12)
npm ERR! Test failed.  See above for more details.

I had the same issue when I published last time a failing test but it did work when I used npm run coverage, for some reason, it's not working now.

mtrezza · 2021-12-12T00:48:54Z

Not sure but it may be that running the test on a windows platform is causing issues. The error seems to say that mongorunner does not have a MongoDB 4.4.10 version for win32. You could try to use a different MongoDB version to run the test. That could also explain why you could run npm run coverage last time but not npm test, if both were using different MongoDB versions.

As you can see in package.json, there are some convenience scripts for other versions:

"test:mongodb:4.0.27": "npm run test:mongodb --dbversion=4.0.27",
"test:mongodb:4.2.17": "npm run test:mongodb --dbversion=4.2.17",

You can run any other DB version with npm run test:mongodb --dbversion=<DB VERSION>

Then just change the test from it to fit to only run that one test.

Meglali20 · 2021-12-14T20:25:55Z

The issue still persists I have tried multiple versions, I even tried it on Linux but get almost a similar error "can't determine Linux flavor" problems maybe from the package side or some missing files?

mtrezza · 2021-12-15T09:54:09Z

Not sure, but it look much like an issue of your custom environment, as running tests is a basic functionality. Try to delete the node_modules folder, but other than that I am not sure how to support any further at this point.

I am closing this as it does not seem to a bug in Parse Server but a custom code / environment issue and it was not possible to demo the issue. We can re-open the issue once we have more info.

Meglali20 · 2021-12-16T16:09:29Z

The issue should be reopened, managed to get the test working and created a pull request for it -> #7742
If you run the test you see that the before save is triggered only once for the new user but after save is triggered twice.

Meglali20 · 2021-12-19T01:40:28Z

Any update or confirmation?

cbaker6 · 2021-12-29T18:32:00Z

This might be related to parse-community/Parse-SDK-JS#1353 (comment). Much of the handling of authData is handled by the client SDKs. If I remember correctly, if a user is logged in anonymously and then becomes a real user by logging in with a username/password or linking with an auth provider, a new sessionToken is generated, which might trigger isNew. If a user was already a real user, the same sessionToken is used.

Note the issue in my comment above as in your PR, you mentioned you tested with the JS SDK. There's a bug as the JS SDK doesn't always handle authData correctly when linking.

Meglali20 · 2021-12-29T23:38:45Z

@cbaker6 the issue also happens with the Android SDK, and something I forget to mention is that I am not using anonymous login and also not trying to link the user, it happens when a user signs up/reconnect with the third party auth used. if it's an issue with the session token it might get worst if the user tries to log in with multiple devices.

cbaker6 · 2021-12-29T23:52:31Z

Looking at the history of the ParseUser file in the Android SDK it hasn't had much feature additions/fixes since 2018 (most of the changes look to be linting and clean up) so it's possible the SDK can have a bug.

The anonymous login discussion is an example of how the client SDKs handle auth data...

If your cloud code triggers are simple enough and you can help me understand the process you are making to test. I should be able to replicate the behavior with the Swift SDK to help figure out if it's a server or client issue.

Meglali20 · 2021-12-30T00:20:50Z

@cbaker6 Sure, just sign up -> log out -> reconnect with the account the same account from the client side, from the cloud side you can just do a random test in the user's beforeSave where you check if the user is new (you can just try console.log to print a message) and in the afterSave check if the request.original is being retrieved.

humanshield89 · 2022-01-25T11:21:28Z

This is an issue I had when I created my own auth provider (custom 2fa), and when ever users login using that auth provider an after save triggers for the user as a newly created user, my workaround was to create a lock object when the user is created in beforeSave so when after save I check if that lock exists then yes it is a new user otherwise it is this bug.

in before save

if(!!req.original){ // signup create a lock object for this user
        const lockObject = new Parse.Object("NewUserLockObject");
        lockObject.set(ParseUserKeys.username, username, {});
        await lockObject.save(null, {useMasterKey: true});
}

then in after save

    // New signup
    /// This is a workaround for a bug in Parse Server
    // When using custom AuthAdapter is being used after login saves authData in the use object
    // But it makes an after save trigger without a before save ?
    // this makes the req argument have no original in after save
    // so the workaround is to query the DB for an existing user with the same username
    // if this object has been created then it is signup otherwise it is just the bug 
    // check the existence of a lock object it is there then this is a signup if it is not it is just the bug 
    const exists = await QueryUtils.findOneInClassForKeyEqual(Parse.Object.extend("NewUserLockObject"), ParseUserKeys.username, req.object.get(ParseUserKeys.username), true);

    if (!req.original && exists) {
           // delete the lock file 
                   await exists.destroy({useMasterKey: true});
          // perform actions fir signup...

I know this is not the best solution but I was low on time

Meglali20 · 2022-01-27T21:05:44Z

@cbaker6 can you confirm it on your side?
@humanshield89 I think that creating a whole new object and a class just for that isn't a good solution, but if you also confirm the issue, @mtrezza maybe this issue should be labeled as a bug and not as a question.

mtrezza · 2022-01-27T21:14:14Z

The discussion seems to ping-pong between Parse Server, Parse JS SDK and Parse Android SDK. Is there a way to reproduce the issue with a test in this repository without involving the Parse Android SDK?

Meglali20 · 2022-01-27T21:17:13Z

I have already made a pull request for a failing test #7742

humanshield89 · 2022-01-27T21:51:20Z

@Meglali20 I confirm the issue yes I had this issue for s year now and I used that workaround because I did not know any other solution, every release I check if it was fixed but no luck

I think the issue is somewhere in the custom auth providers implementation but I am really not familiar with parse under the hood so I can't ping point it. but I think this is definitely a bug that has nothing to do with the client SDK but rather somewhere in the auth provider implementation

mtrezza added state:needs-investigation type:bug Impaired feature or lacking behavior that is likely assumed labels Dec 8, 2021

mtrezza added type:question Support or code-level question and removed type:bug Impaired feature or lacking behavior that is likely assumed state:needs-investigation labels Dec 15, 2021

mtrezza closed this as completed Dec 15, 2021

Meglali20 mentioned this issue Dec 16, 2021

fix: Original object not retrieved when user logs in with third party auth #7742

Open

7 tasks

mtrezza reopened this Dec 16, 2021

cbaker6 mentioned this issue Feb 25, 2023

Add afterFind to auth adapter #8440

Closed

3 tasks

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

User is always being detected as new when logged in through Facebook, Twitter, or Google #7737

User is always being detected as new when logged in through Facebook, Twitter, or Google #7737

Meglali20 commented Dec 8, 2021

parse-github-assistant bot commented Dec 8, 2021 •

edited

Loading

mtrezza commented Dec 8, 2021

Meglali20 commented Dec 8, 2021

mtrezza commented Dec 8, 2021 •

edited

Loading

Meglali20 commented Dec 8, 2021 •

edited

Loading

mtrezza commented Dec 8, 2021

Meglali20 commented Dec 9, 2021 •

edited

Loading

mtrezza commented Dec 10, 2021

Meglali20 commented Dec 10, 2021

mtrezza commented Dec 11, 2021 •

edited

Loading

Meglali20 commented Dec 11, 2021

mtrezza commented Dec 12, 2021

Meglali20 commented Dec 14, 2021

mtrezza commented Dec 15, 2021 •

edited

Loading

Meglali20 commented Dec 16, 2021 •

edited

Loading

Meglali20 commented Dec 19, 2021

cbaker6 commented Dec 29, 2021

Meglali20 commented Dec 29, 2021

cbaker6 commented Dec 29, 2021 •

edited

Loading

Meglali20 commented Dec 30, 2021

humanshield89 commented Jan 25, 2022

Meglali20 commented Jan 27, 2022

mtrezza commented Jan 27, 2022

Meglali20 commented Jan 27, 2022

humanshield89 commented Jan 27, 2022

User is always being detected as new when logged in through Facebook, Twitter, or Google #7737

User is always being detected as new when logged in through Facebook, Twitter, or Google #7737

Comments

Meglali20 commented Dec 8, 2021

New Issue Checklist

Issue Description

Steps to reproduce

Actual Outcome

Expected Outcome

Environment

Logs

parse-github-assistant bot commented Dec 8, 2021 • edited Loading

Thanks for opening this issue!

mtrezza commented Dec 8, 2021

Meglali20 commented Dec 8, 2021

mtrezza commented Dec 8, 2021 • edited Loading

Meglali20 commented Dec 8, 2021 • edited Loading

mtrezza commented Dec 8, 2021

Meglali20 commented Dec 9, 2021 • edited Loading

mtrezza commented Dec 10, 2021

Meglali20 commented Dec 10, 2021

mtrezza commented Dec 11, 2021 • edited Loading

Meglali20 commented Dec 11, 2021

mtrezza commented Dec 12, 2021

Meglali20 commented Dec 14, 2021

mtrezza commented Dec 15, 2021 • edited Loading

Meglali20 commented Dec 16, 2021 • edited Loading

Meglali20 commented Dec 19, 2021

cbaker6 commented Dec 29, 2021

Meglali20 commented Dec 29, 2021

cbaker6 commented Dec 29, 2021 • edited Loading

Meglali20 commented Dec 30, 2021

humanshield89 commented Jan 25, 2022

Meglali20 commented Jan 27, 2022

mtrezza commented Jan 27, 2022

Meglali20 commented Jan 27, 2022

humanshield89 commented Jan 27, 2022

parse-github-assistant bot commented Dec 8, 2021 •

edited

Loading

mtrezza commented Dec 8, 2021 •

edited

Loading

Meglali20 commented Dec 8, 2021 •

edited

Loading

Meglali20 commented Dec 9, 2021 •

edited

Loading

mtrezza commented Dec 11, 2021 •

edited

Loading

mtrezza commented Dec 15, 2021 •

edited

Loading

Meglali20 commented Dec 16, 2021 •

edited

Loading

cbaker6 commented Dec 29, 2021 •

edited

Loading