-1

I just deployed a new web app, API, and DB to Azure. As a test, I had about six people use the app. It worked for five people, but one person got this CORS error:

SEC7120: [CORS] The origin 'https://mysite.azurewebsites.net' did not find 'https://mysite.azurewebsites.net' in the Access-Control-Allow-Origin response header for cross-origin resource at 'https://mysiteapi.azurewebsites.net/user'.

How is that possible? The architecture is like this:

Browser > Azure Web App > Azure API > Azure DB

The CORS issue is between the Azure Web App and the Azure API, right? So how could one person have this issue when nothing changes between the web app and the API for each user?

In my .NET Core 3.0 API, I have this

app.UseCors(options => options
  .WithOrigins("http://localhost:4200", "https://localhost:4200", "https://mysite.azurewebsites.net")
  .AllowAnyMethod()
  .WithHeaders("Authorization", "Content-Type"));

And my web app calls the API like this:

const headers_object = new HttpHeaders().set("Authorization", "Bearer " + jwt);
    this.http.get('user', { headers: headers_object, responseType: 'json' })
      .subscribe((data: any) => {
        this.userDto = data;            
      },
      error => {
        console.log('error: ', error);
      });

So how is that even possible for it to behave differently? And why would that happen?

Bob Horn
  • 33,387
  • 34
  • 113
  • 219
  • Among the possible causes: that user is receiving an error response — a 5xx or 4xx — in which case the response may not have the Access-Control-Allow-Origin response header at all; or for some reason that user isn’t receiving a response at all — maybe because they have a browser extension or anti-virus software that’s blocking it. To troubleshoot, consider having the user look at the Network tab in browser devtools (preferably in Firefox, because that’ll show more information than in Chrome) — to view the HTTP status code of the response, and the complete set of response headers. – sideshowbarker Jun 06 '20 at 00:35
  • Thanks. The response header does show `Access-Control-Allow-Origin` for the appropriate site. Plus, setting `UseCors` in Startup.cs should have the response header for everything, right? That's interesting about browser extensions or anti-virus. I can check that. – Bob Horn Jun 06 '20 at 01:14
  • Could this is related to [https://stackoverflow.com/a/49364050/5344880] ? From that link, we can infer that the way you define the URL to allow CORS also matters. Hence, accessing an URL ***with*** www perfix and ***without*** www prefix could lead to different behavior – Guru Pasupathy Jun 06 '20 at 02:20
  • That's a good thought, and I can see if that's an issue for me, but I don't think it is. I use mysite.azurewebsites.net everywhere. And I'm not sure how this would be an issue for one user. But thanks for the tip. – Bob Horn Jun 06 '20 at 13:38
  • So this is interesting... I had my son (who gets the CORS errors) try logging into Google OAuth on my machine (where it works for me), and he got the CORS errors. Again, on my machine, where it works for me. – Bob Horn Jun 07 '20 at 00:28
  • I got it. For some reason, my son didn't have the claim "family_name" from Google OAuth. And that was causing an exception, and for some reason a CORS error. – Bob Horn Jun 07 '20 at 01:01
  • 1
    You can post it as answer to help others who have same problem. – Joey Cai Jun 08 '20 at 05:43

1 Answers1

-1

For some reason, my son didn't have the claim "family_name" from Google OAuth. And that was causing an exception, and for some reason a CORS error.

Bob Horn
  • 33,387
  • 34
  • 113
  • 219