Just wanted to know what is the best elegant way (currently available) to handle CORS (Cross-Origin Resource Sharing) in ASP.NET WebAPI so i can use XmlHttpRequest over multiple domains ? How i can integrate this in the headers of every type of request (GEt, POST, etc..) with OPTIONS too ?
Thanks!
Tpeczek have a nice found, however while doing my own research ive found something similar and also very elegant ways of handling CORS which enable you to configure your CORS in a config file in App_Start folder. Its all handled using an open source library called Thinkecture. See details here :
http://brockallen.com/2012/06/28/cors-support-in-webapi-mvc-and-iis-with-thinktecture-identitymodel/
It have many advantages.. you can configure origins, methods (GET, POST, etc.), access to specifics controllers and actions and it also keep your controllers clean from any attributes.
WebAPI, IIS and ASP.NET MVC is supported !
Carlos Figueira has a nice series of posts about CORS and ASP.NET Web API:
Implementing CORS support in ASP.NET Web APIs
Implementing CORS support in ASP.NET Web APIs – Take 2
CORS support in ASP.NET Web API – RC version
Personally I'm a big fan of Take 2 approach because EnableCors attribute can be easly extended to give you control over allowed origins.
Add below in web.cofig file(inside the system.webserver element).
<httpProtocol>
<customHeaders>
<add name="Access-Control-Allow-Headers" value="accept, maxdataserviceversion, origin, x-requested-with, dataserviceversion" />
<add name="Access-Control-Allow-Origin" value="*" />
<add name="Access-Control-Max-Age" value="1728000" />
</customHeaders>
</httpProtocol>
and add below code in global.aspx.cs file
protected void Application_BeginRequest(object sender, EventArgs e)
{
if (Request.Headers.AllKeys.Contains("Origin") && Request.HttpMethod == "OPTIONS")
{
Response.StatusCode = 200;
Response.End();
}
}
There is now CORS support in the nightly of web api
http://blogs.msdn.com/b/yaohuang1/archive/2013/04/05/try-out-asp.net-web-api-cors-support-using-the-nightly-builds.aspx
Use nuget to:
Uninstall the Microsoft.AspNet.Mvc.FixedDisplayModes package.
Install Microsoft.AspNet.WebApi.Cors package from the nightly builds
Then fix the bindings in the web.config
Then enable CORS
config.EnableCors(new EnableCorsAttribute())
Read more about it on this wiki https://aspnetwebstack.codeplex.com/wikipage?title=CORS%20support%20for%20ASP.NET%20Web%20API&referringTitle=Specs
Edit 19-04-2013 Scott Guthrie has blogged about it: http://weblogs.asp.net/scottgu/archive/2013/04/19/asp-net-web-api-cors-support-and-attribute-based-routing-improvements.aspx
It depends how fine-grained you want to control CORS. If you want to allow any domain for instance you can add static CORS headers to all responses by configuring them in IIS. I chose this approach and wrote about it here.
Related
I'm reading the book API Security in Action by Neil Madden. In the book, there is a section about CORS and how to attach the proper headers in Java. I am aware that there is already an AddCors and UseCors built in to ASP.NET Core, but for my edification I wanted to roll my own middleware.
However, I found that I was unable to receive any sort of OPTIONS requests, they were automatically being rejected somehow, and I was unable to respond to them manually, even when it was the first middleware in the pipeline. Since the UseCors middleware is able to intercept these pre-flight requests, I'm curious whether or not it is hooking into a deeper level of ASP.NET Core than I am able to.
TL;DR: Is ASP.NET Core (or Kestrel) performing some sort of automatic preflight request checking even when UseCors is not called?
The answer in the end is no, ASP.NET does not do anything fancy when it comes to preflight requests. I looked into the source code and the CorsMiddleware (and associated extensions) are relatively simple; most of the logic is contained within the ICorsService, and doesn't impact the middleware pipeline directly.
I'm unsure what my original issue was being caused by, but it is now resolved.
See below for the source code:
https://github.com/dotnet/aspnetcore/blob/a450cb69b5e4549f5515cdb057a68771f56cefd7/src/Middleware/CORS/src/Infrastructure/CorsMiddleware.cs
It is worth noting that if you add the CORS headers manually, you will get the following exception
System.InvalidOperationException: Endpoint ProjectName.Controllers.SomeController.Login (ProjectName) contains CORS metadata, but a middleware was not found that supports CORS.
Configure your application startup by adding app.UseCors() inside the call to Configure(..) in the application startup code. The call to app.UseCors() must appear between app.UseRouting() and app.UseEndpoints(...).
You can avoid this error by setting a flag to true in the custom CORS handler
httpContext.Items["__CorsMiddlewareWithEndpointInvoked"] = true;
However, I feel it's important to stress that this should only be done for education purposes; you should be relying on built-in CorsMiddleware and not rolling your own whenever possible (and it should hopefully always be possible).
I have a .NetCore 3.1 API project that uses Entity Framework.
It is working perfectly when I run it locally from Visual Studio.
However, after publishing to a production IIS 8.5 server, I get the following errors when I try to hit an API that uses PUT on the production server.
xhr.js:178 PUT https://nationalparks.xyz.gov/api/plants/91 405 (Method
Not Allowed)
My controller begins like this:
[HttpPut("{id}")]
public async Task<IActionResult> PutPlant(long id, [FromBody] Plant plant)
{
...
}
And client-side looks like this:
await axios({
method: "PUT",
url: "api/plants/" + plant.id,
data: JSON.stringify(plant),
headers: { 'Content-Type': 'application/json; charset=utf-8' }
});
Honestly I'm stumped...I'm not sure why it's doing that.
I've seen a few posts saying to modify the web.config, but my app uses appsettings.json, not a web.config.
Any ideas?
Thanks!
The reason behind the issue is the WebDAV module intercepted the request. to resolve the issue you could follow the below workaround.
1)Remove WebDAV from your system:
open control panel-> “Turn Windows Features On or Off”->un-ticking the WebDAV publishing checkbox.
or
2)Add below code in your web.config file:
<system.webServer>
<modules>
<remove name="WebDAVModule" />
</modules>
<handlers>
<remove name="WebDAV" />
</handlers>
</system.webServer>
Please remember that after doing these changes you can nit use the WebDAV module in iis.
dotnet core applications do use web.config when running under IIS. You will notice that the publish command makes a web.config file that tells IIS which DLL to run for your application.
I think I had the same issue a while back. I fixed it by adding lines to web.config to remove the WebDAV modules. See this answer for more detail:
https://stackoverflow.com/a/12443578/65432
As stated on the NLog GitHub the ${aspnet-request:serverVariable=String} layout renderer is not supported in .Net Core.
The documentation doesn't provide alternatives to many of the variables available under serverVariable.
My question is, are there any alternatives? Like to access remote address, server name, port etc? Or do I just have to write a bunch of custom layout renderers documented here and dependency inject all the stuff by hand?
For ASP.NET Core there as many new layout renders. The reason is that the API of ASP.NET Core is very different and the server variables can't be read like in ASP.NET (so non-core)
There are currently 13 layout renders for ASP.NET Core that renders a part of the request.
${aspnet-request} - ASP.NET Request variable.
${aspnet-request-contenttype} - ASP.NET Content-Type header (Ex. application/json)
${aspnet-request-cookie} - ASP.NET Request cookie content.
${aspnet-request-form} - ASP.NET Request form content.
${aspnet-request-headers} - ASP.NET Header key/value pairs.
${aspnet-request-host} - ASP.NET Request host
${aspnet-request-ip} - Client IP.
${aspnet-request-method} - ASP.NET Request method (GET, POST etc).
${aspnet-request-posted-body} - ASP.NET posted body / payload
${aspnet-request-querystring} - ASP.NET Request querystring.
${aspnet-request-referrer} - ASP.NET Request referrer.
${aspnet-request-url} - ASP.NET Request URL.
${aspnet-request-useragent} - ASP.NET Request useragent.
See also https://nlog-project.org/config/?tab=layout-renderers&search=package:nlog.web.aspnetcore
If you need something else, you could indeed create a custom renderer. If you need the http request you could use:
AspNetLayoutRendererBase.Register("aspnet-request-myrenderer", (logevent, httpcontext, config) => ... );
You need to reference the NLog.Web.AspNetCore package for that.
I'm using WCF 4 on IIS 7.5 and want to eliminate the default .svc extension from the URL of all my RESTful services. I've seen the approaches documented using the Url Rewrite Module and an IHttpModule but I don't want to take those approaches.
I am vaguely familiar with the concept of Routes introduced in ASP.NET MVC and as I understand they are now abstracted out of MVC in Net 4 as System.Web.Routing. But in looking at the docs it appears I need to add a Global.asax file to my project which I'm not really keen on. Is there any other way to handle this?
I've also seen the Configuration-Based activation feature, but that only seems to eliminate the .svc file, but still requires I use .svc in the url of my service.
Can anyone summarize my options here for not needing .svc in my urls?
Sure, no problem: first off, read all about the new WCF 4 features in A Developer's Introduction to Windows Communication Foundation 4.
What you're looking for is called file-less service activation. It's a new setting in your <system.serviceModel> that looks something like this:
<serviceHostingEnvironment>
<serviceActivations>
<add factory="System.ServiceModel.Activation.ServiceHostFactory"
relativeAddress="[subfolder/]filename.svc" or "~/[subfolder/]filename.svc"
service="SomeNamespace.YourService"/>
</serviceActivations>
</serviceHostingEnvironment>
Basically, all the information you'd have in the *.svc file (path, service to call) is in this config section now.
You should be able to call this service at
http://yourserver/virtualdirectory/YourService
now - no more *.svc, no messy URL rewriting etc. - it just plain works!
Update: it doesn't seem to work that well, unless you go in and add a *.svc extension to your relative path - kind defeats the whole purpose!
If you want to register using an ASP.NET route, check out the MSDN docs on that topic. You'd have to have something like this in your application startup, in a web app that would be global.asax.cs:
void Application_Start(object sender, EventArgs e)
{
RegisterRoutes(RouteTable.Routes);
}
private void RegisterRoutes(RouteCollection routes)
{
routes.Add(new ServiceRoute("YourService",
new WebServiceHostFactory(), typeof(SomeNamespace.YourService)));
}
Hopefully, with that, you'll be able to get your service up and running without any *.svc file extensions!
Just to wrap up the answer and add one more point there. You'll need the same ASP.NET route registration as above:
void Application_Start(object sender, EventArgs e)
{
RegisterRoutes(RouteTable.Routes);
}
private void RegisterRoutes(RouteCollection routes)
{
routes.Add(new ServiceRoute("YourService",
new WebServiceHostFactory(), typeof(SomeNamespace.YourService)));
}
In order to get this working you need however to add some more things to web.config. The service hosting should be configured to be ASP.NET compatible. This can be done by adding aspNetCompatibiliyEnabled="true" to serviceHostingEnvironment element:
<serviceHostingEnvironment multipleSiteBindingsEnabled="true" aspNetCompatibilityEnabled="true" />
Hope this clarifies and gives an easier to find solution.
Important clarification for IIS 7.5 and Framework 4.0:
For the Web routing module to work, it requires the application pool set to "Integrated Mode", it doesn't works in "Classic Mode"
One additional problem I've found after switching is that when in "Integrated Mode" the application crashed on startup because I had modules included in the <system.Web> section.
I fixed it by moving the modules to the <system.webServer> configuration section that is new for IIS 7
How can I detect the user agent in a web service? My web service is implemented using a WCF webservice with basicHTTPBinding. It will be a post from some SOAP clients. I wish to know the user-agent from the clients.
I shall like to see some sample code for this.
I am using a WCF based web service and in the svc.cs, I tried to catch this.Context.Request.UserAgent. But it gives the following error:
this.Context.Request.UserAgent 'MySoapService.MyService' does not contain a definition for 'Context' and no extension method 'Context' accepting a first argument of type 'MySoapService.MyService' could be found (are you missing a using directive or an assembly reference?)
I also tried System.Web.HttpContext.Current.Request.UserAgent and it says:
'System.Web.HttpContext.Current' is null
Edit note:
I tried to activate the ASP.NET compatibility mode. I added <serviceHostingEnvironment aspNetCompatibilityEnabled="true" /> in the config file and added [AspNetCompatibilityRequirements(RequirementsMode = AspNetCompatibilityRequirementsMode.Required)] on the top of the class that implements the service interface. Then using System.Web.HttpContext.Current.Request.UserAgent gives me the user agent as desired.
There is another way to get the user agent without enabling ASP.NET compatibility in web.config:
string userAgent = WebOperationContext.Current.IncomingRequest.Headers["User-Agent"];
You can use also:
WebOperationContext.Current.IncomingRequest.UserAgent
You can read user agent from the HttpContext.Current.Request object if you enable ASP.NET compatibility in web.config:
What a totally unhelpful response!
This is not a trivial task. Yes it is obviously possible to get te user-agent string but how does one actually do it? I spent 2 hours checking google and so on but found the answer buried in MSDN documentation. In Visual Studio, from within a WebMethod try
this.Context.Request.UserAgent
That should do it!
User-Agent is a standard HTTP header. It'll be available to your web service just like it's available to anything CGI-like.
Did you even bother searching for this before posting your question? There must be millions of hits for it on Google.