Parse Pointer Permissions don't allow create

Question

I've followed every step of this walkthrough, but when I try to create a new row, I get a 403:

code: 119

message: "This user is not allowed to perform the create operation on Messages. You can change this setting in the Data Browser."

My code:

Messages = Parse.Object.extend("Messages")
var message = new Messages();
message.set("sender", Parse.User.current());
message.set("receiver", *anotherUser*);
message.set("subject", "foo")
message.set("body", "bar")
message.save()
.then(
  function(message){
    console.log("success!")
  },function(error){
    console.log("error: ", error);
});

My CLPs are set as follows:

It looks like someone else posted the same issue in a google group. What are we missing?

Have you checked to see if the what the value is of Parse.User.current()? My guess is that it's returning a nil user. Also, I've always used PFUser.currentUser(), so maybe give that a go too — Russell
– Russell, Commented Oct 23, 2015 at 18:45
Just double-checked–I console.log it out just before I save it, and it is a valid user object with an id. — adamdport
– adamdport, Commented Oct 23, 2015 at 20:12
Is it different from request.user? Try logging that too to see if they are different — Russell
– Russell, Commented Oct 23, 2015 at 21:08
They're the same. Just modified my cloudcode as requested and see in my logs, before_save triggered for Messages for user xxxx, where xxxx is the same as the sender field. — adamdport
– adamdport, Commented Oct 23, 2015 at 21:36
@Russell have you ever used pointer permissions and had create work as expected? — adamdport
– adamdport, Commented Oct 24, 2015 at 21:37

adamdport · Accepted Answer · 2016-01-07 18:57:23Z

17

I've submitted this as a bug to Parse (Facebook), and they replied:

We have managed to reproduce this issue and it appears to be a valid bug. We are assigning this to the appropriate team.

I will update this answer once the issue has been resolved. If this issue is impacting you, please subscribe to the bug, as this will help prioritize the fix.

UPDATE

Facebook replied:

Turns out that this is actually by design. To create an object, the class should have public create permissions on it

Unfortunately, with this solution, I can create a message "from" any other user (another user set as the sender). This is unacceptable and unusable IMHO.

edited Jan 7, 2016 at 18:57

answered Oct 26, 2015 at 15:02

adamdport

12.9k15 gold badges74 silver badges94 bronze badges

Sign up to request clarification or add additional context in comments.

Comments

Nikolay Valtchanov · Accepted Answer · 2015-10-27 01:50:51Z

That has been a bug since the launch of Pointer Permissions, which effectively makes them useless. My impression is they built this with the idea of letting developers secure existing schemas in one go, but of course you need it to work for future creation.

One workaround would involve combining the older Class Level Permissions and per-row ACL's while being careful to not disable your Data Browser. Let's assume you have classes "Puppy" and "Cat" and both have a field called "owner".

In your Data Browser, for each class where it makes sense to have an owner field, you set its Class Level Permissions for Puppy and Cat each to:

Public - Read: Yes or No, depends on your use case, Write: Yes

Add a Pointer Permission for "owner" - Read: Yes, Write: Yes (can skip this for now, see below)

Then in your cloud/main.js, you can use the following as a starting point (which I often call "types" below, sorry).
When Parse fixes the creation issue, you remove the Public Write Class Level permission (above), leave the Pointer Permission one, and get rid of the workaround code below.

--

var validateAndUpdateOwnerWritePerms = function(request){
    var object = request.object;
    var error = null;
    var owner = object.get('owner');

    if (!Parse.User.current()) {
        error = 'User session required to create or modify object.';
    } else if (!owner) {
        error = 'Owner expected, but not found.';
    } else if (owner && owner.id != Parse.User.current().id && !object.existed()) {
        error = 'User session must match the owner field in the new object.';
    }

    if (request.master) {
        error = null;
    }

    if (error) {
        return error;
    }

    if (object.existed()) {
        return null;
    }

    var acl = new Parse.ACL();
    acl.setReadAccess(owner, true);
    acl.setWriteAccess(owner, true);

    object.setACL(acl);

    return null;
}

// Wrapper that makes beforeSave, beforeDelete, etc. respect master-key calls.
// If you use one of those hooks directly, your tests or admin
// console may not work.
var adminWriteHook = function(cloudHook, dataType, callback) {
    cloudHook(dataType, function(request, response) {
        if (request.master) {
            Parse.Cloud.useMasterKey();
        } else {
            var noUserAllowed = false;
            if (cloudHook == Parse.Cloud.beforeSave &&
                (dataType == Parse.Installation || dataType == Parse.User)) {
                    noUserAllowed = true;
            }
            if (!noUserAllowed && !Parse.User.current()) {
                response.error('Neither user session, nor master key was found.');
                return null;
            }
        }

        return callback(request, response);
    });
};

// Set hooks for permission checks to run on delete and save.
var beforeOwnedTypeWriteHook = function(type) {
    var callback = function (request, response) {
        var error = validateAndUpdateOwnerWritePerms(request);
        if (error) {
            response.error(error);
            return;
        }
        response.success();
    };
    return adminWriteHook(Parse.Cloud.beforeSave, type, callback);
    return adminWriteHook(Parse.Cloud.beforeDelete, type, callback);
};

beforeOwnedTypeWriteHook('Puppy');
beforeOwnedTypeWriteHook('Cat');

Mo Nazemi · Accepted Answer · 2015-10-23 18:44:18Z

2

Unfortunately it seems that Parse Pointer Permissions do not work as you expect it on Create. The quick fix would be to allow Create permission to Public. Then to ensure that the user who is creating a record is the same as the sender. So you need to perform a manual check in the beforeSave trigger for Messages class in cloud code and if that check fails, reject the record being created.

answered Oct 23, 2015 at 18:44

Mo Nazemi

2,7472 gold badges20 silver badges25 bronze badges

6 Comments

Russell Over a year ago

Good idea about utilizing cloud code but it's always best to use CLPs and ACLs where possible. Since the current user of the app is creating the message object, there shouldn't be any issues. My guess is that there is an error with Parse.User.current() returning nil

adamdport Over a year ago

What does granting create permission do then?

Mo Nazemi Over a year ago

@Russell As I said pointer permissions unfortunately somehow do not work when sender is creating a record. You need to grant create permissions without them @@adamdport By granting Create permission you let anyone create a record in that class. Add the simple cloud code logic and now only the Sender will be able to create a record. Problem solved as you get the expected behaviour

adamdport Over a year ago

@MoNazemi I meant what does create do as a pointer CLP, not public. I have no doubts that I could manage these permissions manually through Cloud Code, but I'd like to leverage Parse's OTC solutions whenever possible.

Mo Nazemi Over a year ago

Sadly it does nothing !! Create does not seems to work at all. The workaround given is the only way around it as far as I know. This to me should be reported as a bug to Parse.

|

Collectives™ on Stack Overflow

Parse Pointer Permissions don't allow create

3 Answers 3

UPDATE

Comments

Comments

6 Comments

Your Answer

Hot Network Questions

Collectives™ on Stack Overflow

3 Answers 3

UPDATE

Comments

Comments

6 Comments

Your Answer

Sign up or log in

Post as a guest

Related