Repository navigation
Parse.FacebookUtils.logIn is creating new users when Facebook ID already exists. #4897
Description
We have been using a very simple flow to log in users using Facebook that has been working for almost a year and a half, and now it has stopped working.
We use Parse.FacebookUtils.logIn to log in an existing user, or creating a new one.
var facebookAuthData = {
"id": <fb_id>,
"access_token": <fb_access_token>,
"expiration_date": <fb_expiration_date>
};
Parse.FacebookUtils.logIn(facebookAuthData, {
success: function(user) {
if (user.isNew()) {
// New user....
} else {
// Old user...
}
},
error: ...
});
But it's happening that although there is an existing user in the database with the exact <fb_id> that we pass to Parse.FacebookUtils.logIn(), it is creating a new user instead of login the existing user. Furthermore, this "new" user is created with a weird/random "username" in the database.
Some more details:
-
Parse server version: 2.8.2. FB Graph version 3.0.
-
We only see the issue in our "Production" environment. This is a Heroku dyno with a mongoLab add-on. Note that it uses a replica set.
-
Our development environment uses a free-tier Heroku dyno, with a mongoLab add-on without a replica set. We DON'T see the issue here.
-
New users that have never logged in, can successfully log-in using Facebook, and re-login Ok. The ones that are having trouble were old users that logged in through Facebook a while back (using FB Graph v2.2).
-
After Parse.FacebookUtils.login() returns a "new" user when it shouldn't, when we try to save to the new user (i.e. to set the email), the error returned by parse can be inconsistent. Sometimes it will say "code=203, message=Account already exists for this email address." (since we had previously created the user and assigned the email address), but if I manually delete the malformed new user, sometimes instead of creating another malformed user, it will just say "Invalid access token". Very weird.
-
I've tried with older versions of Parse Server too (like 2.7.4) and the same issue happens.
I've tried for days trying to understand why this is happening with no luck. Any help appreciated, especially since this one reached our Production environment and previously FB logged users are being locked out.
Thanks in advance for the help.
Activity
cbaker6 commentedon Jul 16, 2018
I have this same problem with FacebookUtils and TwitterUtils whenever I use Parse Server 2.8 or higher. On ParseServer 2.74 and below, I don't have this issue. As a note, I use the Parse SDK for iOS, version 1.17.1. To further clarify, this issue occurs with users who had created or linked their account using an older Parse Server version. I haven't verified if it for new facebook or twitter users.
I haven't looked at the code, but it seems like FacebookUtils and TwitterUtils doesn't query authData correctly for facebookId and twitterId for duplicates anymore and instead just adds another facebookId and twitterId, even if it's already in the _User table.
jose-carballo commentedon Jul 16, 2018
As per @cbaker6 comment, I re-tested using Parse 2.7.2, and the issue does not happen. Confirmed in 2.8.2.
flovilmart commentedon Jul 16, 2018
Are you able to provide some verbose logs for the issue, as well as potentially a way to consistently reproduce it (including database etc...) is uou’re a le to reproduce the issue in a failing test this would greatly help as well. Otherwise we’ll still look into it.
One last thing, can you check/ share with us which indexes exist on the _User collection?
jose-carballo commentedon Jul 17, 2018
Extract of our package.json:
Here is the log when Parse is deployed (kerberos compiles with warnings):
When the existing user tries to logging to facebook (a user that already has a FB auth data well defined), the Parse.FacebookUtils.logIn() utility will return a new user with random username (expressed in the log below: Q2NGibf9AGcl3W7s6Ud881TiX), instead of returning the existing one which has the same authData.facebook.id. Note that the "Account already exists for this email address." happens after I have received the undesired new user and assign it an email. This is what it logged during the FB login attempt:
I cannot share my environment, but I can confirm that the issue can be reproduced consistently with Parse v2.8.2, just let me know how I can help. Right now I've deployed 2.7.4 to avoid the issue in Production.
Some notes about the environment:
This deployment is running MongoDB version 3.0.15 (MMAPv1). This is a standard heroku production deployment which has been working for about year and a half with no intervention other than Parse Server updates.
rs.conf() raw data output:
The _User collection has 1 index:
flovilmart commentedon Jul 17, 2018
That’s : odd that only one index on the_ User table is there (on id) as on startup, the server should create more indexes on the DB. Is it possible for you pull out the first logs after the server starts?
jose-carballo commentedon Jul 17, 2018
Here are the logs from the server when deploying/starting.
flovilmart commentedon Jul 17, 2018
Yeah, so that means there’s already duplicated entries with the same username in the _User table.
You may want to remove those duplicates and restart the server to ensure all indexes are properly created on startup. While this may not exactly be the root cause, this will help
jose-carballo commentedon Jul 17, 2018
I will look up for duplicate usernames. According to our logic there shouldn't be any, but well if it happened it may be from the earlier development times.
Would the "email" duplicate entries also be a problem? This may be related to "anonymous" users (FB log in's without email permissions), and in such case I am not able to fix that.
flovilmart commentedon Jul 17, 2018
Yes, emails should be unique too, and perhaps the initialization will fail at a later point. Do you have the same log when starting a server against your production DB, with an earlier version of the server?
jose-carballo commentedon Jul 17, 2018
Server log deploying version 2.7.4:
When you say that emails should be unique, does it mean that they cannot be left blank? I really don't see an easy way to change that, as for quite a long time we've supported users using FB login and declining email permissions - actually, many people decline this permission. Even if we change the login flow to request an email address in such a case, we already have a lot of users in the database without email. If it should be, probably is better to express that clearly in documentation, or possibly enforce it somehow.
flovilmart commentedon Jul 17, 2018
They can be left blank. Usernames can’t/ should not.
As I can see in this log, this issue is there as well with 2.7.4, so that’s not it, fixing it should still be done. I’ll check why the original Facebook id can’t be found. Perhaps the unique sparse index can’t be built either on those.
flovilmart commentedon Jul 17, 2018
@tai-x Another question, can you pull from the DB the raw document for a user that fails to login and another that succeeds in logging in?
CIO-DOTNET commentedon Jul 17, 2018
Hi @tai-x, I have noticed your environment is completely different from the one described in issue #4407 (where you left your initial comment). The issue seems to be the related, perhaps parse-server should not look for duplicate email addresses if the email field provided is null or empty? (since the email field is not required?)
To answer your initial question left in issue #4407, the way I solved my issue was by dropping the "User" Class through the parse dashboard, then creating a new "User" Class by selecting the "User" Class option in the dialog window that appears. Have in mind you would of course need to backup any data and structural changes made to your "User" Class before dropping it.
flovilmart commentedon Jul 17, 2018
Dropping the user table will destroy the data...
This is mongodb index creation, the email index is sparse so null /undefined is indeed allowed.
cbaker6 commentedon Jul 17, 2018
Here is the log from Parse-server 2.7.4, this one works correctly by connecting to the old user who has logged in via Facebook using previous versions of Parse:
verbose: REQUEST for [POST] /parse/users: { "authData": { "facebook": { "id": "8379****", "access_token": "EAAKn2SZA5kRkBALZAoSglQ2VNrDwhbJZAi9Ehpw4hXdz0YZAsHjASZC3W8PpJ6eoMqSCrz0k8o9OrogdDrbhCYzBTCgiBgMMeAhiO0Hhz5wkGt62t9Dmgj836Km7kiEZATkKub4Q3ZBxxQeQlmKwZB8gfN3rAPNNToTwfZAZA5DoY6TIym32XUBFH1ZA1q3lKzOsZC2d0dGI8yqZBjfZArFASSw*******", "expiration_date": "2018-09-15T14:55:14.785Z" } } } method=POST, url=/parse/users, host=n*****edu:1337, content-type=application/json; charset=utf-8, x-parse-revocable-session=1, accept=*/*, x-parse-application-id=SBC0DswFA7RdbIQJ8Z6JWkchaZsRbNfvIgg8C2W2, x-parse-installation-id=27b6dfdb-9878-488e-be2e-8849fbae1074, x-parse-os-version=11.4 (15F79), accept-language=en-us, accept-encoding=br, gzip, deflate, x-parse-client-version=i1.17.1, content-length=347, user-agent=AlleyOop/3 CFNetwork/901.1 Darwin/17.6.0, connection=keep-alive, x-parse-app-build-version=3, x-parse-app-display-version=2.04, id=8379****, access_token=EAAKn2SZA5kRkBALZAoSglQ2VNrDwhbJZAi9Ehpw4hXdz0YZAsHjASZC3W8PpJ6eoMqSCrz0k8o9OrogdDrbhCYzBTCgiBgMMeAhiO0Hhz5wkGt62t9Dmgj836Km7kiEZATkKub4Q3ZBxxQeQlmKwZB8gfN3rAPNNToTwfZAZA5DoY6TIym32XUBFH1ZA1q3lKzOsZC2d0dGI8yqZBjfZArFASSw*******, expiration_date=2018-09-15T14:55:14.785Z verbose: RESPONSE from [POST] /parse/users: { "response": { "objectId": "YrCVyDcejf", "createdAt": "2015-01-02T19:09:59.788Z", "updatedAt": "2018-07-17T18:53:50.175Z", "email": "c***@ufl.edu", "username": "coreyiphone6", "usernameLiteral": "CoreyIphone6", "displayName": "Corey E Baker", "authData": { "twitter": { "auth_token": "***", "id": "***", "consumer_key": "** kvKGRA5D59dT*****", "auth_token_secret": "*****", "consumer_secret": "*****", "screen_name": "iKilledChivalry" }, "facebook": { "id": "8379****", "access_token": "EAAKn2SZA5kRkBALZAoSglQ2VNrDwhbJZAi9Ehpw4hXdz0YZAsHjASZC3W8PpJ6eoMqSCrz0k8o9OrogdDrbhCYzBTCgiBgMMeAhiO0Hhz5wkGt62t9Dmgj836Km7kiEZATkKub4Q3ZBxxQeQlmKwZB8gfN3rAPNNToTwfZAZA5DoY6TIym32XUBFH1ZA1q3lKzOsZC2d0dGI8yqZBjfZArFASSw*******", "expiration_date": "2018-09-15T14:55:14.785Z" } }, "twitterId": "***", "twitterFriends": [ "" ], "_failed_login_count": 5, "_account_lockout_expires_at": "2017-02-08T23:30:19.899Z", "facebookId": "8379****", "facebookFriends": [ ], "sessionToken": "r:bbb57dd2954da772a8b9ff09b37f419b" }, "location": "https://n*****edu:1337/parse/users/YrCVyDcejf" } objectId=YrCVyDcejf, createdAt=2015-01-02T19:09:59.788Z, updatedAt=2018-07-17T18:53:50.175Z, email=c***@ufl.edu, username=coreyiphone6, usernameLiteral=CoreyIphone6, displayName=Corey E Baker, auth_token=***, id=***, consumer_key=** kvKGRA5D59dT*****, auth_token_secret=*****, consumer_secret=*****, screen_name=iKilledChivalry, id=8379****, access_token=EAAKn2SZA5kRkBALZAoSglQ2VNrDwhbJZAi9Ehpw4hXdz0YZAsHjASZC3W8PpJ6eoMqSCrz0k8o9OrogdDrbhCYzBTCgiBgMMeAhiO0Hhz5wkGt62t9Dmgj836Km7kiEZATkKub4Q3ZBxxQeQlmKwZB8gfN3rAPNNToTwfZAZA5DoY6TIym32XUBFH1ZA1q3lKzOsZC2d0dGI8yqZBjfZArFASSw*******, expiration_date=2018-09-15T14:55:14.785Z, twitterId=***, twitterFriends=[2207036778], _failed_login_count=5, _account_lockout_expires_at=Wed Feb 08 2017 18:30:19 GMT-0500 (EST), facebookId=8379****, facebookFriends=[], sessionToken=r:bbb57dd2954da772a8b9ff09b37f419b, location=https://n*****edu:1337/parse/users/YrCVyDcejfLog from 2.8.2, which creates a new account instead of linking to the old user:
verbose: REQUEST for [POST] /parse/users: { "authData": { "facebook": { "id": "8379****", "access_token": "EAAKn2SZA5kRkBADpd9Kwd0JeXWkLVeswsZC5fk5DdST3DfnoOP6Xxiqk1hiTNSXZAhZCcDVxCEeQZCYO6EZCjktZAuxcfkXpDnZB8MqZBxDat7ZA1CqBm3FY1GWUY6PnXP8QDr0bVMCpjf4vZAftOI2I7iOZB9sTsvZBRmQIC3Lgi9Bm6VurrFTeoFQbmzCArEPAZBkXBb7Xq81Smz5aC9XcN0YFh41NZBqtR6**************", "expiration_date": "2018-09-15T14:55:15.064Z" } } } method=POST, url=/parse/users, host=n*****edu:1337, content-type=application/json; charset=utf-8, x-parse-revocable-session=1, accept=*/*, x-parse-application-id=SBC0DswFA7RdbIQJ8Z6JWkchaZsRbNfvIgg8C2W2, x-parse-installation-id=b5ff282d-a2bc-4566-ac03-31730d80798f, x-parse-os-version=11.4 (15F79), accept-language=en-us, accept-encoding=br, gzip, deflate, x-parse-client-version=i1.17.1, content-length=347, user-agent=AlleyOop/3 CFNetwork/901.1 Darwin/17.6.0, connection=keep-alive, x-parse-app-build-version=3, x-parse-app-display-version=2.04, id=8379****, access_token=EAAKn2SZA5kRkBADpd9Kwd0JeXWkLVeswsZC5fk5DdST3DfnoOP6Xxiqk1hiTNSXZAhZCcDVxCEeQZCYO6EZCjktZAuxcfkXpDnZB8MqZBxDat7ZA1CqBm3FY1GWUY6PnXP8QDr0bVMCpjf4vZAftOI2I7iOZB9sTsvZBRmQIC3Lgi9Bm6VurrFTeoFQbmzCArEPAZBkXBb7Xq81Smz5aC9XcN0YFh41NZBqtR6**************, expiration_date=2018-09-15T14:55:15.064Z verbose: RESPONSE from [POST] /parse/users: { "status": 201, "response": { "objectId": "XWPlckYLhs", "createdAt": "2018-07-17T18:48:41.263Z", "username": "81b2frJTm5tl73fdXNmDDjX8q", "sessionToken": "r:9320edf4dd9f7b996bcaff9854b83dad" }, "location": "https://n*****edu:1337/parse/users/XWPlckYLhs" } status=201, objectId=XWPlckYLhs, createdAt=2018-07-17T18:48:41.263Z, username=81b2frJTm5tl73fdXNmDDjX8q, sessionToken=r:9320edf4dd9f7b996bcaff9854b83dad, location=https://n*****edu:1337/parse/users/XWPlckYLhs verbose: REQUEST for [PUT] /parse/classes/_User/XWPlckYLhs: { "email": "c***@ufl.edu", "username": "81b2frjtm5tl73fdxnmddjx8q", "usernameLiteral": "81b2frJTm5tl73fdXNmDDjX8q", "displayName": "Corey E Baker", "authData": { "facebook": { "id": "8379****", "access_token": "EAAKn2SZA5kRkBADpd9Kwd0JeXWkLVeswsZC5fk5DdST3DfnoOP6Xxiqk1hiTNSXZAhZCcDVxCEeQZCYO6EZCjktZAuxcfkXpDnZB8MqZBxDat7ZA1CqBm3FY1GWUY6PnXP8QDr0bVMCpjf4vZAftOI2I7iOZB9sTsvZBRmQIC3Lgi9Bm6VurrFTeoFQbmzCArEPAZBkXBb7Xq81Smz5aC9XcN0YFh41NZBqtR6**************", "expiration_date": "2018-09-15T14:55:15.064Z" } }, "facebookId": "8379****" } method=PUT, url=/parse/classes/_User/XWPlckYLhs, host=n*****edu:1337, content-type=application/json; charset=utf-8, accept=*/*, x-parse-session-token=r:9320edf4dd9f7b996bcaff9854b83dad, x-parse-application-id=SBC0DswFA7RdbIQJ8Z6JWkchaZsRbNfvIgg8C2W2, x-parse-installation-id=b5ff282d-a2bc-4566-ac03-31730d80798f, x-parse-os-version=11.4 (15F79), accept-language=en-us, accept-encoding=br, gzip, deflate, x-parse-client-version=i1.17.1, content-length=516, user-agent=AlleyOop/3 CFNetwork/901.1 Darwin/17.6.0, connection=keep-alive, x-parse-app-build-version=3, x-parse-app-display-version=2.04, email=c***@ufl.edu, username=81b2frjtm5tl73fdxnmddjx8q, usernameLiteral=81b2frJTm5tl73fdXNmDDjX8q, displayName=Corey E Baker, id=8379****, access_token=EAAKn2SZA5kRkBADpd9Kwd0JeXWkLVeswsZC5fk5DdST3DfnoOP6Xxiqk1hiTNSXZAhZCcDVxCEeQZCYO6EZCjktZAuxcfkXpDnZB8MqZBxDat7ZA1CqBm3FY1GWUY6PnXP8QDr0bVMCpjf4vZAftOI2I7iOZB9sTsvZBRmQIC3Lgi9Bm6VurrFTeoFQbmzCArEPAZBkXBb7Xq81Smz5aC9XcN0YFh41NZBqtR6**************, expiration_date=2018-09-15T14:55:15.064Z, facebookId=8379**** verbose: RESPONSE from [PUT] /parse/classes/_User/XWPlckYLhs: { "response": { "updatedAt": "2018-07-17T18:50:57.761Z" } } updatedAt=2018-07-17T18:50:57.761ZNote: as stated by @tai-x, on 2.8.2, if I login via Facebook and let it create a new account. Sign-out, then sign-in again, it logs back into the new account it created.
In addition, I don't allow duplicate emails or duplicate usernames in my mongodb. I also don't have any blank email addresses.
Update: here is the log after "install" and "start" just incase it's needed. I don't get any uniqueness warnings on start-up:
alleyoopsocial-parse-server@2.0.0 /Users/netreconlab/Documents/Server/alleyoop_parse_server └─┬ parse-server@2.7.4 ├─┬ @parse/push-adapter@2.0.2 │ ├─┬ apn@2.2.0 │ │ └── http2@3.3.6 │ └─┬ node-gcm@0.14.10 │ ├── lodash@3.10.1 │ └─┬ request@2.81.0 │ ├── aws-sign2@0.6.0 │ ├── form-data@2.1.4 │ ├─┬ har-validator@4.2.1 │ │ ├─┬ ajv@4.11.8 │ │ │ └─┬ json-stable-stringify@1.0.1 │ │ │ └── jsonify@0.0.0 │ │ └── har-schema@1.0.5 │ ├─┬ hawk@3.1.3 │ │ ├── boom@2.10.1 │ │ ├── cryptiles@2.0.5 │ │ ├── hoek@2.16.3 │ │ └── sntp@1.0.9 │ ├─┬ http-signature@1.1.1 │ │ └── assert-plus@0.2.0 │ ├── performance-now@0.2.0 │ └── qs@6.4.0 ├─┬ @parse/simple-mailgun-adapter@1.0.1 │ └─┬ mailgun-js@0.13.1 │ ├── async@2.5.0 │ ├── form-data@2.2.0 │ └─┬ proxy-agent@2.1.0 │ └── lru-cache@2.6.5 ├─┬ bcrypt@1.0.3 │ ├── nan@2.6.2 │ └─┬ node-pre-gyp@0.6.36 │ ├─┬ rc@1.2.8 │ │ └── deep-extend@0.6.0 │ ├─┬ tar@2.2.1 │ │ ├── block-stream@0.0.9 │ │ └─┬ fstream@1.0.11 │ │ └── graceful-fs@4.1.11 │ └─┬ tar-pack@3.4.1 │ ├── fstream-ignore@1.0.5 │ └── uid-number@0.0.6 ├─┬ body-parser@1.18.2 │ └── qs@6.5.1 ├── commander@2.15.0 ├── deepcopy@0.6.3 ├── mime@2.2.0 ├─┬ mongodb@3.0.4 │ └── mongodb-core@3.0.4 ├─┬ pg-promise@8.2.1 │ └─┬ pg@7.4.1 │ └─┬ pg-types@1.12.1 │ └── postgres-interval@1.1.2 ├─┬ request@2.83.0 │ ├── form-data@2.3.2 │ └─┬ hawk@6.0.2 │ ├── boom@4.3.1 │ ├── cryptiles@3.1.2 │ ├── hoek@4.2.1 │ └── sntp@2.1.0 ├── uws@9.148.0 └── ws@5.0.0 netrecon:alleyoop_parse_server netreconlab$ npm start > alleyoopsocial-parse-server@2.0.0 start /Users/netreconlab/Documents/Server/alleyoop_parse_server > node index.js verbose: Support key pairs Map {} alleyoop-parse-server running on port 1337. verbose: REQUEST for [GET] /parse/classes/_Installation: { "where": {}, "limit": 0, "count": 1 }flovilmart commentedon Jul 17, 2018
@cbaker6 are you able to share here the user object, right from mongodb, without all the transformations applied to it from parse server?
jose-carballo commentedon Jul 17, 2018
@flovilmart
Here is the user document that existed previously (removing some of the non-important columns that we added to our User class).
Here is the malformed "new" user document that shouldn't have been created, untouched. It has some fields in the document that are not present in the old user above (_wperm, _rperm, _acl), as well as missing some apparently default ones (_hashed_password, sessionToken) and the rest of custom columns we added to the User class.
Regards,
flovilmart commentedon Jul 17, 2018
@tai-x this is exactly the conclusion I was reaching now. In recent versions the user object follow ACL’s and it is possible that legacy users without any ACL are getting locked out.
The new feature was introduced so a developer can close a user’s account without deleting it by marking the ACL completely private.
There are 2 ways to fix it for 2.8.2:
For now you can stick to 2.7.4 or update your old user’s ACL’s so they can read themselves.
I’ll be working on a patch for this
jose-carballo commentedon Jul 17, 2018
Thanks for your help @flovilmart. Let me know when you have a patch to test it or if you need more info.
flovilmart commentedon Jul 17, 2018
Thanks for providing the data, i’ll Keep you posted here. I need to think about the possible side effects. As this issue also shows that a locked out account would let the user create a new account anyway.
flovilmart commentedon Jul 17, 2018
@tai-x you can try the branch
fix/issue-4897it should fix the issue. If you're using npm >= 6, you can use the branch directly by setting the parse-server dependency tohttps://github.com/parse-community/parse-server#fix/issue-4897jose-carballo commentedon Jul 17, 2018
Fixed. Nice!
flovilmart commentedon Jul 18, 2018
Glad to hear!
cbaker6 commentedon Jul 18, 2018
@flovilmart my data looked like @tai-x's, missing the ACL in mongodb for legacy users, but showing all ACLs in Parse Dashboard:
User created with legacy version:
{ "_id" : "OldjvvMVaG", "_created_at" : ISODate("2015-07-13T18:05:21.502Z"), "_updated_at" : ISODate("2018-06-27T17:35:42.215Z"), "_perishable_token" : "***", "_auth_data_facebook" : { "access_token" : "***", "expiration_date" : ISODate("2015-09-11T18:05:19.475Z"), "id" : "1010***" }, "username" : "jerbear323", "_session_token" : "LzYBc7QEElr85m3kGJFvHu3AH", "_hashed_password" : "", "facebookFriends" : [ *** ], "email" : "jam323@ufl.edu", "usernameLiteral" : "JerBear323", "displayName" : "Jeremy", "facebookId" : "1010***" }User created with newer version of Parse server:
{ "_id" : "5aDx6moNEU", "username" : "bhaskark2", "usernameLiteral" : "bhaskark2", "displayName" : "bhaskark2", "email" : "b**@gmail.com", "_hashed_password" : "", "_wperm" : [ "5aDx6moNEU" ], "_rperm" : [ "*", "5aDx6moNEU" ], "_acl" : { "5aDx6moNEU" : { "w" : true, "r" : true }, "*" : { "r" : true } }, "_created_at" : ISODate("2017-03-22T17:16:00.908Z"), "_updated_at" : ISODate("2017-03-22T17:16:00.908Z") }@flovilmart I wasn't able to test fix-issue-4897, but I did write a CloudCode job that fixed the ACL's for all users as you suggested. After running, ParseServer 2.82 properly logged in Facebook and Twitter users using FacebookUtils and TwitterUtils. The job is below if anyone needs it:
Parse.Cloud.job("fixLegacyUserPermissions", function(request, status) { // the params passed through the start request var params = request.params; // Headers from the request that triggered the job var headers = request.headers; // get the parse-server logger var log = request.log; // Update the Job status message status.message("Starting to fixLegacyUserPermissions for all activities in DB"); var query = new Parse.Query('_User'); query.notEqualTo('username', null); query.find({useMasterKey: true, success: function(results) { if (results == null){ status.error("Warning no results were found in query"); }else{ var counter = 0; var counterForTotalObjects = 0; var fixingActivity = false; console.log("Found "+ results.length.toString() + " items that need to be fixed") for (var i = 0; i < results.length; i++) { var object = results[i]; var newACL = new Parse.ACL(); newACL.setWriteAccess(object, true); newACL.setReadAccess(object, true); newACL.setPublicReadAccess(true); object.setACL(newACL); object.save(null, {useMasterKey: true, success: function(){ counter = counter + 1; status.message("Updated permissions for " + counter.toString() + " Users " + object.id); counterForTotalObjects = counterForTotalObjects + 1; if(counterForTotalObjects == (results.length)){ status.success("Fixed " + counter + " items"); } }, error: function(returnedError) { status.error("Error in fixLegacyUserPermissions: " + returnedError); counterForTotalObjects = counterForTotalObjects + 1; if(counterForTotalObjects == (results.length)){ status.success(); } } }); } } if (!fixingActivity){ status.message("No users needed to be fixed"); status.success(); } }, error: function(error){ status.error('Error saving User.'+error.toString()); } }); });flovilmart commentedon Jul 18, 2018
Awesome! If that’s resolved for you then that’s awesome!