[CORS] Access-Control-Allow-Origin header missing

[shprink]

From a JS client I get the following message on oauth1/request:

No 'Access-Control-Allow-Origin' header is present on the requested resource. Origin 'http://localhost:8080' is therefore not allowed access. The response had HTTP status code 400.

You might want to copy this function from the WP-API:

function rest_send_cors_headers( $value ) {
    $origin = get_http_origin();

    if ( $origin ) {
        header( 'Access-Control-Allow-Origin: ' . esc_url_raw( $origin ) );
        header( 'Access-Control-Allow-Methods: POST, GET, OPTIONS, PUT, DELETE' );
        header( 'Access-Control-Allow-Credentials: true' );
    }

    return $value;
}

[romuloctba]

https://gist.github.com/Shelob9/87f9474df0f541e07383

2015-09-05 2:09 GMT-03:00 Julien Renaux notifications@github.com:

From a JS client I get the following message:

No 'Access-Control-Allow-Origin' header is present on the requested
resource. Origin 'http://localhost:8080' is therefore not allowed access.
The response had HTTP status code 400.

You might want to copy this function from the WP-API:

function rest_send_cors_headers( $value ) {
$origin = get_http_origin();

if ( $origin ) {
    header( 'Access-Control-Allow-Origin: ' . esc_url_raw( $origin ) );
    header( 'Access-Control-Allow-Methods: POST, GET, OPTIONS, PUT, DELETE' );
    header( 'Access-Control-Allow-Credentials: true' );
}

return $value;

}

—
Reply to this email directly or view it on GitHub
#83.

[shprink]

@romuloctba Don't you want to create a PR so everybody can benefit from this changes (if it works).

[romuloctba]

Well, my friend, those are not changes, they are 3 diff hooks that will provide a header with the required Access-controll-allow-origin and etc for you. You should put in your functions.php or (better) wrap it into a plugin.

Btw is not my code also. You could install wp-api cors available @ WordPress plugin directory, but you should not use it in production, since it allows all with *.

I don't think the oAuth plugin should have anything related to CORS, since it should be used with wp-api, that should.

Well, this is untested thou, so I can only hope it helps you with your problem.

[itsananderson]

That Gist doesn't work for Oauth1 because the "rest_pre_serve_request" action doesn't get triggered for Oauth1 requests (since it's not technically a WP-API route).

I wrote a plugin that tackles the CORS issues with Oauth, by plugging into template_redirect, but it's a little hacky. https://github.com/itsananderson/wp-api-cors/blob/09d0e5e13343b492fb0ab060b59bde836505220d/wp-api-cors.php#L25

The other issue you run into after fixing the CORS issues is that the Oauth1 plugin uses wp_http_validate_url to validate the callback URL, which prevents localhost apps from authenticating using Oauth1.

[coderkevin]

If you're thinking of using CORS to send your Client ID and Client Secret to your WP site, I suggest you reconsider and use a server call or a server proxy. Holding a Client Secret securely in client-side code is impossible. For a longer explanation, look here: http://alexbilbie.com/2014/11/oauth-and-javascript/

[rmccue]

Per @coderkevin's note, you're not meant to access these directly via the client side, which is why they don't have the CORS headers.

[larssn]

That depends on the auth flow you've built. In my case, only the first few steps (until the WP login step) is handled in the JS client. After that the rest of the flow is effectively handed off to a server (cloud), which then handles the remaining steps behind the scenes. This server then securely communicates with the resource and exchanges data, and the client doesn't need access to the OAuth1 tokens, keys etc, but can still benefit from the data exchange.

The client thus only needs the key and secret for a short time.

However this is currently not possible due to the reasons mentioned above.