"invalid field name: _failed_login_count" from api.parse.com

[JeremyPlease]

After upgrading to Parse Server >= 2.2.19 and configuring accountLockout (from #2601) Hosted Parse API calls to /login or /classes/_User return:
{"code":105,"error":"invalid field name: _failed_login_count"}

Steps to reproduce

1. Set client key configuration for accountLockout.
2. Attempt to login with correct username and any password on open source Parse Server. This adds the field _failed_login_count to the _User object in database.
3. Attempt to login with same username and correct password on hosted Parse (api.parse.com/1/)

Expected Results

User can login with correct username and password.

Actual Outcome

Parse returns {"code":105,"error":"invalid field name: _failed_login_count"}

Environment Setup

• Server
  • parse-server version: 2.1.19, 2.1.21
  • Operating System: OSX 10.11
  • Localhost or remote server? (AWS, Heroku, Azure, Digital Ocean, etc): localhost and AWS
• Database
  • MongoDB version: 3.0.10
  • Storage engine: MMAPv1
  • Hardware: Shared
  • Localhost or remote server? (AWS, mLab, ObjectRocket, Digital Ocean, etc): mLab

Temporary Solution:

Disable accountLockout config and remove _failed_login_count from all _User objects.

---

From what I can tell, api.parse.com is doing a check on fields before returning the object. Since _failed_login_count starts with _ it considers it an invalid field and returns the error.

I don't think there is a fix on Parse Server side that would make sense, so I'll disable accountLockout until migration is complete.

[flovilmart]

As we move forward, it's very likely those issues arise :) for those new features you should exclusively use Parse-server and parse-dashboard as parse.com wont get updated to support those.

[sidan5]

same issue here. Deleting _failed_login_count and _email_verify_token_expires_at fields from users table in mLab were the only solution that made my app work again (luckily down time was minor).

I guess the temporary solution suggested is what everyone should do in the migration process. Otherwise the server be down sooner than expected.

Currently the default is using this features which may break lots of live apps...

[flovilmart]

@sidan5 like mentioned in the previous comment, parse-server specific features won't be supported on api.parse.com nor the dashboard.parse.com. If you plan to use those, make sure you're fully migrated first!

[sidan5]

@flovilmart That I understand but real app still use Parse Hosted server till I finish crafting my server, update the app and users would update. That could take a while. Not knowing those added fields break Parse Hosted server could be a disaster for some apps.
I guess I'm not the only one that using local Parse-Server to make sure everything is connected right and working, using the real DB to test before deploy and publish an update.

Actually if I didn't do that I would never catch this issue in time which could result with my app be broken completely on production (at least to users that haven't update the app)...

[flovilmart]

Yeah but those added fields should only be there if you use those particular features, not otherwise. Did you enable those additional features?

And you're 100% right testing locally before deploying :) I can't encourage more to do that!

[sidan5]

Yea but there is no mention to that. Also using this feature is default on the example of email verification (probably a comment there would be best).

Problem I have that this (even in a single user) makes queries fail...

[flovilmart]

What example are you talking about? parse-server-example?

[cherukumilli]

@sidan5

The README.md file at https://github.com/ParsePlatform/parse-server/blob/master/README.md currently says:

  // account lockout policy setting (OPTIONAL) - defaults to undefined
  // if the account lockout policy is set and there are more than `threshold` number of failed login attempts then the `login` api call returns error code `Parse.Error.OBJECT_NOT_FOUND` with error message `Your account is locked due to multiple failed login attempts. Please try again after <duration> minute(s)`. After `duration` minutes of no login attempts, the application will allow the user to try login again.
  accountLockout: {
    duration: 5, // duration policy setting determines the number of minutes that a locked-out account remains locked out before automatically becoming unlocked. Set it to a value greater than 0 and less than 100000.
    threshold: 3, // threshold policy setting determines the number of failed sign-in attempts that will cause a user account to be locked. Set it to an integer value greater than 0 and less than 1000.
  },

Please let us know how you would like us to modify the README.md and I will update it and submit a pull request.

[sidan5]

@cherukumilli I think adding something like that would be nice:

// IMPORTANT NOTICE: This feature would add '_failed_login_count' and '_email_verify_token_expires_at' to the user table, that makes the user on queries on user table unreachable when using parse hosted server and could break your app till you finish migration completely

Maybe even add a recommendation not to use this feature at all if there are any app clients that are still using Parse Hosted server