CODEWITHSUNDEEP
azurecorsazure-web-app-service
Nam Ngo
Nam Ngo

Reputation: 263

Azure website Rest Api only accept GET, POST returns 403. Possibly CORS

I am encounter a strange problem. I have a Asp.net Core WebApi project running under Azure App Service (Website). I am using DHC plug-in in Chrome. My service is also running with AAD.

I can request a GET method just fine (After login). However, when I request any POST, I got a 403 response. Looking around in the log, I can see this

2016-07-28T08:14:26 PID[x] Verbose Received request: POST https://blahblah.azurewebsites.net/api/build/beep/

2016-07-28T08:14:26 PID[x] Verbose Found 'AppServiceAuthSession' cookie for site 'blah.azurewebsites.net'. Length: 856.

2016-07-28T08:14:26 PID[x] Information Sending response: 403.60 Forbidden

2016-07-28T08:14:26 PID[x] Warning Cross-site request forgery detected for user '[email protected]' from referer ''!

I am using Asp.net Core 1.0. I have CORS enable in my code (AllOrigin AllHeader), as well as the CORS in Azure website has an entry for '*', which supposed to accept every origin. The log stream seems like it does not even hit my website, but something in Azure blocks the request.

Any help?

Edit: A successful GET method

2016-07-28T20:24:35 PID[22880] Verbose Received request: GET https://blah.azurewebsites.net/api/build/beep/

2016-07-28T20:24:35 PID[22880] Verbose Found 'AppServiceAuthSession' cookie for site 'blah.azurewebsites.net'. Length: 876.

2016-07-28T20:24:36 PID[22880] Verbose Authenticated [email protected] successfully using 'Session Cookie' authentication.

Upvotes: 4

Views: 2376

Answers (2)

user10224879
user10224879

Reputation: 1

In my case I had to remove:

Origin: https://....

changing User-Agent didn't work

Upvotes: 0

Chris Gillum
Chris Gillum

Reputation: 15042

Looks like your JavaScript client is being blocked by the Authentication / Authorization module's CSRF protection, which currently doesn't know about the CORS configuration (it probably should - I'll look into this).

The simplest way to work around this is to add a custom User-Agent HTTP header in your client settings. One of the things our built-in CSRF protection looks for is whether the client is a browser. Pretty much all major browsers use "Mozilla/..." as the user-agent string. Change this to something else to make it clear that you're not a browser and your POST request will go through successfully.

Upvotes: 5

Related Questions