how to call cross domain ajax calls using angular /Jquery - asp.net-mvc

I have a application hosted with domain www.abc.com .This is actually WebApi application . I want to build a separate UI application using asp.net mvc, and its domain is www.xyz.com.
The UI application consuming Angular,HTML5 and other Web technologies.Here i really need to perform GET,PUT,POST,DELETE against www.abc.com. unfortunately the limitation of jsonp , i like to choose CORS (HTML5 Cors), but i can't pass json object to CORS calls . what are the best possible best approach to call cross domain calls (GET,PUT,POST,DELETE) using angularJs with my problem scenario . What should i change in IIS to handle CORS request.

add below web.config in webapi
<system.webServer>
<httpProtocol>
<customHeaders>
<add name="Access-Control-Allow-Origin" value="*" />
</customHeaders>
</httpProtocol>
</system.webServer>
and in angular, set below config options for $http
header("Access-Control-Allow-Credentials: true");
header("Access-Control-Allow-Origin: http://url.com:8080");
header("Access-Control-Allow-Methods: GET, POST, PUT, DELETE, OPTIONS");
header("Access-Control-Allow-Headers: Origin, X-Requested-With, Content-Type, Accept, Authorization");
also check: this link

To enable cross domain ajax calls you can place crossdomain.config in asp.net web api root folder when published with following contents.
<?xml version="1.0"?>
<cross-domain-policy>
<allow-access-from domain="*"/>
</cross-domain-policy>

Related

prevent website to be injected in iframe - server and client validation

I'm developing a asp.net mvc website and want to implment some security features. One of them is to prevent the website from being injected in an iframe. I have read that it is possible to do that with x-frame-options which is a server side validation, but i have also read that it is required to implement client side validation with JS as well. Could anyone help me with that? Many thanks!!
the client side validaton can be done using the busting JS.
To implement the server side validation, you need (as you already mentioned) to set x-frame-options in IIS or in the application (Global asax file):
IIS:
<httpProtocol>
<customHeaders>
<add name="X-Frame-Options" value="DENY" />
</customHeaders>
</httpProtocol>
Global asax:
protected void Application_BeginRequest(object sender, EventArgs e)
{
HttpContext.Current.Response.AddHeader("x-frame-options", "DENY");
}
For more info about busting js, see this link:
https://www.owasp.org/index.php/Clickjacking_Defense_Cheat_Sheet
I have the same problem with old broswers, for example, mozilla 3.0
Hope this helps!

Asp.net Web API 2 and mixed Authentication using both Integrated Windows and Token based

I have an asp.net Web API server running under IIS, that until now has used windows authentication as it has only had other services running on the same domain conencting to it.
So, in my web.config I have the following settings...
<system.web>
<compilation debug="true" targetFramework="4.5.1" />
<httpRuntime targetFramework="4.5.1" />
<authentication mode="Windows" />
</system.web>
<system.webServer>
<security>
<authentication>
<windowsAuthentication enabled="true" />
</authentication>
</security>
....
With this I can use a browser (or the services) on the same domain and reach my services.
Now we want to allow Mobile applications to also connect. We will be using a a token based scheme based on this, and so far to use this I need to turn off the Windows authentication in my web.config to use this. If I leave in the windows configuration as above, I don't even get any of the Owin middle where methods (or custom filters) called when I, for example, se Postman to call a route with no windows authentication set.
So my question is
How can I allow either authentication, so that even a Browser (on the same domain) can still call the routes and be authenticated (via the Negotiate), but also allow other clients to use the token based scheme? Also (very important) how do I configure this in web.config to allow both?
Thanks in advance for any help!

Custom headers ASP.net MVC

I'm trying to serve WebDav requests to create a CalDav server so that users can access our calendar function easily on any device of their choosing.
The problem is in trying to serve any custom headers. I've written a custom ActionResult that sets up any result easily in the right way. Upon a OPTIONS request, which gets recognized, it adds:
response.AppendHeader("Allow", "OPTIONS, PROPFIND, HEAD, GET, REPORT, PROPPATCH, PUT, DELETE, POST");
When I look into the request that the end-user receives the following header appears:
Allow: OPTIONS, TRACE, GET, HEAD, POST
When I then try to do a request with the custom header PROPFIND it simply returns a 404 error. I tried googling but there is not a lot around about this stuff. It's probably something I have to enable or disable.
https://www.iis.net/configreference/system.webserver/httpprotocol/customheaders
please see section How To.
You can do it on multiple ways
IIS
Web.Config
Code : C#, VB.NET, JavaScript
I had to remove the WebDavModule and WebDav handler in the web config. After I had done that it worked perfectly.
<system.webServer>
<modules runAllManagedModulesForAllRequests="true">
<remove name="WebDAVModule" />
</modules>
<handlers>
<remove name="WebDAV" />
</handlers>
</system.webServer>

MVC4 404 Errors

I'm building out a series of MVC4 Web API's that return various bits of information. In most of the APIs, I'm conducting a GET method and passing a fully qualified domain name.
If I pass a short name the API returns the data as expected; however if I pass a fully qualified domain as an ID ending in ".com" I get a 404.
The API works fine when I debug within Visual Studio 2010; however once I "publish" the content, I start getting 404's. My initial hunch is that it's something with IIS; however I haven't been able to put my finger on the exact problem.
WORKS: /controller/action/server_shortname
404: /controller/action/server.domain.com
Any guidance would be appreciated. Thanks
If you are using .NET 4.0 you can use this in your web.config:
<httpRuntime relaxedUrlToFileSystemMapping="true" />
Apart from that you should also assure that you are running your applicationPool in integrated mode.
There are a few other posts that mention the same problem and depending on your configuration you could find your answer there:
How to get ASP.NET MVC to match dot (".") character at the end in a route?
ASP.NET MVC Url Route supporting (dot)
. has a special meaning in the path portion of an url and is interpreted by IIS as a extension separator.
If you are running in IIS Integrated Pipeline mode you could add the following handler to the <system.webServer> node:
<system.webServer>
<handlers>
...
<add
name="UrlRoutingHandler"
type="System.Web.Routing.UrlRoutingHandler, System.Web"
path="/api/*"
verb="*" />
</handlers>
</system.webServer>
You will only need to adjust the path="/api/*" to the endpoint that you configured your API to listen to.

Why does IIS6 Accept-Encoding value equal null when attempting compression with ASP.Net MVC

I have plugged in the HttpCompress module to enable compression for my MVC web application.
If I run my site through the development web server (Cassini) I have no troubles with the execution of compression.
However when I deploy the site to IIS6 the compression is not executing. I have checked the source code of the compression library and the CompressContent handler returns without acting becuase a null value exists for
app.Request.Headers["Accept-Encoding"]
My best guess is that this has something to do with the handling of extensionless urls in IIS6. What do I need to do to fix this problem in production?
[ below is the config for the module, if that is of any assistance ]
<blowery.web>
<httpCompress preferredAlgorithm="deflate" compressionLevel="high">
<excludedMimeTypes>
<add type="image/jpeg" />
<add type="image/png" />
<add type="image/gif" />
<add type="application/pdf" />
</excludedMimeTypes>
<excludedPaths></excludedPaths>
</httpCompress>
</blowery.web>
Some further investigation discovered that I was accessing the server via a proxy, and it appears that the proxy was not forwarding the compression headers to IIS.
It seems the easiest way to identify a proxy meddling with the request is to check the response headers for a via entry.
See the complete list of http headers as a homework task.

Resources