Skip to content

using include() function with Query fails on Pointer collection CLP restriction #2005

Description

@araskin

Please read the following instructions carefully.

Make sure these boxes are checked before submitting your issue -- thanks for reporting issues back to Parse Server!

Issue Description

I currently have the following code which was migrated from and currently works without a problem on Parse.com

            var Truck = Parse.Object.extend("Truck");
            var truckObject = new Truck();
            truckObject.id = requestParams.truckId;
            query.equalTo("truck", truckObject);

            query.include('vendor', 'truck', 'overrideMenu');
            query.limit(1000);

            return query.find()
            .then(function(scheduleResults){});

The query.find() call fails with the following exception

{"message":"Permission denied for this action.","code":119}

When trouble shooting this issues I noticed that if I remove VENDOR from the INCLUDE function then everything works fine. The VENDOR field is a pointer to a record in the collection called vendor .

The CLP for collection vendor is as follows:

2016-06-08_0713

I noticed that when I check the box for FIND permission on the CLP the error goes away. However I feel that this behavior is incorrect since it is a direct pointer load and should be treated as a GET read rather then a FIND read.

Also passing in useMasterKey also fixes the issue and while in this case it is an acceptable work around I believe the core behavior is wrong when using an include function to load pointer objects with a CLP of GET = false

Steps to reproduce

Please include a detailed list of steps that reproduce the issue. Include curl commands when applicable.

  1. Create a collection object called collection1 with a pointer field to collection2
  2. Uncheck the GET permission on the CLP of collection 2
  3. Run a QUERY on collection1 and include a call to the include function so that the full row of collection2 is loaded as well.

The call will fail with a permission error.

Expected Results

Since I assume that the include does a GET I don't see why the query would fail. My assumption is the the collection2 pointer field would load successfully

{"message":"Permission denied for this action.","code":119}

[FILL THIS OUT]

Environment Setup

  • Server
    • parse-server version: 2.15.5
    • Operating System: Mac OS X (nodeJS running locally)
    • Hardware: Macbook Air
    • Localhost or remote server? local
  • Database
    • MongoDB version: [3.1.0-1.5
    • Storage engine: Dont know
    • Hardware: AWS
    • Localhost or remote server? Remote server running on AWS

Logs/Trace

You can turn on additional logging by configuring VERBOSE=1 in your environment.

[FILL THIS OUT]

Activity

  1. sprabs commented on Jun 15, 2016

    @sprabs

    I have not had this problem. FWIW, in my code (at least with an older version of the JSSDK), it would complain if I tried to do:
    query.include('vendor', 'truck', 'overrideMenu')

    My structure is more like...
    query.include(["vendor", "truck", "overrideMenu"])

    Don't know if that was corrected in later versions of the SDK and I just have the array formatting in there due to legacy reasons, but thought I would share.

  2. araskin commented on Jun 15, 2016

    @araskin
    Author

    Thanks for your comments. I did try putting it in an array like you suggested.

    In your code, does "vendor" have a CLP where FIND is unchecked? When I check that box on "vendor" CLP the issue is resolved.

  3. sprabs commented on Jun 15, 2016

    @sprabs

    @araskin Was the column in question added after you did the Parse migration? I remember earlier on, I did notice something off about one of my columns... and it was related to permissions.

  4. tarekskr commented on Jun 19, 2016

    @tarekskr

    I can successfully replicate your problem. I believe the issue is due to Parse internally using FIND instead of GET when executing query includes.

  5. araskin commented on Jun 19, 2016

    @araskin
    Author

    @sprabs No the column was part of the original collection prior to the migration.

    Thanks @tarekskr . That analysis makes sense. For now, I am just using the masterKey flag to work around the problem but I guess it should be fixed.

  6. tarekskr commented on Jun 19, 2016

    @tarekskr

    @araskin Just make sure you're never using the masterKey outside of Cloud Code. Never on the client side of course.

  7. araskin commented on Jun 19, 2016

    @araskin
    Author

    @tarekskr absolutely. I try to avoid any direct REST API calls (though I do have some). Almost all of the calls from the front end or to specifically created cloud code functions.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Metadata

Metadata

Assignees

No one assigned

    Labels

    type:bugImpaired feature or lacking behavior that is likely assumed

    Type

    No type

    Projects

    No projects

      Milestone

      No milestone

      Relationships

      None yet

      Development

      No branches or pull requests

      Issue actions