User email field values not returned

Parse Server 📡 GraphQL API
1

In a fresh parse-server instance (i.e. all CLPs and ACLs are defaults), I create two example users using a signUp mutation. I then query all the users. I’m passing user joe's valid session token in my header. Here’s my query:

query {
  users {
    edges {
      node {
        id
        email
        username
      }
    }
  }
}

For some reason, all the data I expect does comes back except for the email field values of any user other than the user for whom the session token applies.

{
  "data": {
    "users": {
      "edges": [
        {
          "node": {
            "id": "X1VzZXI6MTZuY0U3RHJ3UA==",
            "email": "[email protected]",
            "username": "joe"
          }
        },
        {
          "node": {
            "id": "X1VzZXI6OFFlVk1TT0I2RQ==",
            "email": null, // This value should be populated too
            "username": "tom"
          }
        }
      ]
    }
  }
}

If I pass the master key header with my query, then all the email fields for all the users are returned as expected, but I feel there should be a way to achieve this same result via session token use too. Public read/write access is enabled for the User class CLP and ACL levels, so I’m not sure what else to try. What am I missing?

2

That’s actually the expected behavior. Email in the user class is a protected field by default and can only be returned by using the master key.

1 Like
3

So it’s a known thing then. Thank you. I tried to find mention of this behavior in the docs, but came up empty. I have some follow up questions:

  1. You mention the email field is protected by default. Does that mean it’s protected state is modifiable, or just that it’s locked down period?
  2. Other than password, are there any other User class fields that can’t be queried outside of using the master key, or is email the only one?
  3. Not being able to query another user’s email field at all outside of Cloud Code and master key use feels more like a quirk to me than a feature, since username can be queried. If I may ask, why would the email field be handled this way?
  4. Is this restricted behavior mentioned in the docs somewhere, or should it be?
4

You can also unprotect the field by setting: “*”: in User protected fields.

5

I believe email can’t be overridden. See this test case: https://github.com/parse-community/parse-server/blob/master/spec/ProtectedFields.spec.js#L106

6
  1. I believe the rule for email is not modifiable but I actually haven’t tried to modify
  2. E-mail and password by default, but you can define more for any class using the protectedFields option in Parse Server initialization
  3. username is not solely intended to store the email, and, in the case you are storing the emails in the username column, I’d also add username to the protected fields of the user class. The reason behind this I believe that’s because email is a user sensitive information. If you do not protect this field, any authenticated user will be able to retrieve the email address of your entire user base.
  4. I believe it is not mentioned yet. I’ve basically learned by looking at the test cases. I believe we should have a section in the Parse Server guide just talking about the protectedFields option.
7

Thank you both. Very helpful. I can confirm that email cannot be overridden. It remains a protected field. I used setCLP() to set it and can see the schema no longer shows email as being a protected field, but it is. So the test case was correct (of course).

Indeed, a section in the docs on protected fields would be helpful. When you first mentioned the email field was protected, it didn’t occur to me that that was what you meant.

Maybe it would be a breaking change, but I can’t help but think that given there’s an official mechanism built into Parse to manage protected fields, it is somewhat counter-intuitive and maybe a little heavy to not allow the email field to be unprotected under any circumstance.

Ironically, a developer can store a user’s email address to a custom userEmail field. Doing so would be considered a workaround. Some might say the ability to work around the issue shows there’s no need for Parse to allow the email field to be unprotected. Others might say the workaround merely shows that one can get around the protection so why not allow it to be done in an official way.

Thanks again. I appreciate all your help!

8

I see what you say but in my point of view we should move in the direction of having more restrictive default setup (and not less restrictive), and, more important, better document all options and the risks that the developers are taking in the case they decide to workaround the default configuration. I understand your point of view though and I agree that the current state is very confusing and we should have better docs about all security options we currently have in Parse Server.

1 Like
9

All okay. To be clear, I agree with you re: defaults. I’ve seen the other thread about it and that makes sense to pursue. Well-considered reasonable defaults are good.

This particular issue is different, though. Parse isn’t allowing something other than the default even if the risks are understood and the action could be achieved in some other way, and a method to do it officially appears to exist, but doesn’t work.

10

Yes. I misunderstood your first message. You are proposing that email default behavior should be modifiable. I think it makes sense. Could you please open an issue in the open source repo so we can further discuss it and see the opinion of the other maintainers?

11

Sure thing, thanks for considering.

1 Like