I'm sure there is a reason for this, but if you submit any options request with OAuth authorisation parameters in the query string a 401 response is set. I've found a couple of places in the plugin where this seems to be enforced, e.g.
This has created an issue for me in my current project where I am communicating with the REST API, authenticated with OAuth1 from an Angular.JS app.
It appears that the default behaviour when making certain calls, e.g. DELETE, either in angular or the browser, I haven't figured out which, is to send a pre-flight OPTIONS request to the same URL as request in the DELETE request.
Since the DELETE request is sent with the OAuth parameters in a query string, the OPTIONS request is sent with those as well and when the 401 is received, the DELETE request is not made.
I am currently working around this by removing the oauth init functions when an OPTIONS request is sent. I feel I may be creating a security issue here - but I don't see why the OPTIONS request isn't valid, given that I can make the very same request with no authorisation whatsoever and the request is successful.
Could we look to add a rule where an OPTIONS request automatically bypasses the OAuth plugin and just lets the default REST API code pick up the request?
I'm sure there is a reason for this, but if you submit any options request with OAuth authorisation parameters in the query string a 401 response is set. I've found a couple of places in the plugin where this seems to be enforced, e.g.
oauth-server.php lines 114-116 lib/class-wp-rest-oauth1.php lines lines 652-656
This has created an issue for me in my current project where I am communicating with the REST API, authenticated with OAuth1 from an Angular.JS app.
It appears that the default behaviour when making certain calls, e.g. DELETE, either in angular or the browser, I haven't figured out which, is to send a pre-flight OPTIONS request to the same URL as request in the DELETE request.
Since the DELETE request is sent with the OAuth parameters in a query string, the OPTIONS request is sent with those as well and when the 401 is received, the DELETE request is not made.
I am currently working around this by removing the oauth init functions when an OPTIONS request is sent. I feel I may be creating a security issue here - but I don't see why the OPTIONS request isn't valid, given that I can make the very same request with no authorisation whatsoever and the request is successful.
Could we look to add a rule where an OPTIONS request automatically bypasses the OAuth plugin and just lets the default REST API code pick up the request?