Server-side logic. The difference is that traditional data flow is UserControlledCode (i.e. client-side JS) --> MyServer --> DataStore, whereas this is UserControlledCode --> DataStore. In practice you may often choose not to have the code in MyServer do anything beyond act as a pass-through, but not having that option at all seems scary. The only recourse I see is things like database schema constraints (e.g. max posts per user = 10), but that doesn't really solve the problem.
Edit: And I should add that the problem isn't just a user creating new many objects. The problem is that without code controlled exclusively by me somewhere in the middle, business logic (i.e. anything not codified in your database schema) becomes unenforceable. E.g. pull up firebug and type player.levelUp(); player.save();. Now there may be some subset of applications where business logic like this is completely unnecessary, but I can't think of many.
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?
I can't see it working well in a game scenario, but the vast majority of CRUD apps out there could be safely implemented using Parse's security model (as described in lacker's link).
They use a game in their JS documentation! And as they wrote it it's totally vulnerable to the user incrementing their own score.
It's not just games, either. As soon as a client-server solution gets beyond utterly trivial it becomes hard to see how you'd do it without server logic.
Take another example described in lacker's link -- a messageboard post: the ACL defines whether or not a user can make a new post, but what controls the content of that post? What forces HTML tags to be dropped, or limits the number of images in a post, or the size of the post, or checks the domains of links, or prevents xss, or rate-limits a user?
Some of this you can do by treating your entire database as "dirty" and sanitising things on the way out, too, but that doesn't come close to squaring the circle.
I think this is the answer from their docs:
--------------------
All operations are still possible when authenticating with the master key via the REST API. As a developer, this lets you manage any aspect of the data. For example, you can delete private messages via the REST API even if they are private based on the ACL.
------------------------------------
So you really need a intermediate and secure server if you are doing something that needs to be trusted. To have a game completely offline would be a recipe for disaster.
You'd probably want to push events into the users profile, have the game ping your server to tell it that there are events waiting, Pull those events on your server and then increment the score. On your server you can have sanity checks and do cheat detection.
Yeah -- but I think a service that offers to handle all the server stuff for you that also requires you to set up a server has missed a step somewhere.
