How do I prevent a parse.com user from seeing parts of their user data? aka set ACL per field on User class?

Question

I add new users. Let's presume we add a field of 'additionaldata1' on the parse user class

I do NOT want the user to be able to see the data stored in 'additionaldata1' and as such don't want it returned when I query the current parse users.

Seeing as the code is a web.app I don't want it to be possible for a user to 'hack' the local code in order to bring back 'all' their user object data.

So my question is how do I ensure that certain fields such as 'additionaldata1' are NEVER returned on the parse.com user object? Do I have to set up an additional class that is related to the user but set the ACL as non-read? Or can I set ACL per field on the user class?

EDIT// UPDATE: I believe I worked this out myself. It doesn't appear to be possible to set ACL per field on a class. As such I have to add this data into an additional class with a RELATION and then set the ACL on that class table to 'no read' and 'no write'. That way only cloud code can see the class values due to the master key and I can run any validation and queries via cloud code where I need that data to be secure / private from the user.

Answer 1

This case is mentioned in Parse Docs under one-to-one relational data https://www.parse.com/docs/relations_guide#onetoone_anchor.

They recommend that you split up the data into two tables and use a one-to-one:

In Parse, a one-to-one relationship is great for situations where you need to split one object into two objects. These situations should be rare, but two examples include:

Limiting visibility of some user data. In this scenario, you would split the object in two, where one portion of the object contains data that is visible to other users, while the related object contains data that is private to the original user (and protected via ACLs).

Splitting up an object for size. In this scenario, your original object is greater than the 128K maximum size permitted for an object, so you decide to create a secondary object to house extra data. It is usually better to design your data model to avoid objects this large, rather than splitting them up. If you can't avoid doing so, you can also consider storing large data in a Parse File.