Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

CORS help #161

Closed
scottycroy opened this issue Jan 11, 2024 · 15 comments
Closed

CORS help #161

scottycroy opened this issue Jan 11, 2024 · 15 comments
Assignees
Labels
Bug Something isn't working

Comments

@scottycroy
Copy link

Describe the issue
Cloned and built the projects. Tested locally, everything works as expected.
Uploaded the Backend to a development server running Windows Server 2022 with IIS 10 .
Modified the Backend Url in appsettings.json

Run Frontend from my dev workstation (https://localhost:7171)
I am able to register a user, when I try to register a second time, it tell me the username is already taken. This indicates it is working as should.

When I try to login, I get a CORS error:

Access to fetch at 'https://mydevserverurl.com/manage/info' from origin 'https://localhost:7171' has been blocked by CORS policy: No 'Access-Control-Allow-Origin' header is present on the requested resource. If an opaque response serves your needs, set the request's mode to 'no-cors' to fetch the resource with CORS disabled.

I also get this error when the login page is accessed.

The only changes to the code that was made was on each appsettings.json files to change the BackEnd server url to https://mydevserverurl.com

Any help would be appreciated.
I am thinking that it has something to do with my running the front end on localhost and accessing the API from there.
If this is the case, how would one develop the front end and have the API deployed?


Issue Details

Do not edit this section. It is required for issue processing.

@scottycroy scottycroy added the Not triaged Awaiting review label Jan 11, 2024
@guardrex
Copy link
Collaborator

running the front end on localhost and accessing the API from there

I thought we had this covered. The CORS config is set up to use the app settings frontend address ...

https://github.com/dotnet/blazor-samples/blob/main/8.0/BlazorWebAssemblyStandaloneWithIdentity/Backend/Program.cs#L23-L31

(but I think only the frontend address should be there ... I'll take a look at that later ... I'm buried in work 😩 at the moment 😅)

... and on Line 54 ...

app.UseCors("wasm");

Are you sure the app is running locally at https://localhost:7171?

@scottycroy
Copy link
Author

Are you sure the app is running locally at https://localhost:7171?

Yes, I ran dotnet publish on the backend and uploaded to the server.
Then ran the WASM app with dotet run -lp https.
The Blazor WASM is running on https://localhost:7171

Using only the frontend address in the CORS config produces the same result.

// add CORS policy for Wasm client
builder.Services.AddCors(
options => options.AddPolicy(
"wasm",
policy => policy.WithOrigins([builder.Configuration["FrontendUrl"] ?? "https://localhost:5002"])
.AllowAnyMethod()
.SetIsOriginAllowed(pol => true)
.AllowAnyHeader()
.AllowCredentials()));

I feel like such a newb right now 🥇

@guardrex
Copy link
Collaborator

It should work. I'm not sure what the problem is. I probably need to reproduce it here, and we might need to open a product unit issue. It does kind'a sound like one of those simple little things ... a slight misconfiguration (or misunderstanding) 😈 ... and 💥😢.

I'll ping @JeremyLikness on it, but he's been very busy, too, AFAIK. I'm not sure if or when he'll respond here.

@guardrex
Copy link
Collaborator

I'll have to get back to you later tho ... Friday ... Tuesday ... when I can get free. I'm completely buried at the moment. 😩

@JeremyLikness
Copy link
Member

I'm looking at this now. I suspect on the WASM client we'll need to add Access-Control-Request-Headers with a value of content-type to the outgoing request, but I haven't set it up to test yet.

@guardrex guardrex added Bug Something isn't working and removed Not triaged Awaiting review labels Jan 12, 2024
@scottycroy
Copy link
Author

I have attempted that, but it gives the same result.

@scottycroy
Copy link
Author

What I am attempting to accomplish is to use Identity with Roles to access the API. I currently have the application running on MVC with 4 years of data. I want to move to an API back end and WASM PWA front end. Originally, I was looking to use JWT, but of late there is a buzz about the security of JWT, then .NET 8 was released that includes a Token auth and includes some API Endpoints.

@scottycroy
Copy link
Author

So in the browser debug, while checking the Network and the call out to the login?userCookies=true. The Set-Cookie field has an error flag that states:
"This attempt to set a cookie via a set-cookie header was blocked because it had the
SameSite=Lax" attribute but came from a cross-site response which was not the response to a top-level navigation"

@guardrex
Copy link
Collaborator

guardrex commented Feb 7, 2024

I was just looking over the various security issues, and I'll note in passing on the same-site situation that it's being handled on a different issue over on the main repo. It's separate from CORS, so I suppose the product unit will work it separately. Anyway ... check out the remarks and cookie config setting same-site to none ... dotnet/AspNetCore.Docs#31389

@guardrex
Copy link
Collaborator

@JeremyLikness ... Is there any movement on your end for this one?

I suspect on the WASM client we'll need to add Access-Control-Request-Headers with a value of content-type to the outgoing request, but I haven't set it up to test yet.

@halter73
Copy link
Member

The error is pretty explicit that "No 'Access-Control-Allow-Origin' header is present on the requested resource.", so I don't think it has anything to do with Access-Control-Request-Headers. Can somebody please provide the complete network trace? I suspect that the configuration is getting messed up somehow. What happens if you do policy.WithOrigins("https://localhost:7171")...?

@halter73
Copy link
Member

I think the issue for unauthenticated requests might be that UseAuthentication() and UseAuthorization() are implicitly added before the UseCors() middleware gets a chance to add the needed headers. Calling UseAuthentication() and UseAuthorization() explicitly afterwards might fix the issue.

@guardrex
Copy link
Collaborator

I think the issue for unauthenticated requests might be that UseAuthentication() and UseAuthorization() are implicitly added before the UseCors() middleware gets a chance to add the needed headers. Calling UseAuthentication() and UseAuthorization() explicitly afterwards might fix the issue.

That piece was just addressed on the PR ... WASM+Identity sample updates (dotnet/blazor-samples #210).

@guardrex
Copy link
Collaborator

guardrex commented Mar 6, 2024

@scottycroy ... Are you still having trouble? If so, can you respond to @halter73 on ...

If you're not facing this issue any longer, I'll close this issue and keep an 👂 open for more CORS feedback.

@guardrex
Copy link
Collaborator

guardrex commented Mar 7, 2024

I'll close now with an 👂 open for further issues on this subject.

@guardrex guardrex closed this as completed Mar 7, 2024
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Bug Something isn't working
Projects
None yet
Development

No branches or pull requests

4 participants