preventLoginWithUnverifiedEmail not Working

[calhouncole]

Issue Description

I am running parse-server v. 2.2.22. In my ParseServer configuration, I have preventLoginWithUnverifiedEmail = true. On signup, before a user verifies their email, it still logs them in.

My configuration:

var parse_api = new ParseServer({
  databaseURI: process.env.MONGOLAB_URI || 
  config.databaseURI,
  // cloud: './cloud/main.js',
  appId: config.parseAppId,
  fileKey: config.parseFileKey,
  masterKey: config.parseMasterKey,
  serverURL: process.env.PARSE_SERVER_URL || config.parseServerURL,
  publicServerURL: config.parsePublicServerURL,
  verifyUserEmails: config.parseVerifyUserEmails,
  appName: config.parseAppName,
  facebookAppIds: config.facebookAppIds,
  preventLoginWithUnverifiedEmail: config.parsePreventLoginWithUnverifiedEmail,
   // The email adapter
  emailAdapter: {
    module: config.parseEmailAdapterModule,
    options: {
      // The address that your emails come from
      fromAddress: config.parseFromEmailAddress,
      // Your domain from mailgun.com
      domain: config.parseEmailDomain,
      // Your API key from mailgun.com
      apiKey: config.parseEmailAPIKey,
    }
  }
});

Steps to reproduce

Please include a detailed list of steps that reproduce the issue. Include curl commands when applicable.

1. Sign up a user
2. Do not verify the email address
3. Try and login

Expected Results

The User will be blocked from login during signup.

Actual Outcome

The User is logged no problem.

Environment Setup

• Server
  • parse-server version : 2.22.22
  • Localhost or remote server? Heroku
• Database
  • MongoDB version: 3.2.9
  • Localhost or remote server?: mLab

Logs/Trace

2016-10-13T03:55:00.897370+00:00 app[web.1]: GET /parse/login 200 103.378 ms - 341

[flovilmart]

Hi, we have a unit test especially covering that case here: https://github.com/ParsePlatform/parse-server/blob/ad707457be13f177e4a0dc481c990ddbd2df8d80/spec/ValidationAndPasswordsReset.spec.js#L241

Can you please confirm that your configuration is correct and not any differences between the test and you actual setup?

[cherukumilli]

@calhouncole
I just tested it with version 2.2.21 and it works fine i.e., for your use case parse-server throws an error with error message User email is not verified. and error code: 205.

is there any way you can print the values of the following to the console to check and make sure they are set correctly to true?

config.parseVerifyUserEmails,
config.parsePreventLoginWithUnverifiedEmail

I will upgrade my parse-server to 2.2.23 and I will try it again later during the day.

[joshuadiezmo]

i have same issue.

i just want to block user that is not verified.

and also i did not want to send them a verification code because i want that admin will verify them

[cherukumilli]

@ReverseFlash28

I wonder if the values being passed to verifyUserEmails and preventLoginWithUnverifiedEmail are not in a boolean format. i.e., String "true" vs Boolean true.

Can you please hardcode the values of the following to true as a test to see if it works? If this works then I will submit a new PR to convert the value passed to these two options to a boolean.

  verifyUserEmails: true,
  preventLoginWithUnverifiedEmail: true,

[fduch2k]

I'm faced with the same problem. After some research I found that preventLoginWithUnverifiedEmail checked only in UsersRouter.handleLogIn, which is used only as handler for /login api. So inside signUp flow preventLoginWithUnverifiedEmail does not checked. I think that better place to validate this option somewhere inside RestWrite.runDatabaseOperation

[flovilmart]

signUp flow preventLoginWithUnverifiedEmail does not checked.

That's the whole point of, it anyone can signup, but you need your email to be verified to be able to login. In that case, probably the signUp should not issue a session token.

[fduch2k]

signUp should not issue token, it also should return the same error as logIn (but User should be created)

[flovilmart]

If this yields an error, user should not be created

[fduch2k]

So, if server not able to create session (for any reason - db connection error or s.th. else) user which already created must be deleted? Or server should not raise error because user is exists in db?

I don't understand why login should raise error, but signup not.

[flovilmart]

what we should do is simply not return the session token upon signup if the server is configured to require a verified email.

[flovilmart]

@fduch2k do you want to take on the implementation as discussed?

[fduch2k]

Yes, I can implement this. But I can handle this task only on next week

[flovilmart]

There's no rush, open a Pr when you're good :)

[pcg92]

has not been fixed yet?

[flovilmart]

Not yet, it seems to have fallen into the cracks. Would you be willing to attempt a fix? I can guide you through it if you need to.

[pcg92]

Yes I need this feature, so the fix is:

what we should do is simply not return the session token upon signup if the server is configured to require a verified email.

right?

[flovilmart]

Yes, that would be the way to go. Actually, the sessions should not be created at all.

[pcg92]

Auth.js -> getAuthForSessionToken

Is here where I need to check the variable "preventLoginWithUnverifiedEmail"?

[flovilmart]

The method you’re pointing out is checking the session token passed by the clients for their validity as well as the associated roles.

We need to prevent the creation of Session objects when a user signs up or a user object is saved with an email that is not verified

[mryalamanchi]

@flovilmart can you point me towards the code when a Session object is being created during Signup.
I will try fixing it and open a PR asap.

Also, there is another unexpected behavior. When the verifyUserEmails option is enabled for the parse-server and if a Sign up attempt is made using only the username and password, which is mandatory, without passing an email. Then it doesn't let the User login saying the email is not verified. I think it shouldn't allow a User to Sign up, in the first place, without providing an email when the above option is enabled on the parse-server.
Is there something that I am missing here? Does it need a solution or is there already one? I will open an issue if necessary.

[flovilmart]

@mryalamanchi There is a single spot in the code where the sessions are created https://github.com/parse-community/parse-server/blob/8604f9c/src/Auth.js#L350 and written. I should properly rename the createSession of at L375 as write as this method does just that.

So you could have a look at the different callers of Auth.createSession.

When the verifyUserEmails option is enabled for the parse-server and if a Sign up attempt is made using only the username and password, which is mandatory, without passing an email. Then it doesn't let the User login saying the email is not verified. I think it shouldn't allow a User to Sign up, in the first place, without providing an email when the above option is enabled on the parse-server.

This is reasonable to expect this.

[mryalamanchi]

@flovilmart I didn't see any session object being created in the DB (MongoDB) during Sign Up when testing the parse-server with normal Sing-up method. I also skimmed through the code checking for the Auth.createSession callers and found that parse-server already enforces a check before creating a session token to discern if it's for Log in or Sign up.

So here's a rundown :
createSessionTokenIfNeeded enforces a check before calling createSessionToken.
createSessionToken makes the call to Auth.createSession

I should properly rename the createSession of at L375 as write as this method does just that.

I would recommed you to not to rename it to write as the former is more verbose.

To my understanding there doesn't seem to be any issue of session creation during sign up.
We can close this issue unless there's anything else to be checked upon.
But I do have query regarding this ternary check.
What is the purpose for substituting for singup if the storage['authProvider'] is undefined?
Does this create a session directly when Signing up via 3rd part integrations?

This is reasonable to expect this.

I understand. But I think this small feature can be improved upon from the server side itself without requiring any client-side workarounds. I am opening an issue along with it I will also provide a solution that I came up with.

[flovilmart]

What is the purpose for substituting for singup if the storage['authProvider'] is undefined?

This stores in the _Session object wether it was created with a 3rd party auth (logIn) or a traditional email/password (signup) call. There’s no other purposes. It does not ‘create’ a session directly.

I didn't see any session object being created in the DB (MongoDB) during Sign Up when testing the parse-server with normal Sing-up method. I also skimmed through the code checking for the Auth.createSession callers and found that parse-server already enforces a check before creating a session token to discern if it's for Log in or Sign up.

So I am not sure why we’re commenting on this 2 year old issue. I believe you mentioned you wanted to fix the issue, which means you have it in the first place no?

As for the other part, you can implement it though a beforeSave(Parse.User) and enforce an email is set.

[mryalamanchi]

@flovilmart gotcha! Thanks a lot for clarifying.

So I am not sure why we’re commenting on this 2 year old issue. I believe you mentioned you wanted to fix the issue, which means you have it in the first place no?

I recently started using Parse-Server and found it to be really useful given the fact that it's a full blown open source BaaS solution. So, I am wishing to contribute to this project. I am trying to de-clutter the issues section which brought me to this one.
I just figured out it already has the fix. So you can close this issue.

As for the other part, you can implement it though a beforeSave(Parse.User) and enforce an email is set.

I have gone through the API documentation and it suggested to use the same. An effective one indeed.
But it seemed more like to fundamentally have this check when enabling this specific config verifyUserEmails in the Parse-Server codebase. This will eliminate the need of requiring the beforeSave workaround but also shouldn't break any changes for the same. Here's a solution that I thought of that can be possibly implemented just before this:

if(!this.data.email && this.config.verifyUserEmails) { return Promise.reject(new Parse.Error(Parse.Error.EMAIL_MISSING, 'email id is required')); }

[flovilmart]

Here's a solution that I thought of that can be possibly implemented just before this:

feel free to open a PR with the effective tests. I would ask you to add an additional startup option like requireUserEmails to enforce the additional option instead of verifyUserEmails as it would make a breaking change.

[mryalamanchi]

@flovilmart will do so. That will be a neat approach.

[mtrezza]

I looks worth revisiting. This is classified as feature request but from the description it looks like a bug.

[parseplatformorg]

🎉 This change has been released in version 6.1.0-alpha.17

[parseplatformorg]

🎉 This change has been released in version 6.3.0-beta.1

[parseplatformorg]

🎉 This change has been released in version 6.3.0-alpha.1

[parseplatformorg]

🎉 This change has been released in version 6.3.0