Another way of wording his (and my) concern is how do you securely identify the user? Nevermind the permissions model (ACL), how do you actually ensure the user is who they say they are, and how tamper-proof is this authentication.
Nothing in their documentation provides any details on this. The security section is filled with details on how to specify access levels, but I can't find anything about how they guarantee Fred is actually Fred and not Bob with firebug open.
For secure user identification we have the typical username/password model. You don't have to expose that to end users, so you can also cross-authenticate with your own systems. The password is only stored on the server, with a client-side token. There's more documentation for this here:
It looks like this information is in our "Users" section rather than our "Security" section - we should clean that up in our docs to make it easier to find the right information.
I have a question: Is there a possibility to "disable" the automatic creation of new classes? because if I understand the documentation right, then it would be possible for any user to spam my model with new classes.
Note that, as far as I can see, Classes are a SDK convenience but the data itself is completely schemaless as far as the Parse backend is concerned.
I've wondered about this aspect of Parse for months but not seen a satisfactory answer yet. With the client-side credentials for a Parse app readily available, a malicious user could store any amount and type of data in that app's store, with that app footing the bill.
The easiness of hacking the existing data (say, your SpaceBucks premium currency in a game) is a secondary concern, but it's valid to say that for that extra level of security you need your own servers and logic, and Parse is not the right service.
Great. I actually read through the "Users" section and didn't see anything about the client-side authentication token.
So I assume we get the token back from the auth call, then we can cookie it for future requests? Once we lose it (cookie expires, cleared, etc.) we just need to authenticate them again. What does the cookie look like? essentially a uuid? How many characters?
It seems like storing the token on the client happens behind the scenes and is checked automatically for calls requiring secured access?
I'd love to see a little more detail in the docs about this.
Assuming auth is handled properly, this is awesome!
Actually, the Javascript SDK handles the auth token for you. Once you have successfully completed a logIn or signUp, the token is stored in localStorage until logOut is called. And then it is passed along with subsequent requests to authenticate. So, you don't need to worry about how many characters the token is, or things like that.
We should definitely make the documentation clearer on this point, because this is all stuff that should Just Work.
This has always been my concern (perhaps naive) with any (not just this) javascript SDK. It seems that it would be very easy, and almost inviting, for a malicious user to script a spam attack using the javascript console in their browser, and perform a large number of inserts to the database before you can detect this and disable their account.
Are there common javascript development practices or conventions to prevent malicious users from writing an infinite loop (as pseudo-coded in the post above) and spamming your data set?
Nothing in their documentation provides any details on this. The security section is filled with details on how to specify access levels, but I can't find anything about how they guarantee Fred is actually Fred and not Bob with firebug open.