Email field is no longer present in PFUsers returned from query

[zingano]

We use GitHub Issues for bugs.

If you have a non-bug question, ask on Stack Overflow or Server Fault:

• https://stackoverflow.com/questions/tagged/parse.com
• https://serverfault.com/tags/parse

You may also search through existing issues before opening a new one: https://github.com/ParsePlatform/Parse-Server/issues?utf8=%E2%9C%93&q=is%3Aissue

--- Please use this template. If you don't use this template, your issue may be closed without comment. ---

Issue Description

My system has an OS X admin app which is available to trusted administrators only and these admins' PFUser objects are members of a privileged "Admin" Role. The administrators need access to the ordinary iPhone users' emails to contact them about their submissions, among other things.

Each iPhone PFUser in the database is readable by itself and by the Admin role.

For the simplest example, my admin app (Mac OS X) shows a table of users of my iPhone app.

In Parse server 2.2.24, the email column is completed with valid user emails.
In Parse server 2.4.0, this column is blank. The PFUser object that is fetched has no email property.

There were no changes in my OS X application.

Steps to reproduce

Query on the PFUser table returning e.g. newest 100 users.

Expected Results

User email property present

Actual Outcome

User email property not present (null)

Environment Setup

• Server

  • parse-server version 2.4.2
  • Operating System:
  • Hardware:
  • Localhost or remote server? Heroku

• Database

  • MongoDB version: 3.2
  • Storage engine:
  • Hardware:
  • Localhost or remote server? mLab

Logs/Trace

Include all relevant logs. You can turn on additional logging by configuring VERBOSE=1 in your environment.

[natanrolnik]

Closing as duplicate of #3301.
This is a subject that was discussed a lot, due to an intentional change by @acinader. It won't be changed. You can see in the issue I linked the reasons and the suggestions on how to deal with this (not so) new security measure.

[zingano]

Is my case not different, in that the admin user trying to read this other user has the Admin role, which has read access? Does this not mean that the read access granted to the Admin role is not truly read access?

This feels entirely wrong to me.

(And note, this code worked identically on parse.com)

[zingano]

I suppose this just gets ignored now, as I can't reopen the issue.

To repeat, I have specifically given an Admin role read access to all user data. This is a very valid use case. And those user objects are not just those from a PFQuery, but users found linked by other objects in my admin application.

I'd love to help fix this, but I am an iOS developer, and I think it is beyond me without some help.

[zingano]

So I guess I and others like me are stuck on old versions of Parse server. Which may cause you more issues in the long run.

[zingano]

Also, @acinader seemed perfectly fine with a change to remove the default:

the way i implemented #3158, it is not possible to "unset" email as sensitive field as it is always merged into any config to set additional fields. You could change that. It wouldn't be a big a change and I'd be game to accept it.

[natanrolnik]

It won't be ignored, @zingano.

And no, you are not stuck with an old version. You can write a cloud function that queries _User with the master key, as a proxy for the iOS app query, and update your iOS app to call this function.

@acinader and @flovilmart might answer better. And if he said he is ok with accepting a change, you are more than welcome to provide a PR.

[zingano]

Thanks, but like I said, I'm an iOS (and OS X) developer, not a server engineer. So I guess I'll have to stick to the release before this was introduced if no-one else sees the fact that a role explicitly given a access in each user's ACL is NOT ALLOWED TO READ.

[natanrolnik]

Are you able to write cloud functions in JS? That should be enough to solve your problem, as long as you can update the iOS app.

[pungme]

@zingano I can create PR for this case (remove default = ['email']) and let see if it get accepted or not.

[pungme]

@zingano on second thought, I think it's better to keep it this way. In your case, the work around would be you have a cloud code function where inside you check the role of that user, if that user is Admin, then do query with masterKey and throw the results back to client.

The best way in the near future for parse-server to support this would be that we have column level permission where you can set the role to the column just like CLP or ACL.

[awgeorge]

The solution to this, is to implement the agreed changes in #3588

[flovilmart]

@awgeorge feel free to open a PR for the implementation of #3588! That would be nice!