[Feature] Disable user login

[Mardaneus86]

Introduction

Being able to disable a user so he can no longer use the login function without removing the user object.

Motivation

Disabling a user allows you to temporarily remove access to his account without removing all links or ACL's on existing objects. This way the user could be re-enabled in the future and still have access to his old objects.

Proposed solution

1. Add a flag to the User class that says if the user is disabled or not. The UsersRouter could be enhanced to take this flag into account.

2. Another, more flexible, option would be to allow an override for the UsersController and inject that into the UsersRouter handleLogin flow. This way the developer can come up with custom flags to prevent a user from logging in, but this may be overkill.

Detailed design

1. Expand the User schema with a enabled or disabled flag in the SchemaController. Check for this flag in the handleLogin method of the UsersRouter.

2. Inject a allowLogin hook from the UsersController into the handleLogin method of the UsersRouter that returns a boolean. A developer would implement his own version of the UsersController and override this allowLogin method.

Alternatives considered

• Using a Cloud Code function to handle the login and return a session token. You could use the become method on the client to login. However this prevents developers from using the normal login methods, and doesn't prevent a malicious user to still use the regular login method that doesn't take the extra check into account.

• Account lockout: this is only a temporary measure where the account is disabled for a fixed amount of time and also serves another purpose than what is wanted here.

I tested a basic implementation of this proposal on my own fork. However it's still missing unit tests, and I don't know if this is functionality that could be used broadly.

[flovilmart]

Why don't you set the ACL? To make it read/write masterKey only?

[Mardaneus86]

On the User class? Didn't think of that alternative yet. Will try it out and report back.

Thanks for the quick reply.

[flovilmart]

Yes, just make the user not accessible anymore that will yield a Object not found unless you're using the masterKey while preserving everything

[Mardaneus86]

It looks like Parse is resetting the ACL on the User object to the User's ID whenever I try to remove the ACL completely. Am I doing something wrong? Tried through Parse-dashboard and with the REST API. I might be missing something here...

[Mardaneus86]

Nevermind, apparently I was still using an older version where #2495 wasn't fixed yet.

Thanks a lot for your help!

[Mardaneus86]

It seems I was wrong in my checks yesterday, it still resets the ACL on the User object to the users ID on version 2.3.5.

On other objects the proposed technique works as expected.

[Mardaneus86]

I guess the real issue of this one is mentioned in #3588, so closing this one in favour of #3588.

[Mardaneus86]

Further investigation learned that you cannot set the ACL of the User class to "Master Key Only" (that is filling it with an empty ACL object).

It is caused by this line: https://github.com/ParsePlatform/parse-server/blob/master/src/RestWrite.js#L894

Setting the ACL object to null prevents this line from running, but then the ACL isn't updated either. I can understand why this is here. Since a User can write to his own object, he could potentially lock himself out as stated in the comment. We might be able to work around this by checking the MasterKey on this line?

Or is there any other way to remove the ACL from a User?

[flovilmart]

I'd be ok to allow masterKey for the moment. Feel free to open a PR for that.

[Mardaneus86]

Alright, will make a PR for it.

I'll have to make some unit tests first.

[NicksonYap]

A beforeLogin() trigger has been added starting from v3.3.0:
https://docs.parseplatform.org/cloudcode/guide/#beforelogin