Right now, any OPTIONS request to the oauth2/token endpoint is denied thus preventing CORS standard requests to operate.
We should allow this HTTP method and just return headers with no data. Code that set the right CORS headers is then out of scope (for example with the CORS module : https://www.drupal.org/project/cors)

Comments

garphy’s picture

Status: Active » Needs review
StatusFileSize
new627 bytes

Here's a patch that allow OPTIONS requests in the same way Services API does with RESTServer.

garphy’s picture

StatusFileSize
new1.01 KB

Actually, oauth2/UserInfo should allow OPTIONS too...

dashohoxha’s picture

I have solved this problem by intercepting and handling the CORS requests before they go to oauth2_server (or anything else):

/**
 * Implements hook_boot().
 */
function MYMODULE_boot() {
  if ($_SERVER['REQUEST_METHOD'] == "OPTIONS") {
    //header('Access-Control-Allow-Origin: ' . $_SERVER['HTTP_ORIGIN']);
    header('Access-Control-Allow-Origin: *');
    header('Access-Control-Allow-Methods: POST, GET');
    header('Access-Control-Allow-Headers: Authorization');
    header('Access-Control-Max-Age: 1728000');
    header("Content-Length: 0");
    header("Content-Type: text/plain");
    exit(0);
  }
}

But maybe this is not the most standard or flexible approach.

StoraH’s picture

Updated patch to work with latest dev.

pjcdawkins’s picture

+++ b/oauth2_server.pages.inc
@@ -148,6 +148,11 @@ function oauth2_server_authorize_form_submit($form, &$form_state) {
+  // For any OPTIONS request return only the headers.
+  if ($_SERVER['REQUEST_METHOD'] == 'OPTIONS') {
+    exit;
+  }

This probably should be drupal_exit()

pjcdawkins’s picture

pjcdawkins’s picture

Adds the same logic to more page callbacks

pjcdawkins’s picture

My only doubt on this is... could it be the responsibility of code that sets CORS headers for OPTIONS requests to exit() afterwards?