Early Bird Registration for DrupalCon Portland 2024 is open! Register by 23:59 PST on 31 March 2024, to get $100 off your ticket.
Problem/Motivation
The OPTIONS request do not have authentication requirements. The request is handled before ie access checks.
Proposed resolution
Make the required field visible as that's currently not done.
Make sure core does not add authentication to the OPTIONS method.
Use the core way.
Remaining tasks
- Needs discussion: core versus contrib solution?
- Needs UI design
- Blocked on #2817737: A REST resource's "auth" configuration MUST be non-empty, which prevents configuring it for anon access only
User interface changes
API changes
Original report by @-enzo-
In order to enable OPTIONS Request, it is necessary to enable the option to activate a method without authentication
Comment | File | Size | Author |
---|---|---|---|
#5 | Rest-UI-options.png | 19.47 KB | clemens.tolboom |
Comments
Comment #1
-enzo- CreditAttribution: -enzo- commentedComment #2
clemens.tolboom@-enzo- this depends on #2237231: Support OPTIONS request
Comment #3
clemens.tolboom(oeps)
Thanks for reporting :-)
Comment #4
clemens.tolboom@-enzo- is it useful to only use OPTIONS? After an OPTIONS request I suppose another request will be issued.
Core should allow for just an OPTIONS request and Rest UI should allow for it's config right?
Guess this helps a little : #2350847: Do not depends on HAL and basic_auth but it still has cookies.
Comment #5
clemens.tolboomComment #6
-enzo- CreditAttribution: -enzo- commentedHi @clemens.tolboom
For now is required for OPTIONS, but could useful for other devices, in the interface looks optional, but after try to submit is required at least one auth method.
Comment #7
clemens.tolboomSo we need at least mark the required fields as required and must remove those for the OPTIONS settings.
Comment #8
Wim LeersThis is effectively blocked on #2817737: A REST resource's "auth" configuration MUST be non-empty, which prevents configuring it for anon access only in core.
Comment #9
Wim LeersClosely related: #2817745: Add test coverage to prove that REST resource's "auth" configuration is also not allowing global authentication providers like "cookie" when not listed.
Comment #10
Wim LeersThe inability to do this is simply a bug IMO. It's blocked on #2817737: A REST resource's "auth" configuration MUST be non-empty, which prevents configuring it for anon access only, which is a core bug.
Comment #11
clemens.tolboomComment #12
clemens.tolboomReading https://developer.mozilla.org/en-US/docs/Web/HTTP/Access_control_CORS regarding OPTIONS requests
What has this to do with REST UI? Should we disallow OPTIONS requests through the UI? I guess I'm missing something so please enlighten me?
Comment #13
Wim LeersOh, lol, I totally misread this in #10. I read this as
But apparently this is about the
OPTIONS
request…Comment #14
Wim LeersComment #15
clemens.tolboomI hope @-enzo- can shed some light on the use cases. I still don't get it.
Comment #16
taggartj CreditAttribution: taggartj commentedHere is a Use case I don't like doing some thing like this...
when making a resource like....
that don't realy require any sort of authentication.
However I can see the point that these bespoke endpoints could be just made in controllers but in that case not that shareable.
then make a route subscriber with ...
Ps. Had a beer with @-enzo- once that guy knows what he's doing :)
Comment #17
Wim LeersThat's a special case, and it already is supported in Drupal core (it was added in #2847708: RPC endpoint to reset user password). So it looks like you can actually remove that custom code :)
Comment #18
Wim LeersSomebody asked again about this WTF in #2949327-6: Help with REST authentication.3.
Comment #19
clemens.tolboomAs #2237231: Support OPTIONS request is resolved we have a new parent issue core #2817737: A REST resource's "auth" configuration MUST be non-empty, which prevents configuring it for anon access only