protectedFields vs. userSensitiveFields

On parse-server 2.7.x version has userSensitiveFields, not protectedFields.

There is a big different between userSensitiveFields(2.7x.) and protectedFields(latest version)

On pare-server 2.7, userSensitiveFields option make allow to access some fields of User to that user and masterkey.
For example,

  • User class has zip field.
  • parseOpiton has userSensitiveFields : "zip"
  • with a session token of A User, a result of find query has only A's zip field.

On latest version of parse-server, protectedFields option prevent only request without session token.
For example.,

  • User class has zip field.
  • parseOption has protectedFields: { _User: { '*': ['zip'] } }
  • with out any session token, no zip fiendl.
  • with any session token, a result of find query has zip fileds of all users.

I think protectedFields should be work the same way as userSensitiveFields, isn’t it?

All help and comment would be appreciated.


How delete userSensitiveFields (2.7.9)

How delete protectedFields (latest version)

That’s not true. In the example you gave, the user would be able to get their own zip by using their own session token or master key. Take a look in these test cases:


Best!

Thank you for reply. :smile:
I already know that test case. I mentioned another case.
My test case is “should NOT be able to get others PII via API with object”
For example, User “A” should’t be able to get User “B”’s PII using sessionToken of User “A”

But current version can do that.

Sorry for the misunderstanding, but I think it is not true as well :smile:

User A cannot use their credentials to access protected fields of User B.

Take a look in this test case here:

Yes, I know. Almost there. :slight_smile:

That test case is fetching user list with .equalTo('objectId', user.id). It should not be able to get user PII via API with Find as we expect.

But fetching user list without .equalTo('objectId', user.id), the results has PII of all users. The result has all PII of all users.
I made some test case described what I mentioned. put this test case below the case you mentioned.
This case fails.

it('should not be able to get user PII via API with Find without constraints', done => {
  new Parse.Query(Parse.User)
    .find()
    .then(fetchedUser => {
      // caution : anotherUser is current loggedin User. :)
      fetchedUser = fetchedUser.find(u => u.id !== anotherUser.id);
      expect(fetchedUser.get('email')).toBe(undefined);
      expect(fetchedUser.get('zip')).toBe(undefined);
      expect(fetchedUser.get('ssn')).toBe(undefined);
      done();
    })
    .catch(done.fail);
});
1 Like

I think the below code make this result. All requests with user sessionToken and no query keys, pass this “if condition”. no protection fields work in this case.
@davimacedo Do you know what is this code for?

1 Like

It seems that you have found a bug. Do you mind to open a PR in Parse Server repo with this new test case that you wrote? I don’t know exactly why this code exists but I can try to understand and solve the bug.

Ok! I’ll open a PR :slight_smile:

1 Like

Hey guys this is a great feature. Can this be currently applied to Parse.Config? I mean, like preventing users from retrieving all config fields without the master key. This would be useful for configuring stuff like private api keys without having to rebuild the cloud code.

Yes. Take a look in this PR here that was recently merged and already available at Parse 3.8.0.

2 Likes