问题
I'm trying to determine the best approach for the following scenario using Parse and a Backbone front end. I want to build a discussion thread where two or more users, of various roles (ie: member, admin, etc), are able to communicate by posting simple messages which will appear in a chronological list. The messages would appear with the users name, users photo, the date it was posted and the message content.
My initial instinct was to create a Message class in Parse with the following fields:
- title (string)
- message (string)
- author (pointer)
Then when I load the messages for the thread I would include the author relationship so I could get necessary info like their name and profile image.
var query = Parse.Query('Message');
query.include('author');
query.find({
success: function(msgs) {...},
error: function(error) {...}
});
This works, and is all fine and dandy but then I got thinking about the ACL's I will be using to lock down my data and it occurred to me that I wouldn't want any user except an admin being able to see other users information.
Sooooo that brings to my dilemma, how can I limit the data that is available through this relationship so all user data isn't accessible but we can still access the users name and profile pic?
I know I could always save the authors name and pic to the message record itself so I wouldn't need to access the relationship but that runs into the problem of changing data on the authors side like a new profile pic or name update that then is not reflected in the message thread.
Cloud code is another option where by I could hand pick the fields to return but that seemed like a lot of work if this scenario existed in a lot of places in your app.
Hopefully someone has some insight on this issue as I'm sure it's reasonably common in SPA world, I just didn't know how to phrase the question in a search so I haven't found anything.
Thanks!
回答1:
Consider that user-to-user conversations in a public system really ought to be between users' personae.
personaA <-> personaB
| |
userA userB
I would create a Persona table that is a user's public face. It would contain nickname (distinct from but maybe equal to username), photo and so on, as well as a pointer back to the user table, which would remain fully locked down at the class level.
回答2:
The User
class by default is rather "open" as far as security is concerned. For example anyone that can get your keys (which is not hard in iOS, Android or JavaScript) can enumerate a lot of your columns (username, email are accessible however password is not). It's best to put all of the sensitive data in the User object and store accessible things like photo, name, etc in another data class. So "author" will be a pointer to a AuthorData
class and you can store a pointer of AuthorData
in the User
object.
This way you can use ACLs to lockdown your User object and then the issue goes away.
来源:https://stackoverflow.com/questions/28752653/parse-data-security-and-relationships