Support for Drupal 7 is ending on 5 January 2025—it’s time to migrate to Drupal 10! Learn about the many benefits of Drupal 10 and find migration tools in our resource center.
Would it be appropriate to add JSONP support to this module?
Comment | File | Size | Author |
---|---|---|---|
#18 | restws-support_options_request-1084144-11-18.patch | 5.49 KB | m.stenta |
#11 | restws-support_options_request-1084144-11-7.patch | 1.51 KB | marcus_w |
#6 | restws-support_options_request-1084144-6-7.patch | 1.1 KB | marcus_w |
Comments
Comment #1
klausiShould not be too hard, would just require a JSONP format controller class that bases on the JSON format and adds the function call wrapping. Patches welcome.
Comment #2
scor CreditAttribution: scor commentedI'd recommend CORS instead, it's easier to add: just one line of code to output an additional header without having to change the JSON output. Most modern browsers understand it (see site above). There is an example in the JSON-LD module.
Comment #3
chandimac CreditAttribution: chandimac commentedCORS can be enabled by adding the
Header set Access-Control-Allow-Origin "*"
in the .htaccess file
Comment #4
chandimac CreditAttribution: chandimac commentedFor the benefit of folks trying to get cross-browser POST calls working with $.ajax clients:
CORS Header params in .htaccess file
Javascript to create a new article entity. User needs to have 'bypass node access' perm set.
Comment #5
justafishI just whipped this up for anyone who wants to configure this within drupal http://drupal.org/project/cors
Comment #6
marcus_w CreditAttribution: marcus_w as a volunteer commentedWhen using the cors module #5 mentions, the GET /restws/session/token doesn't work for modern browsers. In a cross domain request an OPTIONS request will be fired first. (see https://developer.mozilla.org/en-US/docs/Web/HTTP/Access_control_CORS#Ov...).
As the restws module returns a 403 on the url, the actual GET request is never fired.
I've created a patch which checks for the request method first, then either returns the normal behavior on GET, and a 200 on OPTIONS. You'd still need to use the cors module to set the actual headers. But I think normal CORS functionality is possible with this patch.
Comment #10
marcus_w CreditAttribution: marcus_w as a volunteer commentedI don't know why the test fails, seems to be something wrong with the tests itself, as there are many errors and they don't use the OPTIONS stuff.
Comment #11
marcus_w CreditAttribution: marcus_w as a volunteer commentedAdded support for OPTIONS request on the Entities as well (simply returns)
Comment #12
Cosy CreditAttribution: Cosy commentedJust about to try this out..
Got stuck for 6 hours wondering what the hell chrome was doing sending this "OPTIONS" request !
Comment #13
Cosy CreditAttribution: Cosy commentedWhilst I'm now getting past the OPTIONS scenario with a 200 -
Im still getting a 403 POSTing to rest/session/token
Has anyone got any clear advice on how to login & grab the token via http in a headless scenario using Basic auth?
Comment #14
Cosy CreditAttribution: Cosy commentedJust a thought, but as documented before, marcus_w patch deals with the OPTIONS object being sent..
In my network tab I can see 2 requests being fired,
1) With the options object:
Response is a 202:
AND THEN A FURTHER POST REQUEST:
which returns the 403
Cache-Control: no-cache, must-revalidate, post-check=0, pre-check=0
etcetc
Is it possible that the OPTIONS request is fired, a token generated & some sort of session; (returns)
then the POST request is fired, but the token is regenerated & the session no longer valid at this point. ?
(Baring in mind i dont fully understand the mechanisms, that implement restws. )
Comment #15
m.stentaGreat patch @marcus_w! It helped to solve CORS preflight issues for us when creating new entities via
POST
requests.However, we are having the same problem with updating existing entities via
PUT
requests. This is a little trickier to solve, because of the way therestws
module alters menu items for entities.We're creating/updating Log entities, which is an entity type provided by this module: https://drupal.org/project/log - but as far as I can tell this issue would also affect nodes and other core types.
In the case of creating new entities, we send a
POST
request to/log
. But when updating existing entities, we send aPUT
request to/log/%
. When these requests are sent via Javascript in browsers (testing in Firefox and Chrome), a preflightOPTIONS
request is sent to those endpoints before the actualPOST
orPUT
. This preflight request does NOT contain the Drupal session cookie, so it is essentially an anonymous request.The
restws
module'shook_menu_alter()
adds a new menu router item for/log
, withaccess callback
set toTRUE
. So when aPOST
request is sent to/log
it passes the access check (because it always passes) and goes directly to the page callback (restws_page_callback
). With the patch from #11 above for detecting that it's anOPTIONS
request, this works to respond to the preflight request, so thePOST
request works as expected.However, in the case of a
PUT
request sent to/log/%
, the preflightOPTIONS
request doesn't have a cookie, so the normal entity access callback (log_access
in this case) denies access.I think the only way we could solve this in the
restws
module would be to ALSO alter theaccess callback
of entity menu items so that it can be checked to see if its anOPTIONS
request, and return a 200 response code.This would be somewhat similar to the new function added in the patch from #11,
restws_user_is_logged_in_or_options()
which returnsTRUE
when a user is logged in OR if the request method isOPTIONS
.In this case, though, we would want to return
TRUE
if the request method isOPTIONS
OR delegate to the access callback defined in the original menu item (along with any additional arguments that requires).Comment #16
m.stentaAttached is a patch that adds a new
restws_access_callback()
, which is used to override access callbacks of certain menu items, in the same way that therestws
module is already overriding page callbacks.The access callback simply checks to see if it's an
OPTIONS
request, and grants access if that's the case. Otherwise, it delegates to the original access callback.Comment #17
m.stentaThe patch in #16 is broken, sorry... changing this back to Needs Work.
Comment #18
m.stentaHere is the patch, fixed.
In this version, I also took it one step further and removed
restws_user_is_logged_in_or_options()
in favor of the newrestws_access_callback()
function.I also made a minor change to the way
user_is_logged_in()
is used withinrestws_session_token()
, to ensure that it returns consistent responses even if the user is not logged in (empty response).This is working for me right now - I'm able to do both
POST
andPUT
requests.Ready for review!