-
Notifications
You must be signed in to change notification settings - Fork 4k
Discuss CORS #167
Comments
Hey all, I had noticed that Client has a collection of AllowedCorsOrigins. Is this property being used to validate against the origin string being passed in the ICorsPolicyService? When I created my own ICorsPolicyProvider, I didn't see any way to check against that, because I don't have any reference to the client calling except for the orgin string passed in the IsOriginAllowedAsync. Is this interface just a blanket check against all origins no matter how we filter it, or should we check the origin against all AllowedCorsOrigin collections for all clients? Thanks |
This feature is not done yet. |
@leastprivilege Oh I see. I want to contribute to this functionality. Is there already an idea on how we would want to achieve this? Maybe expose a GetAllClientsAsync method in the IClientStore and do something similar to what the InMemoryCorsPolicyService is doing, or would that not be as efficient? |
I added a method to IClientStore2 (derived from IClientStore) that allows fetching CORS origins for enabled clients (InMemoryCorsPolicyService currently looks at all clients whether enabled or not) |
Yea, maybe on the iclientservice it makes sense to add the cors semantics. we'll think about it. |
When are you planning to release this functionality?? |
@dementeddevil, what did you mean by this:
|
What is the reason that IdentityServer needs to have its own CORS implementation rather than leveraging the ASP.NET CORS middleware? |
We are using that implementation. It's just a matter of allowing CORS for specific endpoints and determining where the policy is sourced from. It's common to associate CORS origins with client configurations. |
I was able to make this work with a kind of a hack. `;
` |
@Jjanne i'm curious why you had to do so much of that implementation? was there something about our ICorsPolicyService that wasn't working for you? |
I needed CORS for both the IdentityServer and for the API. |
Ok, that makes sense. And the problems you're having (and the reason we have this open issue) is because the design of the Microsoft CORS middleware doesn't really make it easy for our situation where we're hosting 2 different "things" in the same pipeline. Plus with the fact that the policy for IdentityServer will most likely need to be dynamic from a database. We'll keep investigating here and try to come up with a solid solution that works. Thanks. |
@Jjanne I was having the same issue, but I have it working now without any workarounds. Although I still get warnings in my logs from IdentityServer about CORS rejections on any of my API endpoints. I think that the ASP.NET CORS provider takes over after and adds the headers on the responses. Its just confusing that I have two separate CORS configurations and that IdentityServer is failing on the /api calls even though the correct Origin is configured. My Startup.cs file just has:
In public void Configure() =>
In Clients.cs:
These are the warnings from my logs:
Request Headers:
Response Headers:
|
Done. |
I want to use ASP NET membership tables as base and then add claims, scopes and token tables as well, in order to store Refresh tokens in the database |
I had same issue. Anyone have solution? Thanks |
This thread has been automatically locked since there has not been any recent activity after it was closed. Please open a new issue for related bugs. |
No description provided.
The text was updated successfully, but these errors were encountered: