Can anyone explain to me how authentication works with JS-based storage client like this?
It scares me to think a user might have the ability to store anything via the web on my dime. I feel like I'm missing something.
It scares me to think a user might have the ability to store anything via the web on my dime. I feel like I'm missing something.
https://parse.com/docs/data#security
You should be able use these in combination to secure your app. If you have more specific questions about how to secure a particular use case, drop us an email at feedback@parse.com and we can help figure something out.
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.
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.
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.
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.
https://www.parse.com/docs/js_guide#users
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.
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!
We should definitely make the documentation clearer on this point, because this is all stuff that should Just Work.
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.
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?