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.

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.