search

tuupola / cors-middleware

PSR-7 and PSR-15 CORS middleware
MIT License
132 stars 16 forks source link

Cors middleware only being called on GET - not POST? #5

Closed ghost closed 7 years ago

ghost commented 7 years ago

Hi Mika,

Thanks for all the tireless work you put into these repos, I'm currently using your CORS-Middleware and planning to use the JWT or BRANCA on in due course.

I have a really annoying issue which I'm sure is an easy fix but I can't find it, using Slim 3.8.1 with Cors-Middleware 0.5.2 I am getting CORS errors on the POST but not GET calls. I'm trying to develop the UI with Ionic (via Ionic Creator) so using AngularJS. Using inspect I can see the headers being set on the GET as below, GET doesnt appear to issue an OPTIONS call, not sure if that's correct or not:

Access-Control-Allow-Credentials:true
Access-Control-Allow-Origin:https://creator.ionic.io
Cache-Control:no-store, no-cache, must-revalidate
Content-Length:73519
Content-Type:application/json,text/html; charset=UTF-8
Date:Fri, 15 Sep 2017 20:16:29 GMT
Expires:Thu, 19 Nov 1981 08:52:00 GMT
Pragma:no-cache
Server:Microsoft-IIS/8.0
Vary:Origin
X-Powered-By:ASP.NET
X-Powered-By:PHP/7.0.21

But using POST I can see them being set as below on the OPTIONS call:

Allow:OPTIONS, TRACE, GET, HEAD, POST
Content-Length:0
Date:Fri, 15 Sep 2017 20:16:30 GMT
Public:OPTIONS, TRACE, GET, HEAD, POST
Server:Microsoft-IIS/8.0
Set-Cookie:ARRAffinity=a544f2c7a222ce45b9597862ebbf6fc1d1b2ee338f4bf5d2d1aeb2c33eb0086d;Path=/;HttpOnly;Domain=<my_domain>.azurewebsites.net
X-Powered-By:ASP.NET

I've implemented the middleware as below, I've added a few permitted origins including evil.com due to using browser extension for debugging, I get the issues when that is switched off:

$app->add(new \Tuupola\Middleware\Cors([
  "origin" => ["https://creator.ionic.io", "http://evil.com", "http://<my_domain>.azurewebsites.net", "https://<my_domain>.azurewebsites.net"],
  "methods" => ["GET", "POST", "PUT", "PATCH", "DELETE", "OPTIONS"],
  "headers.allow" => ["Content-Type", "Authorization", "Accept", "Origin"],
  "headers.expose" => [],
  "credentials" => true,
  "cache" => 0,
]));

Have I missed something that is obvious in how to make it fire the middleware on the OPTIONS or preflight request?

Thanks for any help you can offer, I've been using SLIM for a while but not much on middleware yet, also first time I've hit CORS pain. My plan for production is to deploy API to one server, UI to another for use on mobile browsers and then a mobile app that will go straight to the middleware.

Any thoughts most welcome! Thanks

ghost commented 7 years ago

Finally got to the bottom of this one, it had nothing to do with the middleware, I had done two stupid things, noted below along with the steps to find them in case it helps anyone afterwards:

  1. Added a typo to a variable name on the way past so headers were empty - no real hints for help with finding fat fingers

  2. I did find that by setting the line below in my app.config (temporarily for debug) I could clear all custom headers and get simple POST request so no OPTIONS preflight call, I then just had to debug the request to identify which custom headers I needed to add to the list for the headers.allow array on the middleware. For me it turned out to be as below, will vary depending on your API and client requirements though:

"headers.allow" => ["Content-Type", "Authorization", "Accept", "Origin", "Headers", "Method"],