i have read a lot about DocuSign api and how they works, i figured out that they don't support cors.
For this reason i'm using an angular proxy configuration for my test environment, so i could do all my tests with my localhost.
The problem is that when i upload my project on a server i can no more use that proxy config, if i try to use it by replacing "localhost" with my domain name it returns me an html which is not an error from docusign but a sort of error related to my proxy conf.
I think i need create a cors gateway in my server in order to use the api, i've read a guide about that and it's very complicated since i'm only a frontend developer.
So my answer is:
is there any easier method to use these api in my online application?
can i obtain some sort of permissions from docusign which grants to my domaint to access their api calls without going into some sort of cors errors.
Thank you for attention
I work in DocuSign developer support. We do not support CORS. It is on our roadmap. Looks like you have your options, move the calls to DocuSign to the back-end or build a CORS gateway.
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 created MongoDB and Node.js REST API for my website. I am accessing my database data from the API and showing it on my website. I am doing these things locally on localhost.
Now I want to host my REST API. I don't have any idea regarding hosting. If I host my REST API somewhere and start getting data through its endpoints, then anybody can use those endpoints and access my data, but I want to restrict it to my website only. Meaning, that only my website can make requests to that API, no other websites can make a request. If other websites try to access it, it should show an error. How can I achieve this? Can someone please explain me step by step how do I do this?
I think you are referring to CORS. You need to set your API to have a response header like this on all requests:
Access-Control-Allow-Origin: https://yourSiteDomain.com
You can read more about it here: https://developer.mozilla.org/en-US/docs/Web/HTTP/Headers/Access-Control-Allow-Origin
Other people can still access your API directly though, through postman etc.
What you need is a CSRF(cross site request forgery) token
for node js you can use
csurf : http://expressjs.com/en/resources/middleware/csurf.html
look online on how to implment it
I'm working on a submission for a conference. I'd like to integrate DocuSign with Alfresco's Angular based developer framework and specifically the Alfresco Content App.
In order to keep things simple, I'd like to think about workflows that could be done 100% from the browser without any backend code of my own.
I suspect I could create a "Sign this document now" type action for any document found in the Alfresco UI. That could initiate an OAuth flow that would not require any backend services of my own.
I think I would need to put my integrator key into the SPA. This would then be visible to anyone using the app. From reading through docs, I'm unclear if it is OK to "leak" this key?
Are there other use cases I can implement in an SPA without adding backend services of my own? Things like, sending a doc out to be signed by one or more people? Or embedding a signing experience in the Angular UI?
I have seen the following series on the DocuSign blog:
https://www.docusign.com/blog/dsdev-building-single-page-applications-with-docusign-and-cors-part-1/
Having read through that and also the REST API documentation, I'm still unclear if it is even possible to implement something like this without any support from my own backend service.
I also have not found any place online where I can reach out to a developer evangelist from DocuSign to discuss my options. I believe DocuSign developers monitor SO, so figured this was the next best thing.
Great question. Browsers implement the Same Origin Policy. So, as I wrote in the blog series (see all three of my posts listed below), you will need a CORS gateway to make API calls from your Angular program running in the browser itself to the DocuSign system.
The good news is that creating a private CORS gateway isn't hard. See part 2 of the series:
Part 1. Introduction
Part 2. Building a private CORS gateway
Part 3. An example React SPA
Authentication
Your app will need an access token when it makes API calls to DocuSign. There are multiple techniques available to give your app the access token it needs:
Your app can, by itself, authenticate the user with DocuSign. In this case, because of the security issues--as you mentioned in your question--you do not use the OAuth Authorization Code Grant flow. Instead, you use the OAuth Implict Grant flow, which is designed for this use case. This flow is demonstrated in part 3 of the blog series.
You can implement the OAuth Authorization Code Grant flow in your server, and then create a private API between your server and your browser app to obtain the access token.
A private API
As an alternative to using CORS, you can just implement your own private versions of the DocuSign API methods on your server. Then your browser app would send a private_send_envelope request to your server. Your server would manage the access token, send the request to DocuSign, and relay the response back to your browser app.
This pattern is the same as your question about implementing a backend service. It will work fine but is not as elegant as implementing everything within your browser app. Depending on your immediate and future API needs by your SPA, this might be a good idea or not.
CORS support is the key
Until DocuSign has CORS support you'll need to build something on the backend. Either a CORS gateway (which only involves configuration, not software) or a private API gateway.
Please ask your DocuSign sales or technical contact to add your information to the internal DocuSign proposal for CORS support, PORTFOLIO-1100. This will help raise the priority of CORS support. Thanks.
Specific answers
Regarding:
I think I would need to put my integrator key into the SPA. This would then be visible to anyone using the app. From reading through docs, I'm unclear if it is OK to "leak" this key?
Answer: It is okay to add your integrator key (IK) to your browser app if and only if the IK is set for Implicit Grant usage (check the "Mobile App" checkbox on the IK's property sheet).
Having read through that and also the REST API documentation, I'm still unclear if it is even possible to implement something like this without any support from my own backend service.
Answer: at this time you will either need to implement a private CORS gateway or implement backend software.
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.