We followed this project and wired up our MVC application to use the new ADAL bit but we are seeing the following error when the token expires:
XMLHttpRequest cannot load https://login.windows.net/0bccafdb-3696-4344-3269-991d0a93be57/oauth2/autho…QzLTk5MWUtOGE5KRLTIFMYWE3MTliNjU1YMJTLENi00YWIzLTllNDQtYmVmZWU4ZWFjMjQ1. The request was redirected to 'https://login.microsoftonline.com/login.srf?wa=wsignin1.0&wtrealm=https%3a%…ZAEkNmNhNzFiYTUtZWZhOS00YjE0LWExYTYtZjQ5NjgwMzU5NzEz7Q2&wp=MBI_FED_SSL&id=', which is disallowed for cross-origin requests that require preflight.
Related: CORS preflight request responds with 302 redirect in Azure hosted Web API
That sample is not meant to be used with XMLHttpRequest. It is secured via a redirect based protocol, which in turn requires full browser postbacks for performing authentication operations. That protocol is not designed to work with Web API and AJAX calls, and although it can work for testing purposes production use will force you into hacks and other bad tactical measures.
If you want to make calls from JavaScript, please consider http://www.cloudidentity.com/blog/2015/02/19/introducing-adal-js-v1/.
Related
I've developed simple REST API using a expressJs. I'm using React as my client side application. So the problem is anyone can see my API endpoints because of react app is in client side. So they will also able to make request and fetch data from my REST API. (May be they will build their own client side apps using my API.) I've seen some question about this and couldn't find any comprehensive answer. How these kind of a security problem should be handled? Is it possible to give the access for API to only my client app? If not how huge brands that using REST API prevent that? (Also I don't have a user authenticating scenario in my product as well. People can just visit and use the website. They don't need to register).
Authentication can be a way but it can be bypassed. Another way is you can create a proxy server which strictly blocks cross origin requests, hence it blocks requests from other domains to make request to your API, and you can make your API call from that proxy server. In this way your API server endpoint will also be not compromised.
If, as you state in your comment, this is about users on your own website being allowed to use your site's API, while disallowing off-site use (e.g. other websites, wget/curl, etc) then you need to make sure to set up proper CORS rules (to disallowed cross-origin use of your API) as well as CSP rules (to prevent user-injected scripts from proxying your API), and you also make sure to only allow API calls from connections that have an active session (so even if you don't want user authentication: use a session managemer so you can tell if someone landed on your site and got a session cookie set before they started calling API endpoints).
Session management and CORS come with express itself (see https://expressjs.com/en/resources/middleware/session.html and https://expressjs.com/en/resources/middleware/cors.html), for CSP, and lots of other security layers like HSTS, XSS filtering, etc, you typically use helmet.
I have created few API on nodejs a d want to consume in same nodejs app. Even I have ensure cross origin to my domain.
It's only preventing cross domain and not allowed API.
But when using postman it's allowed .
Please help to provide how to restrict my nodejs api to be used by my app internal in angular and should not allow cross domain and postman.
Cross domain protections are implemented only in a browser to protect end-user browser security. They do not apply to http requests made from Postman or from node.js or from any other programmatic tool, only from the browser.
There is no way to keep your API from being called by other agents besides your own web app. This is just the way of the web. For your web page to be able to use the API in the browser, that API has to be open to the public.
The usual way to provide some protections on such APIs is to require some sort of user login in order to use the API. Your own web app can have a logged in user and your server can require a certain login cookie be on the http request before your server will fulfill the request. This too can be used by 3rd party tools such as Postman, but they would have to first obtain an appropriate login cookie.
To prevent abuse even in these cases where they get a login cookie, you would need to track usage on your server and if you detect any irregular patterns or abusive patterns (often with some sort of rate limiting detection logic), then you can temporarily or permanently ban that user login.
I have a webservice working on a domain say www.abc.com . I want to configure my server so that none of the request coming from another domain (except from www.abc.com) will be accepted. I should not use user authentication or anything related to token based authentication. So, the only option i can think is CORS but i do not exactly know how to use it. Any help would be great.
I am using nodejs and express
Don't set a CORS header. Done.
To address your comment: Postman doesn't make Ajax requests, it makes requests. If you don't indicate in Postman that it's an Ajax request, it's just a standard client request.
See also how Postman send requests? ajax, same origin policy for some more details.
I'm building a browser based application in Javascript. I've tried to access the docusign api via jQuery:
$.support.cors = true;
$.ajax({crossDomain:true, url:"https://demo.docusign.net/restapi/v2"})
I get the error:
Cross-Origin Request Blocked: The Same Origin Policy disallows reading the remote resource at https://demo.docusign.net/restapi/v2?_=1407189114238. This can be fixed by moving the resource to the same domain or enabling CORS.
Accessing other APIs such as yahoo, totally works:
$.ajax({crossDomain:true, url:"https://query.yahooapis.com/v1/public/yql"})
Is there a special thing that I need to do for docusign api? Thanks. (Note: My examples here use blank queries to illustrate whether an api is accessible at all. The actual code uses real queries. This problem is not caused by not having a real query. You can see this yourself by pasting the above url into your browser and see that it returns some xml.)
DocuSign does not support CORS (Cross-Origin Resource Sharing) in its platform. There are too many potential security risks with CORS and for DocuSign to maintain its extremely high level of security and certification compliance it can not support CORS.
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?