Invalid session not throwing error

[nitrag]

"enableAnonymousUsers": false

Yet ... I can still make curl requests with a purposely bad session token and the data is queried successfully from server.

I'll email you the curl command, since the data is private.

[flovilmart]

probably because you still have some _Sessions that are set in the DB.
Also, a bad session token would not throw an error, but just not load the attached user for the request.

I don't think we should throw errors on bad session tokens? @nlutsenko ?

[nitrag]

Nothing in the curl request is user validating. I've cleared the installationId and SessionToken.

I sent you a direct email. Only difference is I still had the InstallationId. Clear that and test from your PC. You will see that you get the data yourself.

Unless I'm missing something. Is there IP caching going on behind the scenes that correlateds my IP to a session? Why would sessions in the DB matter when the incoming request has no linkable information?

[gfosco]

Anonymous user support enables an actual _User record to be created, for the user to save and persist private data, etc... It does not affect querying for data that has public read access.

An invalid session token does not throw an error, it is the same as having no session token. You can see the path in middlewares.js and Auth.js, if a session token is invalid, it returns the nobody auth object. This behavior is the same on Parse.com.

[nitrag]

Well, hold on...

So what's stopping anyone from coming in and grabbing all your data? I could write a simple rest query and cURL an entire table from someone's Parse database? This is especially important since application and client keys aren't foolproof. Am I supposed to restrict everything with CLP and ACL and then do a whole bunch of unnecessary intermediary cloud code functions with a valid request.user to get the data? Or need to add every user to a basic role and add role permissions to every object?

To me, enableAnonymousUsers=false means that you need an account to access the API.

Please confirm this and offer any other advice you have on this subject. At this point I will continue to push forward on completely restricting anonymous access.

Is this where I would put the logic to return a Parse Error? Would it bubble back up to the http response?
https://github.com/ParsePlatform/parse-server/blob/master/src/Auth.js#L42

[flovilmart]

I believe you need to read this article: https://parse.com/docs/ios/guide#security

[nitrag]

Yes, yes. I've read it before and again now.

The only thing I can think of is to create a "Role" (eg. "basicuser") and assign that role to every registered user, then add the "basicuser" role to every Class's CLP. Then disable generate read/write access. Is this the proper method for my issue?

Short of that, I see having to create ACL's on every single object. If that's the case, I'd rather just disable any user who is not logged in.

Or am I still missing something? Sorry I'm dense on this. The articles and official parse examples don't touch on this.

[andresgarza]

Shouldn't all requests with an invalid or non-existing session fail? From the Developer's Guide:

When a device's session token no longer corresponds to a Parse.Session object on the Parse Cloud, all API requests from that device will fail with “Error 209: invalid session token”.

The documentation even suggests how to handle that error by logging user out and rendering log in screen.