I want to enable CORS for a subdomain only, so I need to enable it programmatically, I thought doing this would be enough:
HttpContext.Current.Response.AppendHeader("Access-Control-Allow-Origin", "*");
But then I noticed that the JS library making the requests, makes an OPTIONS request first, so my code never runs.
Is there anyway to show that I have Access-Control-Allow-Origin in an OPTIONS request, but then allow or disallow it programmatically in a GET request?
Thank you
You can easily do so by writing a module, which is similar to what I described in this blog post,
https://blog.lextudio.com/2014/11/how-to-handle-cors-preflight-requests-in-asp-net-mvcweb-api-with-windows-authentication/
Related
In my StartUp.cs I have the following setup for CORS.
services.AddCors(_ => _.AddPolicy("LocalDev", __ => __
.AllowAnyOrigin()
.AllowAnyHeader()
.WithMethods("GET", "POST", "PUT", "DELETE")
));
It works as expected. However, I noticed that removing GET and POST doesn't seems to affect the funtionality. Removing PUT or DELETE has effect, though. I'm confused by this.
Is it the case that the methods for getting and posting enjoy a special status while the others are required to be explicitly provided? I haven't found any references on that in MSDN for the method.
.WithMethods affects GET/POST requests only when they trigger a CORS preflight OPTIONS request — basically, any GET or POST that includes custom request headers. If a GET or POST doesn’t include any custom request headers, then it won’t trigger a CORS preflight OPTIONS request, and so it will be allowed regardless of what the .WithMethods setting is.
In CORS protocol terms, .WithMethods sets the Access-Control-Request-Headers header value, which browsers only consult for responses to a CORS preflight OPTIONS requests.
For requests that do trigger a CORS preflight, an intersection of conditions is required; i.e., the request must have both the right origin and the right method. But for requests that don’t trigger a CORS preflight OPTIONS request, there is by definition no “right” method — because in that case, any Access-Control-Allow-Method header is irrelevant and ignored. Or maybe rather, conceptually, it’s more clear to just say that there’s a hard-coded list of “right” methods: the set of CORS-safelisted methods — GET, HEAD, or POST — defined in the Fetch spec.
.WithMethods affects GET/POST requests only when they trigger a CORS preflight OPTIONS request — basically, any GET or POST that includes custom request headers.
this is incorrect, even with a custom header, a POST+Preflight request works having .WithMethods("GET")
I would test a couple of requests to the API and check the Access-Control-Allow-Methods header. That's the actual logic that allows/restricts any HTTP methods to reach your API.
If the header does contain GET, even though you didn't specify it in your list of allowed HTTP verbs, we are looking at a .NET Core bug and I think you should log it at https://github.com/dotnet/core/issues
When using ITHit WebDAV server it applies its own CORS settings, this is OK for the Verbs and Methods in my case. However it only allows on to configure one Origin, in my case I have multiple origins I need to support. So is it possible to make ITHit use the origin settings that is configured on an application level without it overwriting it?
I ended up creating my own middleware that adds/replaces the Access-Control-Allow-Origin header on the response after it has passed the ItHit middleware, with the Origin from the request if valid. If the request is invalid is still up in the air as there are multiple flavors on how to deal with it, for now i just send a 403 without processing the request.
I hope IT Hit will do an update to not roll their own implementation and use the native one part of Asp.Net Core.
I've added a custom header X-XSRF-TOKEN and when a user logs out I want to be able to remove that header from future requests sent by the browser.
In the logout web api action I can modify the header like so:
Request.GetOwinContext().Response.Headers.Append("X-XSRF-TOKEN", "ModifiedToken");
On future requests it now sends requests with the X-XSRF-TOKEN with the value ModifiedToken. Is there a way I can remove it instead. With cookies you can expire them.
If I call the remove function on the Request or Response headers, on the next request to the server the header is still present:
Request.GetOwinContext().Response.Headers.Remove("X-XSRF-TOKEN");
or
Request.GetOwinContext().Request.Headers.Remove("X-XSRF-TOKEN");
Is it even possible to do this or even guarantee the browser will actually stop sending the header?
Try This.
Request.GetOwinContext().Response.Headers.Append("NULL", "ModifiedToken");
Note - I am not sure it will work or not. But you can try this one as well.
I want to use Nancy with the default routing, as it's clean and works well, however I want an option to log all incoming requests to the console (I'm using Nancy's self-hosting module) irrespective of whether an explicit route exists. Put simply, I want to be able to capture the verb, the incoming request URI, any posted data (if it's a POST request), etc.
How do I do this? Before/After only seem to run for requests that match an existing route, and a 404 does not trigger OnError either. Also, using Get["/(.*)"] only catches GET requests and will ignore other HTTP verbs.
Use the Before/After on an Application level, not Module, for that https://github.com/NancyFx/Nancy/wiki/The-Application-Before%2C-After-and-OnError-pipelines
I have an HttpModule and I'd like to choose the HttpHandler for the current request, is that possible? Also web.config is not an option because the condition is not based on path or extension. My googling skills have failed me, no matter what keywords I use all the results are "IHttpHandler vs IHttpModule".
You can create an HttpModule that will run on every request from the Client(Browser).
See here how he has used cookies to send timezoneOFfset by using HttpModule.
http://weblogs.asp.net/cprieto/archive/2010/01/03/handling-timezone-information-in-asp-net.aspx
Download the code and see how the things are working.
Definately you need some config changes.