Creating nodes with POST should work without bypass node access permission

To create a node you need to "POST" to "http://www.example.com/node" without any id. You can't specify the id...

Your command is correct...
curl -u restws_user:xxxx --header "Content-Type: application/xml" --data @test1.xml http://www.example.com/node
..but your username isn't. I assume you want to use the included Basic authentication login module, and in order for it to work, you have to use the prefix 'restws' on your user name your trying to log in with.
You can find more details in the Readme.

Hello bailey86, Were you able to resolve this issue? I am seeing the same "403 Forbidden" error when I do a POST
Is there an example of POST with XML payload that works?

Thanks.
Kamran

Hi,

My guess is that it is related to the issue which I'm facing as well when doing CURL from PHP code, using the latest Drupal core and latest dev snapshot of Restws. My code is the following, the code is taken from http://www.barnettech.com/content/restful-webservices-module-restws with slight modifications:

<?php

$node = array(
      'title'     => 'Hello world',
      'body' => array(
        'value' => 'hi there',
        'summary' => 'hi there',
        'format' => 'filtered_html'
      ),
      'comment'   => 2,
      'promote'   => 0,
      'revision'  => 1,
      'log'       => '',
      'status'    => 1,
      'sticky'    => 0,
      'type'      => 'page',
      'language'  => 'und',
      'author'    => 1,
    );

$result = create_entity(json_encode($node));

function create_entity($data) {
  //global $user;
  $crl = curl_init();
  curl_setopt($crl, CURLOPT_URL,"http://<drupal_site>/user/login");
  curl_setopt($crl, CURLOPT_HEADER, 0);
  curl_setopt($crl, CURLOPT_USERAGENT, 'PHP script');
  curl_setopt($crl, CURLOPT_FOLLOWLOCATION, 1);
  curl_setopt($crl, CURLOPT_COOKIEJAR, "/tmp/cookie.txt");
  curl_setopt($crl, CURLOPT_COOKIEFILE, '/tmp/cookie.txt');
  curl_setopt($crl, CURLOPT_POST, TRUE);
  curl_setopt($crl, CURLOPT_POSTFIELDS, "name=<username>&pass=<password>&form_id=user_login");
  curl_setopt($crl, CURLOPT_VERBOSE, true);
  curl_setopt($crl, CURLOPT_COOKIE, session_name() . '=' . session_id());

  ob_start();

  curl_setopt($crl, CURLOPT_HTTPGET, TRUE);
  curl_setopt($crl, CURLOPT_URL, 'http://<drupal_site>/restws/session/token');
  curl_setopt($crl, CURLOPT_NOBODY, FALSE);
  curl_setopt($crl, CURLOPT_HTTPHEADER, '');

  $token = curl_exec($crl);

  ob_end_clean();

  curl_setopt($crl, CURLOPT_HTTPGET, FALSE);
  curl_setopt($crl, CURLOPT_POST, TRUE);
  curl_setopt($crl, CURLOPT_POSTFIELDS, $data);
  curl_setopt($crl, CURLOPT_URL, 'http://<drupal_site>/node');
  curl_setopt($crl, CURLOPT_HTTPHEADER, array('Content-Type: application/json', 'X-CSRF-Token: ' . $token));
  curl_setopt($crl, CURLOPT_RETURNTRANSFER, 1); // output to command line

  $ret = new stdClass;
  $ret->response = curl_exec($crl); // execute and get response
  $ret->error    = curl_error($crl);
  $ret->info     = curl_getinfo($crl);

  var_dump($ret);

  curl_close ($crl);

  unset($crl);

  return;
}

What happens is the user authentication in the first step passes fine with HTTP 200 but when saving the node, it returns response "403 Access Denied: CSRF validation failed".

If I change the url into an existing node url, it will not give the 403 but node is not created either. This behavior is to be expected though as it is supposed to take in only PUT when an existing node url is given.

On a bit of debugging the result, I realized that printing out the $token returns 1 instead of the hash; it appears also as the X-CSRF-Token in the code output.

Did some debugging on the code and it is actually working as expected; the curl_exec returns boolean true/false and in this case, it returns the 1 for success.

The authentication and token retrieval both return HTTP 200 with response "1" on curl_exec() so they obviously get returned correctly but after this when trying to access the url /node for adding new node with POST, it is giving me the 404.

The module sets HTTP status in a few different situations and tried to debug the 404's there but doesn't seem that it's the module which sets the 404 in this case.

Sidenote to my Drupal installation for this case, I'm using Panopoly with Drupal core 7.19.

As you can see in the simpletests of this module POST for creating nodes is working as expected.

This is wrong:

$token = curl_exec($crl);

curl_exec() does not return the contents, you need to set CURLOPT_RETURNTRANSFER, see the PHP documentation about that.

Please try that and report back here.

Hi,

Yes that was actually in my last test, missed it first but added it there. The code now is:

<?php

$node = array(
      'title'     => 'hello from restful services',
      'body' => array(
        'value' => 'hi there',
        'summary' => 'hi there',
        'format' => 'filtered_html'
      ),
      'comment'   => 2,
      'promote'   => 0,
      'revision'  => 1,
      'log'       => '',
      'status'    => 1,
      'sticky'    => 0,
      'type'      => 'page',
      'language'  => 'und',
      'author'    => 1,
    );

$result = add_node(json_encode($node));

function add_node($post_data) {

  $ch = curl_init();
  curl_setopt($ch, CURLOPT_URL,"<drupal_site>/user/login");
  curl_setopt($ch, CURLOPT_HEADER, 0);
  curl_setopt($ch, CURLOPT_USERAGENT, 'PHP script');
  curl_setopt($ch, CURLOPT_FOLLOWLOCATION, 1);
  curl_setopt($ch, CURLOPT_COOKIEJAR, "/tmp/cookie.txt");
  curl_setopt($ch, CURLOPT_COOKIEFILE, '/tmp/cookie.txt');
  curl_setopt($ch, CURLOPT_POST, TRUE);
  curl_setopt($ch, CURLOPT_POSTFIELDS, "name=<username>&pass=<password>&form_id=user_login");
  curl_setopt($ch, CURLOPT_VERBOSE, true);
  curl_setopt($ch, CURLOPT_COOKIE, session_name() . '=' . session_id());

  ob_start();

  curl_exec ($ch);
  curl_setopt($ch, CURLOPT_URL, "<drupal_site>/restws/session/token");
  curl_setopt($ch, CURLOPT_RETURNTRANSFER, 1);

  $HTTP_X_CSRF_TOKEN = curl_exec($ch);

  curl_setopt($ch, CURLOPT_HTTPGET, FALSE);
  curl_setopt($ch, CURLOPT_POST, TRUE);
  curl_setopt($ch, CURLOPT_POSTFIELDS, $post_data);
  curl_setopt($ch, CURLOPT_URL, '<drupal_site>/node');
  curl_setopt($ch, CURLOPT_HTTPHEADER, array('Content-Type: application/json', 'X-CSRF-Token: ' . $HTTP_X_CSRF_TOKEN));
  curl_setopt($ch, CURLOPT_RETURNTRANSFER, 1);

  ob_end_clean();

  $ret = new stdClass;

  $ret->response = curl_exec($ch);
  $ret->error    = curl_error($ch);
  $ret->info     = curl_getinfo($ch);

  print_r($ret);

  curl_close ($ch);

  unset($ch);

  return;
}

What happens now is it returns HTTP 200 for the authentication and for the token; also the token gets set correct. However, now when it tries to add the node, it gives me HTTP 403 Forbidden. The user has full admin rights to the system. Paste of the $ret:

 [response] => 403 Forbidden
    [error] => 
    [info] => Array
        (
            [url] => <drupal site>/node
            [content_type] => text/html
            [http_code] => 403
            [header_size] => 407
            [request_size] => 522
            [filetime] => -1
            [ssl_verify_result] => 0
            [redirect_count] => 0
            [total_time] => 0.407991
            [namelookup_time] => 1.8E-5
            [connect_time] => 1.9E-5
            [pretransfer_time] => 5.8E-5
            [size_upload] => 223
            [size_download] => 13
            [speed_download] => 31
            [speed_upload] => 546
            [download_content_length] => 13
            [upload_content_length] => 223
            [starttransfer_time] => 0.407943
            [redirect_time] => 0
            [certinfo] => Array
                (
                )

            [redirect_url] => 
        )

Looks like you are populating the cookie on your client:

curl_setopt($ch, CURLOPT_COOKIE, session_name() . '=' . session_id());

But you should of course use the cookie that is returned by the server.

Hmm, I don't think it is that one because I just ran it on my home server on a different Drupal installation but same d-core 7.19 and it worked perfect as-is, didn't change a thing except for adding CURLOPT_USERPWD right on the beginning of the code after curl_init because that's needed to get on the server. Will have to continue investigating...

CURLOPT_COOKIE is definitely wrong, since the docs say that this sets the cookie header. But yeah, you are using it on the login request, where it does not make a difference. You can just remove it.

Hi,

Yeah I guess so...will get rid of it, going to check on the other drupal installation tomorrow and try debug why it still gives the 403 there.

Another thing, I just tried to create a Scald Atom for the scald file provider but it gives me again that 403 when trying to create, even tried using the uid 1 of drupal for login and creation.

My question is, has this ever been tested with Scald entities? The code that I'm using is the same as before with just the exception that I changed the following:

curl_setopt($ch, CURLOPT_URL, '<drupal_site>/node');

into

curl_setopt($ch, CURLOPT_URL, '<drupal_site>/scald_atom');

Also changed the $node array into the following:

$node = array(
      'title'     => 'testing scald creation',
      'sid'       => null,
      'provider'  => 'scald_file',
      'base_id'   => 132,
      'data'      => array(),
      'actions'   => 5,
      'scald_authors'    => array(),
      'scald_tags'       => array(),
      'type'      => 'file',
      'publisher'    => 1,
    );

As far as I know, the above should be more than enough for Scald atom creation so don't really see that this could be the reason for the 403.

Thx aalamaki for your code at #14, it worked for me as a simple restws php client :)

Has anyone solved the 403 issue already? I constantly get 403 - forbidden when trying to POST a new node to /node. POSTing to /node/1 (an existing node of the same content type) to create a NEW node works as described in #8, but this doesn't make sense.

When setting the permissions for the logged in user to "Bypass content access control", POSTing to /node works, but I don't want to give the user that permission.

Interestingly, when giving the anonymous user access to the REST resource "node" and giving him the permission to create nodes, POSTing to /node works fine, even when the "Bypass content access control" is NOT set for the anonymous user.

This is really a show stopper for this otherwise great module.

What does the 403 error message say? Looks like you are not sending the CSRF token as authenticated user?

Did you try restws_basic_auth where you don't need the CSRF token?

Yes, I send the CSRF-Token along in the header. Therefore, PUT and DELETE work as they should, and POST also works, but only to node/* instead of to /node. If I did not send the token, neither of that would work.

The return is just '403 - forbidden'. If I omitted the token, it would say '403 - Access Denied: CSRF validation failed'. But that is not the case.

In the Drupal logs the corresponding message is just "access denied".

BTW: I'm testing using Chrome and the Dev http Client plugin.

It is required that the user POSTing the node has the "bypass node access" permission, because entity_metadata_no_hook_node_access() has no other way of granting access on creation. There might be an Entity API issue somewhere to fix that for the create operation.

I tried both restws_basic_auth that comes with restws and the session based authentication that comes with the Services module. With both methods, authentication works flawlessly, but I can't POST a new node to the /node URI without attaching the nid of an existing node.

There it is: #1780646: entity_access() fails to check node type specific create access

I applied patch #136 to the Entity API module as suggested in the thread you pointed to, but with no effect. Could you give some more details?

Thanks very much for your support so far!

No further ideas - you need to debug the cause of the 403. What else is registered on /node on your site? Does the request arrive at RESTWS if you enable logging?

The /node path is actually a drupal system path pointing to the the default front page of each drupal installation. Each node that has the "promoted to frontpage" setting is shown on that page.

It is possible to set another page (or view etc.) as the frontpage in the drupal settings, but the /node URL and the corresponding system page still live in the background. So maybe the attempt to POST something to the /node URL interferes with the drupal core itself?

Can you reproduce the behaviour?

I enabled logging and the request arrives at restws. The logfile says:

2013-07-31T14:59:02+0200
Resource: node
Operation: create
Format: application/json
Id: 
Payload: {
"title":"TEST",
"type":"fs_sub",
"author":{
"id":"5"
}

}

I think something's going wrong in restws.entity.inc after line 286:

if (!user_access('bypass node access')) {
        $this->propertyQueryOperation($query, 'Condition', 'status', 1);
      }

Why? When I set "Bypass content access control" for authenticated users in the permission settings, POSTing to /node works fine.

I am also seeing this issue.

The problem is that restws_entity_node_access() expects a node to be passed-in, but it's getting a NULL instead. That function is actually called indirectly through the entity_access() function (it's the access callback registered on the node entity), which is in turn being called by RestWSEntityResourceController::access(), which is providing NULL for the node parameter when the $id arg is NULL.

So, the call chain looks like this:

1. restws.module: restws_handle_request() calls $resource->access() with a NULL for $id.
2. restws.entity.inc: RestWSEntityResourceController::access() calls entity_access() with a NULL for $entity.
3. entity.module: entity_access() calls restws_entity_node_access() with a NULL for $node.

The isset() check in restws_entity_node_access() looks wrong...

Hmm, nope, wasn't the isset()... It looks like it always needs a node to be passed in to know what type it should be. The question is, how do we get an empty node to pass in? I'm thinking the issue is in restws_handle_request().

Hmm, an even larger problem -- how does the /node endpoint know the content type of the node that is being created? I mean, it can be specified in the JSON, but... it seems like that's too late. All the security checking of handle_request() happens by the time we're digging into the request content.

Oops, didn't mean to set NR on the last comment; meant to set it on this one.

Attached is a patch that address this issue. It's a bit of a larger change than I was hoping for -- I had to change how the security check is being done so that we can detect the bundle type from the incoming request.

With this patch applied, Rest WS seems to now work as expected for the "create" case.

Ummm... pretty sure, my patch didn't break those tests... were they passing previously?

Nope... looks like I *did* break them. It was subtle, but lethal.

Attached is a re-roll with additional concerns addressed. :: fingers crossed ::

How about.... this one?

First we need to know the actual problem. As you can see in the test cases creating nodes with POST works fine, so we need to know what goes wrong with your request.

Actually, the tests *don't* show that. They pass because the logged-in user has permission to bypass the access checks...

I explained the actual problem in #30. The request is not at fault.

PS Here's a sample request to /node that fails unless the user has a role with the "bypass content permissions" permission:
{"type": "article", "title": "This will fail"}

The CSRF header is being passed in, along with the session cookie. Saving works normally with my patch applied.

So... yeah, it's NOT the request.

As was noted earlier in the thread, though, if I create a dummy node (say, nid "2"), and then use the endpoint "/node/2" instead of "node", it works -- for the reasons I explained previously. The code is flawed.

Let's see if this works...

Aha, so this is a feature request that nodes should be working not only with the "bypass node access" permission.

So we already have restws_entity_node_access() as custom access callback for nodes. Now the question is if it gets called correctly from entity_access() and what happens on create.

I don't think we have to change that much code, it is just a matter of correctly invoking restws_entity_node_access().

Also the issue summary is now completely wrong, could you fix that as well?

Okay, several issues:

1. This isn't a feature request. It *is* a bug. The docs indicate that if the user has the appropriate permissions to create the type of content that they're trying to create, they should be able to do so by posting to "/node" with appropriate headers set.

2. The issue summary is *not* completely wrong. It is accurate -- the OP was a symptom of the same problem.

3. As far as I know, the Drupal community takes security very seriously. If we have to give a system account permission to completely bypass all security on all content types just to be able to create one or two posts of a given type, this does not seem to be in line with community expectations.

Ok the entity API issue from #25 got solved but this problem still persists. So #46 is pending or after having a quick look at code.: Can we just remove that access check below and entity API will be smart enough to manage the access control by itself? Of course we would need to set an entity API dependency to the latest version.

/**
 * Access callback for the node entity.
 *
 * Replacement for entity_metadata_no_hook_node_access() because it does not
 * work with the create operation.
 *
 * @todo Remove this once https://drupal.org/node/1780646 is fixed.
 *
 * @see restws_entity_info_alter()
 * @see entity_metadata_no_hook_node_access()
 */
function restws_entity_node_access($op, $node = NULL, $account = NULL) {
[...]

The attached patch solves the issue here and might pass tests: it basically moves the access check for the create op after populating the entity object and before saving it.

Sorry, wrong format

+++ b/restws.module
@@ -129,7 +129,7 @@ function restws_handle_request($op, $format, $resource_name, $id = NULL, $payloa
-    if (user_access('access resource ' . $resource_name) && $resource->access($access_op, $id)) {
+    if (user_access('access resource ' . $resource_name) && ($op == 'create' || $resource->access($access_op, $id))) {

we should not handle this in the global restws_handle_request() function but rather in the access() method of the RestWSEntityResourceController. We should also add a comment why we are making an exception for the create operation.

And we should update our node creation test case, it should work now without the bypass node access permission.

In this patch I've moved the check for access to the access() method with a note.

Because the patch at #52 passes an entity wrapper to the access() function instead of a string, I've also updated the text on the interface class.

I've also removed all reference to "bypass node access" permissions in the tests. This might be totally wrong, and probably should be done more discriminately. I'm interested to see if they pass! :)

Patch and interdiff between this and 50_0 attached.

Ahh, of course. Well, I'll keep looking at that later!

This patch is based on #55 and updates the permissions in the tests. A new test which creates a node with missing permission has been added. Also the access() method will only allow empty entity wrapper, otherwise the create X content permissions is not checked.

Was this patch push live? It seem like a fairly large scale issue to just leave open. Giving a user full bypass access means they can have control to delete, edit, any other users content. I'm not sure why this is ok given the huge security issues it opens up. To @GuyPaddock point the docs state that the REST server will properly give access to roles that are granted, but this isn't the case. I spent the better half of 2 days trying to figure this out before coming to find this thread.

The patch in #58 works for me.

My API user has the "Access the resource node" permission from restws, and the "Create {node type} content" from node module, but not "bypass node access" and I'm able to successfully create a node via a POST request.

I think that this should be higher.

Agreed. this should be reviewed and rolled into dev

After applying the patch in #58, I still got a 403 error on occasion with my API user. After querying the response from the API, I was getting a

Error: 403 Forbidden: Not authorized to set property status

message, and the same for the language property.

After I stopped trying to set these properties, the POST worked fine.

I'm successfully POSTing nodes into Drupal using the restws module and the patch in #58, as well as the configuration in #60 and #63.

did something change is 2.4 release? Just tried to apply patch but im getting errors

restws-1720602-58.patch
patching file restws.entity.inc
Hunk #2 FAILED at 167.
Hunk #3 succeeded at 341 (offset 1 line).
1 out of 3 hunks FAILED -- saving rejects to file restws.entity.inc.rej
patching file restws.test
Hunk #4 succeeded at 131 (offset 53 lines).
Hunk #6 succeeded at 173 (offset 53 lines).
Hunk #8 succeeded at 252 (offset 53 lines).
Hunk #10 succeeded at 341 (offset 53 lines).
Hunk #12 succeeded at 391 (offset 53 lines).
Hunk #14 succeeded at 592 (offset 53 lines).

EDIT: it looks like its conflicting with https://www.drupal.org/node/2090177

Media Crumb, It applies cleanly for me. How are you applying the patch?

Yeah opdavies, the issue was having already patched for the other bug with taxonomy terms. Really with these fixes would get rolled into dev soon

Ah, OK. Yes, hopefully they will get merged in soon.

1. The issue summary is still about being about something other than the issue title.
2. Security Review: So the idea is good in that a REST client can be limited to only posting nodes for which the REST client has access to. Since this was RTBC'd over a year ago, let's just make sure there are no holes opened up. Convince me the user isn't somehow still bypassing node access.

3.   +++ b/restws.entity.inc
     @@ -74,8 +74,8 @@ interface RestWSResourceControllerInterface {
     -   * @param int|string $id
     -   *   The id of the resource.
     +   * @param int|string|object $id
     +   *   The id (or EntityDrupalWrapper in case of 'create') of the resource.
     

   should this variable still be called $id if it's not always an id?

this patch didn't passed the test

This corrects the #71 patches ... (making it test passing)

Patch in #58 allows the correct creation of the new node (without bypass node access permission), but still misses the properties settings task.
This new patch fixes that, allowing the settings of the "status" and "language" properties too.

This new patch fixes that, allowing the settings of the "status" and "language" properties too.
I don't know why this fails testing. It apply correctly (to me) to the current 7.x-2.x-dev

23:25:35 RESTWS Basic Auth 15 passes, 1 fail, and 0 exceptions
23:25:35
23:25:35 Fatal error: Call to a member function attributes() on a non-object in /var/www/html/sites/all/modules/restws/restws.test on line 280

Last try. This new patch just amends two lines from the #58 one (fixing and allowing the settings of the "status" and "language" properties too)

In the /restws.entity.inc file:

- // Get the ID and bundle property names.
- $entity_keys = array_intersect_key($entity_info['entity keys'], array('id' => 1, 'bundle' => 1));

+ // Get the entity keys properties.
+ $entity_keys = array_merge($entity_info['entity keys'], ['status' => 'status']);

It passes all "RESTful web services tests" Simpletests in my local environment.

This new patch fixes the same problem both for creation and update operations, calibrating the entity properties update (language, status, etc.) on the user entity_access permissions ...

Confirming that the patches in 84+ resolve issues with adding and updating entities via REST. My case was using 3 different types of custom entities, and provided that the permissions were implemented properly (I had to work through a veil of ignorance first!), this goes nicely. Not sure why the testbot keeps crapping out...

Anyhow - goods stuff @itamair !!

This patch fails testbot due to a problem with restws.test code in:
Fatal error: Call to a member function attributes() on a non-object in /var/www/html/sites/all/modules/restws/restws.test on line 280

Adding a modification to the user creation, and some additional test lines to attempt to diagnose.

Triggering testbot

Further testbot testing.

Re-enabling bypass to determine if it is indeed a permissions failure (the perms set here work on my own system).

Testing is failing due to the following message "Fatal error: Call to a member function attributes() on a non-object " (line 280 in patch #87). The error tells me that the simplexml_load_string() call is failing to produce a result.

279:     $xml_element = simplexml_load_string($result);
280:     $nid = $xml_element->attributes()->id;

My first thought was that this was a permissions issue but I added "bypass node create" back into the permissions in Patch #95, but it failed testing with the same error. (also tried to get it to throw a proper testbot error with assertTrue but didn't make a diff).

-      'access content', 'bypass node access', 'access resource node',
+      'edit any article content', 'create article content', 'access resource node', 'administer users','bypass node access'
...
     $xml_element = simplexml_load_string($result);
+    $this->assertTrue(is_object($xml_element), 'simplexml_load_string(' . print_r((array)$result,1) . ') returns valid object.');
     $nid = $xml_element->attributes()->id;

This makes me conclude that perhaps it is the XML insert itself is malformed in some way rather than the permission. One last test of permissions here by re-adding "access content" and then will explore tweaking the XML for insert.

Changing status to trigger test.

Patch #98 also failed, so it seems to me that this is NOT an issue with perms, but something else that is preventing the completion of the XML insert. Trying a simpler xml here (in case it is a case of malformed taxonomy data). If this does not resolve it, I will file a bug report on the restws.test.

Trying a modified test of smlx insert, asserting only that a 201 code is returned under the assumption that the problem is the result loading by simplexml_load_string().

Last patch certainly managed to get some fails ... re-testing.

At the risk of being completely spurious, it seems that the testing for CRUD without bypass has many fails. The simplexml error in previous versions seemed to mask the other errors - now 12 errors are reported all but one having to do with permissions (cache poisoning in auth sub-module also fails). The attached patch tries to resolve a single issue in testCRUD().

Testing CRUD part 2

Attempting to fix errors in method testResourceArray() by checking only for code 200 and 201 - this may not be a robust fix, but it seems that the technique that was used in many of these MAY BE inserting/updating successfully, but failing on node retrieval.

More tests.

Last test got close - xml update seemed to pass, but xml insert failed. REtesting with insert disabled.

Finally some progress. #118 managed to pass testResourceArray() by avoiding the XML update. I also suspect that the json insert was faulty,but that was not directly screened. XML update seemed to pass, but more rigorous testing (assertequal on something like a field or property) is needed.

This patch to the module works in practice (at least on one install for me) -- seems like the testing is in need of work.

Thank you #robertwb for this in deep review ;-)

Yeah @itaimar - sorry to trigger so many tests -- I am fairly ignorant of the testbot workings so it took a while. Your enhancements really make secure REST in D7 a reality - I can now verify proper function on 2 systems with fine grained control of access to content/entity types and controlled access to functions.

I will keep at it but try to be a bit more efficient now that I get the gist.

At some point, it might be help reviewers if someone can post a diff from #107 (where we had the CI error) to where we are now.

Agreed @lokapujya, but I would point out that the last patch to pass all tests was #58, and we have had CI errors since #75. Note also that I believe that the testbot changed between those two patches, so not sure if that impacts the test failures or not.

So, in short, I would resubmit #58 to see if it passes, then figure out what's up with the testing from there.

+    // The "create" operation requires an existing entity to check access.
+    // See https://www.drupal.org/node/1780646
+    if ($op == 'create' && empty($id)) {
+      return TRUE;
+    }

This needs tweaked I think. In our testing, $id wasn't empty, it was an empty value object. The following helped account for this use-case

if ($op == 'create' && (empty($id) || empty($this->wrapper($id)->value()))) {
  return TRUE;
}

patch from what was mentioned in 125

Also eager for resolution ... second pilot project begins in two weeks, depends on this fix as far as we can tell.

I'm trying to use this great module to automate content creation via my organization's delivery pipeline. I get 403 when POST /node unless the user's role has "bypass node access" permission. I'm trying to create a node of type swaggerdoc (custom type), so should only need the "create swaggerdoc content" permission.

Looking into the entity_access bug linked by klausi at #25, I tried a little patch which gave me some joy, the following change in restws.entity.inc:

public function access($op, $id) {
     $node = entity_create('node', array('type' => 'swaggerdoc'));
     return entity_access($op, $this->entityType, isset($id) ? $this->wrapper($id)->value() : $node);
  }

It's not perfect, but solved my immediate problem. Perhaps this will inspire the maintainers and contributors to fix this bug.

The patch above in #130 is not safe.

With this patch users with access to 'swaggerdoc' can create any type of node.
The patch only checks if the user has access to swaggerdoc, not if the node the user is trying to create is also of the type 'swaggerdoc'.

Is this issue still valid? Is it related to the recent security patches? I mean, it seems like a security bug to have "bypass permissions" anytime... https://www.drupal.org/sa-core-2019-003

it is not related. The recent core / contrib fix is related to sanitization of fields. This is a logic centric issue. If you have no problem giving bypass (say to a super admin / non-user web service account) then sure. If you need to bypass for normal users (and that causes problems given that normal users are not super users in your setup) then you shouldn't use this.

Thanks @btopro