We Keep Coding

Enable CORS on Specific URL in ASP.NET Web Forms

I'm not a backend developer, so I apologize ahead of time if I do not provide enough information. I am just trying to find some resources that will help my backend developer understand what I am trying to do.
I am trying to make an AJAX GET request to an rss feed inside of web application that was built using ASP.NET Web Forms. However, the request gets blocked because of Cross Origin Security. I want to enable CORS for the route that is associated with our RSS feed (/page/rss/{id}).
I was able to enable CORS in our webconfig using:
<httpProtocol>
<customHeaders>
<add name="Access-Control-Allow-Origin" values="*" />
<add name="Access-Control-Allow-Methods" values="GET" />
<add name="Access-Control-Allow-Headers" values="Content-Type" />
</customHeaders>
</httpProtocol>
But, that enables it for the entire project which is not what I want. Our routes are defined in an XML file like this:
<namespace.routing>
<routings>
<route name="publishedPage" url="page/{PageName}" page="~/Default.aspx" />
</routings>
<defaults>
<default url="http://blog.example.com" domain="example.com" page="page/homepage" />
</defaults>
</namespace.routing>
So, how would one go about enabling CORS on a specific path in ASP.NET Web Forms? If someone could point me in the direction of some resources that would help us that would be great. If you need anymore information I'm happy to provide it. Thanks!

I'm not sure how you are returning your rss endpoint, but if you have access to the HttpContext object, you can use it to supply the CORS headers directly.
HttpContext.Current.Response.AppendHeader("Access-Control-Allow-Origin", "*");
HttpContext.Current.Response.AppendHeader("Access-Control-Allow-Methods", "Get");
HttpContext.Current.Response.AppendHeader("Access-Control-Allow-Headers", "Content-Type");
Depending on how old your app is, you might need to use AddHeader instead of AppendHeader.

RESTful WebService CORS Preflight Channel did not succeed

I created a WebService in C#. All GET methods are working without any problems.
Now I need to provide some POST methods. When calling it via C# it works without any problems. Then I tried to write a small html page with JavaScript to call my methods. But there I get a CORS error ("Preflight channel did not succeed").
I already added the following part to my web.config file:
<customHeaders>
<add name="Access-Control-Allow-Origin" value="*" />
<add name="Access-Control-Allow-Headers" value="*" />
<add name="Access-Control-Allow-Methods" value="*" />
</customHeaders>
Sadly it is still not working. What am I doing wrong?

So what you have here is not really a valid way to handle CORS requests. The problem is that this will add the CORS headers to all responses, but browsers will use an OPTIONS request in order to check for CORS headers. This would work if you also implement OPTIONS requests for all of your API end points.
The better option is to use one of the CORS frameworks, such as this one: Enabling Cross-Origin Requests in ASP.NET Web API 2 for ASP.NET WebAPI 2. This type of framework will intercept the OPTIONS request for you and supply the appropriate response without the need for you to manually create 2 routes per endpoint.

AngularJS, WebAPI, and Windows Authentication: OPTIONS 401 and "Reponse for preflight has invalid HTTP status code 401"

I'm building an internal application for work that uses AngularJS, WebAPI, and Windows Authentication. The Angular client and the WebAPI are different projects, which will run on two seperate ports on my local machine.
I enabled CORS in Web.config of the API project using the following:
<httpProtocol>
...
<customHeaders>
<add name="Access-Control-Allow-Origin" value="http://localhost:#PORTOFCLIENT#" />
<add name="Access-Control-Allow-Headers" value="Content-Type" />
<add name="Access-Control-Allow-Methods" value="GET, POST, PUT, DELETE, OPTIONS" />
<add name="Access-Control-Allow-Credentials" value="true" />
</customHeaders>
</httpProtocol>
I can make GET requests just fine; the problem is when I try to save an object using POST:
function updateFoo(foo) {
return $http.post(baseUrl + "/api/foos", foo, { withCredentials: true })
.then(updateFooComplete)
.catch(updateFooFailed);
...
}
I receive the following errors in Chrome:
OPTIONS http://localhost:#PORTOFWEBAPI#/api/foos
XMLHttpRequest cannot load http://localhost:#PORTOFWEBAPI#/api/foos. Response for preflight has invalid HTTP status code 401
After a little Googling, I found this response mentioning the fact that the OPTIONS request shouldn't be authenticated.
How do I prevent OPTION requests from being authenticated by WebAPI? Am I missing something?

Swagger not able to retrieve operations from ServiceStack resources Service

I am trying to get Swagger to work with ServiceStack. The web server is located behind a Firewall and accessed from the Internet (my.domain.de:80). Requests are then forwarded to the web server on Port 8070.
When visiting the swagger page it is able to access /api/resources and retrieve the List of ServiceMethods, but then fails to retrieve the List of Operations.
When I use fiddler to inspect the result I see that he /api is missing so that swagger tries to get the List of Operations from /resources/ServiceName instead of /api/resources/ServiceName.
The Swagger-UI gives me the following error message:
Unable to read api 'ServiceName' from path http://my.domain.de/resource/ServiceName (server returned Not Found)
SwaggerConfig:
discoveryUrl:"../../api/resources",
ServiceStack Config:
WebHostUrl = "http://my.domain.de"
Update(2)
If I dont set the WebHostUrl the BasePath in the initial response from ServiceStacks resources service contains the portnumber from the webserver basePath=http://my.domain.de:8060/api. But on the Firewall this port is not reachable, nor do we want it to be reachable.
web.config:
<location path="api">
<system.web>
<httpHandlers>
<add path="*" type="ServiceStack.WebHost.Endpoints.ServiceStackHttpHandlerFactory, ServiceStack" verb="*" />
</httpHandlers>
</system.web>
<system.webServer>
<modules runAllManagedModulesForAllRequests="true" />
<validation validateIntegratedModeConfiguration="false" />
<handlers>
<add path="*" name="ServiceStack.Factory" type="ServiceStack.WebHost.Endpoints.ServiceStackHttpHandlerFactory, ServiceStack" verb="*" preCondition="integratedMode" resourceType="Unspecified" allowPathInfo="true" />
</handlers>
</system.webServer>
</location>
Update
in the Inital response the basepath is:
basePath=http://my.domain.de
and by my.domain.de I mean a real world url which is just the hostname without port, url-path, querystring or fragment (I acctually checked wikipedia for the correct names ;)
I have found this other question on StackOverflow, but it did not help me.
Swagger with Service Stack not working
How can I get ServiceStack/Resources Service to either add /api for its returned ServiceList?

Colleague of op here.
I spent some time researching this problem and I believe the issue is a bug in ServiceStack's swagger support.
See here:
https://github.com/ServiceStack/ServiceStack/pull/800
Quote:"When set, use webhosturl for base url in swagger and metadata links"
It is implemented correctly for metadata, but not for swagger.
Line 52 in SwaggerResourcesService.cs overrides the baseurl with the WebHostUrl if it is set, but does not combine with the real path as the implementation in metadata does:
https://github.com/sneal/ServiceStack/blob/6b33f5c2417587b5983c611b4bf8a5d42d88d890/src/ServiceStack.Api.Swagger/SwaggerResourcesService.cs

how to remove server info via <customHeaders> in web.config

I have removed the x-powered-by using <httpProtocol>
<httpProtocol>
<customHeaders>
<remove name="X-Powered-By" />
<remove name="Server" />
</customHeaders>
</httpProtocol>
This hides the X-Powered-By but the server (IIS info ) is still not getting removed
It would be good if there is a way where I can remove all the info in the Response Header
How can i do it?

I believe you need UrlScan to remove the IIS info.
The particular setting you need to configure is: RemoveServerHeader
By default, a Web server returns a header that identifies what Web
server software it is running in all responses. This can increase the
server vulnerability because an attacker can determine that a server
is running IIS and then attack known IIS problems, instead of trying
to attack an IIS server by using exploits that are designed for other
Web servers. By default, this option is set to 0. If you set the
RemoveServerHeader option to 1, you prevent your server from sending
the header that identifies it as an IIS server. If you set
RemoveServerHeader to 0, this header is still sent.