Using asp.net webApi
I've site1 (http://localhost:53723) and site2 (http://localhost:64009).
I want to fetch data from site2 to site1 (Cross domain, not same origin).
We can use jsonp for this, and I've achieved data.
Can we use jsonp to post/put/delete verb for cross domain (not same origin)?
Your design might be a little bit flawed and you should reconsider if you really need to make cross-origin requests. If you do, then a lot better solution in case when you need to support POST/PUT/DELETE verbs is CORS. Carlos Figueira have some nice blog post on how to implement it in ASP.NET Web API:
Implementing CORS support in ASP.NET Web APIs
Implementing CORS support in ASP.NET Web APIs – take 2
Related
I am building a RESTfull API with express.
Is there any cases I might need to plug https://www.npmjs.com/package/cors library you can thing of? For what particular scenarios would you use CORS with RESTfull API ?
You need CORS when the API is accessed from browsers on a website domain that is different from the API domain. So probably, yes you need to support CORS.
You do not need CORS support if the API is not accessed from a browser.
You do not need CORS support if the API is on exactly the same domain (and port) as the website accessing the API.
I am currently developing an API that will be launched into production in a matter of weeks. I am relatively new to REST, started reading about CORS - and realized that it could impact me.
What conditions will a REST service not be accessible to a client? I have been using sample html/js on the same server, and through Postman - a google chrome addon - to access my API. I have had no issues so far.
When the API goes live, it will be hosted at 'api.myserver.com'. Requests, at the beginning, will come from 'app.myOTHERserver.com'. Will these requests be denied if I do not use a CORS-friendly approach like JSONP or special 'access-control' headers that permit my domain?
What about accessing rest APIs from other non-browser clients? Such as a C# application? Are these requests permitted by default?
Assuming I do need to add 'access-control' headers server-side, to permit the scenario described above when my API goes live, is it better (performance-wise) to let your web server (NGINX in my case) handle the headers, or should I add them through PHP or NodeJS?
This is more about the same-origin policy applied by web browsers than it is about RESTful APIs in general.
If your API is intended to be used by web applications deployed on a different origin host/port than the API, then you have these options:
Respond with appropriate headers that allow for techniques like CORS to work.
Have the web server which serves up your web content (in your example, app.myOTHERserver.com) handle your REST API requests too by proxifying your API requests from the web server through to the API server. For example, you could have your API exposed on your web server under the URL /api, and then it's just a matter of setting up a web proxy configuration that forwards requests under that URL to your API server.
Use JSONP or other techniques.
If your API is going to be used by non-web applications, you have nothing to worry about. This is only a restriction applied by browsers when running JavaScript code to make sure that the user hasn't inadvertently clicked on a phishing link with some hackery in it that tries to send their PayPal password to Pyongyang.
When the API goes live, it will be hosted at 'api.myserver.com'.
Requests, at the beginning, will come from 'app.myOTHERserver.com'.
Will these requests be denied if I do not use a CORS-friendly approach
like JSONP or special 'access-control' headers that permit my domain?
You can specify what clients can access your web service to an extend. Assuming you're using Express: How to allow CORS?
We're developing a web-api back-end ... implemented some calls, done in c# with sqlserver etc.
The backend will have more than one client apps. One would be a website, one would be a mobile app using phonegap, and hopefully we get more client apps using the service ...
We would like to setup the web-api project independent from the website stuff and NOT run into crossdomain issues.
Could a reverse proxy be used for this? Or maybe a vpn in azure? Any other suggestions?
Paul
There are a couple of things you need to do:
Set up your WebApi to support CORS (Cross Origin Resource Sharing). You can do this easily by installing the Cors Nuget package from Microsoft:
Install-Package Microsoft.AspNet.WebApi.Cors
Then you need to enable cors early in the application lifetime, for example in the Application_Start section of global.asax:
GlobalConfiguration.Configuration.EnableCors();
See this link for more details: http://www.asp.net/web-api/overview/security/enabling-cross-origin-requests-in-web-api
I see that you are concerned about security. Good. Then you may need to do two more thing to get your CORS to play nicely.
First, you should really look into creating a custom Cors policy provider (see the link above). Since you are hosting your WebApi in Azure, make it easy to configure the allowed origins. This should be a whitelist of only the websites you want to allow on your webapi.
Second, I assume that your user is authenticated on the website. I also assume that the way you call the WebApi is via jQuery or some other provider that uses jQuery as a transport (such as BreezeJS). To pass on the authentication details to your WebApi, jQuery needs to know that it should do that. The easiest way to do this is to set a global setting on your website:
$.ajaxSetup({ crossDomain: true, xhrFields: { withCredentials: true } });
A good tip for knowing exactly what goes wrong (because from experience, something will), is to use Chrome to test. Then you can open this link and see all the details of what is happening on the wire: chrome://net-internals/#events
Happy coding! :)
Create a Cloud Services (Web Role - MVC 4 web application), then deploy your webapi to there. Just make sure your webapi handle CORS issues, so you can call the api from both clients.
More info:
Enabling Cross-Origin Requests in ASP.NET Web API
PS: I'm working in a project that works exactly as you said. A website and mobile app as clients of my webapi on azure and we are doing like this. It's working pretty well.
I'm developing a rich client javascript application with ASP MVC 4 Web API back end.
How would you suggest to secure all the ajax requests ad make sure they are made from an authenticated user.
Thanks !
Any securing mechanism would do, consider for example Forms authentication.
You add the Authorize attribute to your controller methods and ajax requests carry the cookie if it has been issued from the server.
This is really as simple. If for some reason it doesn't apply to your scenario, you'd have to be more specific.
As Wiktor suggested, you could use Form-based authentication (HTTP mechanism).
If we consider your question more broadly though, what does it mean to secure all the AJAX requests?
You probably want to achieve:
integrity
confidentiality
non repudiation
accountability
more?
The topic is more broadly discussed on wikipedia. More specifically you want to do the following in your API:
secure the communication channel: use SSL (either one-way or 2-way). This will provide integrity and confidentiality
use authentication. This will give you non-repudiation and accountability. There are different authentication methods available in .NET (Forms, HTTP Basic, SAML-based...)
for advanced scenarios around authorization (which user is allowed to call with method), use claims-based authorization (part of .NET framework), RBAC, or XACML.
What is the simplest security that could be applied in ASP.NET Web API in MVC 4 to prevent external users from accessing the Web service , is there anything simple enough like authorization of some token which could be maintained for each instance?
It depends, a Http Web API is stateless by nature. If you are invoking the Web API from a web browser using Ajax, you might rely on cookies for maintaining the user identity in the session. Otherwise, other traditional HTTP authentication mechanisms like basic authentication requires the user credentials in every call. You might want to take at the Thinktecture.IdentityModel library, which provides a lot of extensibility points for authentication.
http://leastprivilege.com/2012/10/23/mixing-mvc-forms-authentication-and-web-api-basic-authentication/
Regarding authorization. The framework already ships with a few attributes like AllowAnonymousAttribute or AuthorizeAttribute that you can use to decorate the Web Api methods.
Better you could have search about Authorization in MVC. Yes it does support it. Please check the below links which could be helpful.
Secure MVC 4
Redirect unauthorized Users
Custom Authorize