The 2026 Drupal Business Survey is open. Your response will help shape the future of the Drupal business ecosystem.I'm trying to make a POST request to create a node via ajax on the same domain as the Drupal site (no cross-domain action here). In following the example here, the response is always a 403.
The "Content" resource is enabled for POST requests with basic_auth & cookie authentication, and hal_json & json formats.
When trying to make the request via POSTMAN, putting in admin username and password hash into header as basic auth, it creates the node. So I don't think it is related to the actual creating of the node.
The account I am testing on for the ajax request is the same admin account, so this shouldn't be a permissions issue either.
I checked in CsrfRequestHeaderAccessCheck::access(), and it actually does return AccessResult::allowed()->setCacheMaxAge(0), so it is not failing at the CSRF token check. It appears to be failing somewhere else after that, with, \Symfony\Component\HttpKernel\Exception\AccessDeniedHttpException
Here is the code:
$('#create-node-submit').click(function(e) {
e.preventDefault();
var newNode = {
_links: {
type: {
href: '/rest/type/node/article'
}
},
type: {
target_id: 'article'
},
title: {
value: 'This is a test Article from REST'
},
field_description: {
value: 'Here is some test description.'
}
};
getCsrfToken(function (csrfToken) {
postNode(csrfToken, newNode);
});
return false;
});
function getCsrfToken(callback) {
$.get(Drupal.url('rest/session/token'))
.done(function (data) {
var csrfToken = data;
callback(csrfToken);
});
}
function postNode(csrfToken, node) {
$.ajax({
url: '/entity/node?_format=hal_json',
method: 'POST',
headers: {
'Content-Type': 'application/hal+json',
'X-CSRF-Token': csrfToken
},
data: JSON.stringify(node),
success: function (node) {
console.log(node);
},
error: function (XMLHttpRequest, textStatus, errorThrown) {
console.log("Status: " + textStatus);
console.log("Error: " + errorThrown);
}
});
}The messages are not helpful:
Status: error
Error: Forbidden
| Comment | File | Size | Author |
|---|---|---|---|
| #4 | Screenshot 2016-11-29 10.37.24.png | 15.95 KB | cruno |
| #4 | Screenshot 2016-11-29 10.37.16.png | 28.03 KB | cruno |
| #4 | Screenshot 2016-11-29 10.37.04.png | 6.3 KB | cruno |
| #4 | Screenshot 2016-11-29 10.36.55.png | 133.69 KB | cruno |
Comments
Comment #2
cruno commentedComment #3
wim leersYes, we're aware of the extremely frustrating error responses. We have #2808233: REST 403 responses don't tell the user *why* access is not granted: requires deep Drupal understanding to figure out to fix that.
But, I want to help you in the mean time. Can you post the full response that the server is sending? (
jQuery.ajax()does crappy things in case of error responses, which makes this even harder to understand.)Comment #4
cruno commentedWim Leers: I'm including screenshots of the response and request headers/data being sent and received.
Comment #5
cruno commentedAccidentally re-set the ticket category.
Comment #6
wim leersPlease export your
rest.resource.entity.nodeREST Resource config entity and post it here.Comment #7
cruno commentedIt's the default rest.resource.entity.node.yml file in the core rest module.
From the db:
Comment #8
wim leersThat also looks fine.
Last question: does this user have the appropriate
create <TYPE> content?Comment #9
cruno commentedYes, the user is the admin.
Comment #10
wim leersDamn :(
Then I'm afraid the only answer I can give you is this one:
\Drupal\rest\Plugin\rest\resource\EntityResource::post()… so you can figure out the root cause
Very sorry. Until #2808233: REST 403 responses don't tell the user *why* access is not granted: requires deep Drupal understanding to figure out is done, this is the only solution.
Comment #11
wim leersOh there's one more thing I can check. Can you export your
rest.settingsand paste it here?Comment #12
cruno commentedThanks for your help. I'll try xdebug again.
rest.settings.yml:
Comment #13
wim leersSo #12 counters my last suspicion: that you had the BC layer for entity permissions enabled, which would've required an extra permission to be granted. (#2664780: Remove REST's resource- and verb-specific permissions for EntityResource, but provide BC and document why it's necessary for other resources)
Which means using xdebug to find the root cause is the only solution for now, I'm afraid :( Sorry! We're working hard to make this better!
Comment #14
cruno commentedThe issue turned out to be that Rest UI would not set the authentication in the configuration properly. supported_auth can be set, but authentication cannot.
In rest.resource.entity.node.yml:
Before:
After:
So as it turns out the issue was with Rest UI module, not core Rest module.
Comment #15
gvsoIn case someone else faces this problem, there is an issue about this on REST UI issue queue #2831716: REST UI does not support "resource" granularity