POST operation does not verifying author ID

For ui it checks if user has permission administer nodes, if so, user can change author. User 1 has every permission. Does it work the other way, ie posting node as user 7 with target id 1?

I have also got into this situation and can not get a user to post any longer. After granting the approved user access to REST permissions and perms to creat/view/edit it seeems to have gotten stuckkkkk. No matter what i do now in the permissions the only users that can now use services to create content are administrators.

#2098355: Missing default access for all node fields recently landed, which implemented base field access control for node fields. I suspect that is related.

I found the issue the permission that needs to be giving to the role that is using the service needs to have the path permission "Create and edit URL aliases". Then everything works again.

Is this something the REST api should fix? Just a solution for author uid would not be suitable. When doing form alters it is possible to deny access to a piece of form using #access. This is not handled by sending json data. A proper solution would be node validations / field validations whether certain values are permitted.

Thanks #6

In Drupal 8, I was getting

error": "Access denied on creating field "

while trying to do a basic hal+json POST over the REST API using an authenticated user.

I wasn't including a URL or Path Alias, just a Title as shown below, but that still returned a "403 Forbidden" response.

Enabling "Create and edit URL aliases" under /admin/people/permissions made it work.

Basic hal+json POST Example
Note: you'll need to change out the href to your domain and "your-node-type" should be whatever content type (page, article, or your custom type)

{
    "_links": {
        "type": {
            "href": "http://example.com/rest/type/node/your-node-type"
        }
    },
    "title": [
        {
            "value": "Any Title"
        }
    ]
}

#2098355: Missing default access for all node fields fixed this. I worked on manually reproducing this, and got the expected response:

{"error":"Access denied on creating field 'uid'"}