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

Support from Acquia helps fund testing for Drupal Acquia logo

Comments

-enzo-’s picture

Issue summary: View changes
clemens.tolboom’s picture

clemens.tolboom’s picture

(oeps)

Thanks for reporting :-)

clemens.tolboom’s picture

Issue summary: View changes
Related issues: +#2350847: Do not depends on HAL and basic_auth
FileSize
0 bytes

@-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?

Only local images are allowed.

Guess this helps a little : #2350847: Do not depends on HAL and basic_auth but it still has cookies.

clemens.tolboom’s picture

FileSize
19.47 KB

-enzo-’s picture

Hi @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.

clemens.tolboom’s picture

Issue summary: View changes

So we need at least mark the required fields as required and must remove those for the OPTIONS settings.

Wim Leers’s picture

Title: Add option to enable method without Authentication » [PP-1] Add option to allow access to resource (or a particular method on a resource) without authentication (i.e. as anon)
Category: Feature request » Bug report
Status: Active » Postponed

The 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.

clemens.tolboom’s picture

Issue summary: View changes
clemens.tolboom’s picture

Reading https://developer.mozilla.org/en-US/docs/Web/HTTP/Access_control_CORS regarding OPTIONS requests

The specification mandates that browsers "preflight" the request, soliciting supported methods from the server with an HTTP OPTIONS request method, and then, upon "approval" from the server, sending the actual request with the actual HTTP request method.

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?

Wim Leers’s picture

Title: [PP-1] Add option to allow access to resource (or a particular method on a resource) without authentication (i.e. as anon) » Add option to allow access to resource (or a particular method on a resource) without authentication (i.e. as anon)
Related issues: -#2817737: A REST resource's "auth" configuration MUST be non-empty, which prevents configuring it for anon access only, -#2817745: Add test coverage to prove that REST resource's "auth" configuration is also not allowing global authentication providers like "cookie" when not listed

Oh, lol, I totally misread this in #10. I read this as

the option to have a anonymous checkbox, next to Basic Auth, Cookie, and so on

But apparently this is about the OPTIONS request…

Wim Leers’s picture

Status: Postponed » Active
clemens.tolboom’s picture

Issue summary: View changes
Status: Active » Postponed (maintainer needs more info)

I hope @-enzo- can shed some light on the use cases. I still don't get it.

taggartj’s picture

Here is a Use case I don't like doing some thing like this...

/**
 * Implements hook_form_alter().
 */
function rest_password_form_alter(&$form, FormStateInterface $form_state, $form_id) {
  if ($form_id === 'restui' && !empty($form['resource_id']['#value']) && $form['resource_id']['#value'] === 'lost_password_resource') {
// DIE OPTIONS DIE.    
unset($form['wrapper']['settings']['authentication']['#options']);
    $form['wrapper']['settings']['authentication']['#options'] = ['Na' => 'Not Needed But tick this or Rest ui Will Cry.'];
    $form['Extra'] = [
    // Dear god i wish all rest points were documented in a Postman collection.
      '#markup' => '<h2>How to Use:</h2> <p>Post "mail" to endpoint.</p>',
    ];
  }

when making a resource like....

/**
 * Provides a resource to Email new password to user, cause i cant find out how core does it.
 *
 * @RestResource(
 *   id = "lost_password_resource",
 *   label = @Translation("Lost password"),
 *   uri_paths = {
 *     "canonical" = "/user/lost-password",
 *     "https://www.drupal.org/link-relations/create" = "/user/lost-password"  
 *   }
 * )
 */

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 ...

protected function alterRoutes(RouteCollection $collection) {
    if ($route = $collection->get('rest.lost_password_resource.POST')) {
      $requirements = $route->getRequirements();
      if (!empty($requirements['_csrf_request_header_token'])) {
       // Oh no you didn't csrf. 
        unset($requirements['_csrf_request_header_token']);
        unset($requirements['_permission']);
        $options = $route->getOptions();
        unset($options['_auth']);
        $route->setOptions($options);
        $route->setRequirements($requirements);
      }
    }
  }

Ps. Had a beer with @-enzo- once that guy knows what he's doing :)

Wim Leers’s picture

That'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 :)

Wim Leers’s picture

Somebody asked again about this WTF in #2949327-6: Help with REST authentication.3.