sessionTokens / ACLs are not transmitted to queries triggered by CloudCoude

[SebC99]

Issue Description

When a user calls a cloudcode function, he's identified as the request.user
This user is used for all the ACLs. As an example it's taken into account for saving objects.

But if the cloudcode function performs a query, it seems it doesn't pass the sessionToken in the rest request, as the query doesn't use the right ACLs.

Steps to reproduce

I create a PFObject with a read/write ACL for the currentUser only
If I use the JS SDK to perform a query on that object, it works perfectly
If I use a cloud function which perform the exact same query, I have no result

Expected Results

The query triggered by the cloud function should be "identified" with the same user to respect the ACLs

Environment Setup

• Server

  • parse-server version : 2.7.4
  • Localhost or remote server? Localhost && AWS

• Database

  • MongoDB version: 3.6
  • Storage engine: WiredTiger
  • Localhost or remote server: Atlas

[georgesjamous]

Try this..
This is how it should be done in cloud code, you have to pass the session explicitly:

const auth = { sessionToken : request.user.getSessionToken() } // using session
const auth = { useMasterKey: true } // using master
query.find( auth )
query.first( auth )
object.save({}, auth)
object.destroy( auth )
Parse.Object.saveAll( objects , auth )

[SebC99]

I'll try, but having to pass the request object (or the user object) to every sub-method call is not very convenient, and doesn't help clean code with small methods ;)

I thought the default mode would be to keep using the sessionToken except if useMasterKey is used (which seems to be the case if you simply call a save() in the cloud function)

[georgesjamous]

This will answer your question.
Read this

[georgesjamous]

The closest solution I could suggest to you is to create a Parse.Query extension (subclass) and initialize it with a user maybe like this new MyQuery( user )
Then override the .find() method to super.find( auth )

This is the closest as you will get to Parse.com (as far as I know)

[SebC99]

thanks @georgesjamous I'll give it a try :)

[flovilmart]

Closing as this is the expected behaviour. Unless we accomplish a major refactor to cloud code, this is here to stay.