Hi. I've run into quite a few problems with the user class. Let me try to break them down. For reference, I'm using Kinvey 1.24, due to the user query bug in Kinvey 1.25.



On several occasions, I've had a password column appear in the user class on the backend. The password for one of the users will show up as null. At that point, the user gets locked out of the system and can't log in again. This even happened with a Facebook user, who normally doesn't even have to enter a password. He became locked out too. We don't have any code related to the password field outside of the sign-up block for non-Facebook users.



The email field (one of the standard fields on user) also seems to get corrupted at times. On multiple occasions, the email address of all of users in the backend changed to the same email address of one of the other users. The only time email is ever mentioned in the code is during the sign-up block. This glitch doesn't seem to happen when anyone signs-up though.



Of less concern, I have an attribute on the user called displayName. It seemed to work fine on version 1.25, but 1.24 seems to populate it with the username on signup. Perhaps somebody can confirm that is something Kinvey used to do?



This is all still in a test environment, but having passwords set to null and email addresses changing has made me quite nervous. Are these problems with the email and password fields documented? I understand that I could have problems in my code, but I don't have any code that should change the email or password fields. Any help would be appreciated. Thanks.

I've been able to duplicate the password corruption. Here's the situation. We've got a game in which users can attack other users who aren't currently logged-in. After the attack, we need to adjust some attributes on the user who got attacked. We thought it would be more secure to make these changes through business logic with custom endpoints, rather than setting the user collection permissions to full. After calling the custom endpoint which updates the user, that user is no longer able to log-in (although his updated data looks correct on the backend).



So this leads to a few questions. One, is it possible to update other users through custom endpoints while the user collection is set to shared instead of full? If so, how can I do it without corrupting the password field? Do we need to do something special with the master key in our endpoint? Two, is this a more secure approach than just setting user permissions to full, and making the updates on other users in our application? Thanks.

The user collection isa special case in that the password is not returned when querying the user collection. The update operation will do a full update of the document passed, and since the document retrieved doesn't include the password, the password gets overwritten with a null value and is impossible to recover from.



The two options available are to separate user profile data into a separate collection from user to avoid this problem altogether. Alternatively, you could use the $set operator to only set the fields you want to modify. This would leave the password intact.



For example:



userCollection.update( { _id: "abc123" },

{ $set: {

field1: 500,

field2: true

}

}, callback);

@Michael - The set operator seems to fix the password problem. Thanks!