• Resolved PedeLa

    (@pedela)


    Hello,

    we are trying to use this plugin as a lightweight alternative for some heavyweight OpenId Connect server solution. So far, this only works partially, since we ran into problems regarding CORS preflight requests, which are send by the browser automatically.

    To be precise, our problem lies with requesting the user info via a GET request to “/oauth/me”. We provide the authorization header according to specification and all is fine if we send this request directly (manually). But if we use it in our scripts, because of the cross origin, the browser first automatically sends an OPTIONS request to this resource, not containing the authentication itself (which cannot be modified I guess). The plugin then sends back a 400-error. My search for answers to this problems revealed that the solutions for people having the same problems were found on server side, where the server was told to behave differently to OPTIONS requests.

    My question is: Did we oversee something? Is there a solution we have not thought about?

    We would appreciate any answer we can get on this topic and thank you in advance!

    https://ww.wp.xz.cn/plugins/oauth2-provider/

Viewing 8 replies - 1 through 8 (of 8 total)
  • Plugin Author Justin Greer

    (@justingreerbbi)

    Hi @pedela,

    Here is what I would recommend trying out. On your client server, you can make a request to your server which then would do server to server calls to get the information you are looking for.

    Another solution would be to use JSON-P and send the header authorization in the body request instead of in the header. This would allow you to make one request with JSON-P and receive the data you are looking for. CORS and great and all but the main thing it does is provides legacy support to browsers that should have been dead years ago.

    Hope I shed some light on the issue. Please let me know if you have any more questions. I am here to help!

    Thread Starter PedeLa

    (@pedela)

    Hello Justin Greer,

    thank you for your quick reply.

    Does this mean that there exists no possibility for the plugin to handle OPTIONS requests? Because switching to another technology is not an option due to the already existing software that uses our current OIDC server. And to be honest, it never occurred to me that CORS is an outdated technology.

    If I understand you correctly this would leave us with implementing an intermediate request receiver at WP server side that basically “sorts out” (and “fake answers”) the preflight requests?

    I’m not entirely sure that this is our way to go, it does not seem a very clean solution. But anyways. thank you again for your help, you brought some light on the issue!

    Plugin Author Justin Greer

    (@justingreerbbi)

    I would not say CORS is outdated. Currently WP OAuth Server does not support OPTIONS as a request that I am aware of. I will ask the other developers just to be sure.

    As a personal recommendation, I would not use client facing software to make a secure call anyways If you have the ability to make the call from client server to provider server.

    Hi Justin,

    I’m running into this same problem when issuing a POST request to get a token. The token request call is working from Postman, but when sending the request from an angular/ionic client, the browser is sending the OPTIONS request first, which the plugin returns a 405. So, without CORS support from the plugin to respond correctly to an OPTIONS request, we cannot use this for authenticating our wp rest api calls. Any advise is greatly appreciated.
    Thanks,
    Lynne

    Plugin Author Justin Greer

    (@justingreerbbi)

    Hi @lynne424

    Currently CORS is not support in the OAuth2 draft thus we will not add it to the core of our plugin. However this does not mean that you can not add your own extension to WP OAuth Server.

    There is an action called wo_before_api which passes the _REQUEST. You can add an action using this and intercept the request and send back the “OK” message to the client.

    The lack of CORS support is to prevent click highjacking which is a very real danger but plays hell on things like node.js and other frameworks. If you bypass to much of the OAuth2 process one might as well write there own connector and auth flow.

    Hope this helps.

    Plugin Author Justin Greer

    (@justingreerbbi)

    The process would look something like the following:

    function wo_cors_check_and_response(){
    if ($_SERVER['REQUEST_METHOD'] == "OPTIONS") {
        header('Access-Control-Allow-Origin: *');
        header('Access-Control-Allow-Methods: POST, GET');
        header('Access-Control-Allow-Headers: Authorization');
        header('Access-Control-Max-Age: 1');  //1728000
        header("Content-Length: 0");
        header("Content-Type: text/plain charset=UTF-8");
        exit(0);
      }
    }
    add_action('wo_before_api', 'wo_cors_check_and_response');

    Thanks for the quick response Justin. Your suggestion (with some modifications/tweaks for my particular app) is working.

    Plugin Author Justin Greer

    (@justingreerbbi)

    Great, that is awesome news!

Viewing 8 replies - 1 through 8 (of 8 total)

The topic ‘CORS – Preflight Request Problems’ is closed to new replies.