I am creating a web app that has the following requirements:
There will be multiple administrators working for a tenant. The administrators will upload a document that needs to be signed and select the recipients and click send. The recipients will receive a link by email, click it, log in, view the document and sign it.
I was looking into third party developer API's to help with this such as DocuSign but a few questions/concerns came to mind.
I am going to assume that uploading and setting the areas to sign would need to be done through the docusign site. So would each administrator have to login in to the single tenant docusign account and upload their documents? Seems like it wouldn't be possible.
As an alternative I was thinking about staying away from the third parties entirely and just using an HTML signature pad under the document. However, with this technique the actual document would never be signed so for printing purposes it would look bad.
If anyone can shine some light on this topic that would be great. I am trying to figure out what my options are.
(I work for DocuSign.) Using DocuSign or another 3rd party product to handle the signing ceremony and related legal issues is usually a business decision that you'll want to discuss with your colleagues.
Legal issues to be considered include the signer's authorization to use eSignatures for the transaction, authentication, non-reputability, and more.
If you choose to use DocuSign, we have many code examples to help you implement your application.
It is common to "embed" the signing ceremony within your application. Your application can programmatically create the document, or use pre-canned documents.
Signature fields can be placed via anchor text as suggested by #EmmanuelRosa or specific coordinates on the page can be used.
If you have questions about how DocuSign works, contact DocuSign for more information. You can also sign up for a free trial account. When you're ready to develop your software, sign up for a developer sandbox account. More info is available on the DevCenter.
Added: Multiple tenant application
If you're writing an ISV application that you'll sell to multiple customers (tenants) then each customer will usually have their own DocuSign Account. In some cases you'll find that customers will have a pre-existing DocuSign account that they will want to use with your application.
In other cases, your customer's first need for a DocuSign account will be to use it with your application.
If you want, and depending on your volumes, you can resell DocuSign accounts to your customers who need them.
Each DocuSign account can handle any number of users. Users are usually people who send transactions for signing.
Signers do not need a DocuSign account and are not charged for.
You will not want your customers to share a DocuSign account since an account administrator can see all of the account's transactions.
Generally speaking, DocuSign does not charge per account. Instead it charges either per sender or per sent transaction (envelope).
Also note one ISV application written by you will have one Integration Key (same as a client_id) and that application can be used by any number of users, in any number of different DocuSign accounts.
I am going to assume that uploading and setting the areas to sign
would need to be done through the docusign site.
Actually, you can do that programmatically :)
I don't recall the details, but I do remember creating a template (*.docx file) of the document that would be uploaded. The template had placeholders for where the signature goes. I believe I used something like {{signature}} as the placeholder. Then, in your code you use the DocuSign API to upload the document and template; There's a way to tell the API what placeholders you used for the various fields.
The signing happens on the DocuSign website, but you can set up the document through the API.
In fact, it is possible to upload to multiple recipients with DocuSign. As the DocuSign documentation is suggesting, here are the steps to follow in order to send to multiple different recipients from the same account (administrators account).
Upload your document
From your DocuSign Account, click NEW, then click Send an Envelope.
Click UPLOAD A FILE to upload a document from your computer, or click GET FROM CLOUD to upload a document from an online location. Locate the document you want to upload and click Open.
Add the recipient
In the RECIPIENTS field, enter the recipient's name and email address.
Add the email subject and message
a. DocuSign automatically adds an email subject when you upload a document. You can edit this subject and add a message to the recipient by filling in the MESSAGE fields.
b. When finished, click NEXT.
Add signing fields
The Fields Palette and your document appear. The recipient name is displayed in the Recipients List.
To assign a signature or other field for the recipient, click and drag a field from the Fields Palette and place it on the document.
Preview and send your document
Review your document, then click SEND.
I work for HelloSign. The HelloSign API fits your use case very well and you can try it out for free. https://app.hellosign.com/api/reference
Do you want to have the document uploading take place on your website? If so, that is fine with the HelloSign API. We have a workflow called Embedded Requesting where the administrators could place the signature fields using an editor. We have other ways of placing signature fields as well.
Building it yourself is a lot of effort if you want the signature to be legally valid. You can reach out to HelloSign API Support at apisupport#hellosign.com
Related
I have a website and my own server and database, I also have an native Android app. I need to allow users to be able to sign-in with their account from the website inside the app in order to sync information and other things they need to use. I've been stuck for a couple of days trying to figure out how to do that. I've found a lot of content regarding OAuth and AppAuth but they are focused on using an OAuth API to the job. Back on my server, I use Hybridauth for social login, but users can also register directly on the site. How would be the proper way to allow my users to sign-in to their website account through the Android app?
You're overthinking it. OAuth isn't meant for users to log in, it's meant to enable external services to access data on behalf of a user.
To make a user log in? Create a POST endpoint on your webservice named login. It should take two parameters- username and password. The body of the login service should salt and hash the password, then check if the hash equals the hash stored in the db for the same user. If so, you're logged in and you return a success packet with a unique token to authenticate you for later requests. If not, you return a failure. The Android app would ask the user for their data, then send a request to the endpoint. On success it saves the token and sends it in all future requests to authenticate yourself, either as a parameter or as a header.
This is of course the simplest possible version. More advanced features would include expiring of login tokens, refresh tokens, possible lockout if you have too many bad requests, etc. But the above is the basic idea. Although really I'd look for an open source solution you can take, as there's quite a lot of complexity when you get into all the stuff mentioned above, and its a place where a mistake that leads to a vulnerability is probably the most dangerous.
I have a problem with the Docusign embedded Edit View.
My application connects to Docusign via JWT. Using the API, I'm allowing users to edit existing envelopes (when in draft) through my own application. The redirection to docusign works fine and the users are able to edit an envelope, adding/removing recipients, setting the signature blocks, etc. All good there. My problem is with the callback.
Using the ReturnUrlRequest, my callbacks are successful and after editing an envelope, users are redirected back to my application. The problem is that before this happens, for a few seconds they are looking at the Docusign inbox for the account. This is a security issue and could allow users to see privileged information, as if they send an envelope after editing it, they'll be looking at the sent folder and can see all other recent envelopes. I presume they could also stay in the inbox and do whatever they wanted if they click on an entry quick enough, but I haven't confirmed this yet.
I need the callback to go directly from the envelope edit to my application, and prevent anything else from docusign from appearing. Is there a way I can lock this down?
And yes, I know that this is something I shouldn't be doing in any event, and that my basic problem is that I'm using the edit view in the first place. I don't have much of a choice. I originally implemented things using the API and my own application provided all of the configuration options on their own. The client, however, didn't like this and essentially demanded that their users be allowed to use the Docusign system's own editing suite, as that is what they are familiar with. I'm trying to square the circle as best as I possibly can.
As per the Information Security Notice on the linked page, the Create Edit View provides fully authenticated access to the sending user's account. Even if you were able to prevent the brief view of the inbox, a savvy user could 'break out' of the edit view by navigating directly to app.docusign.com (or appdemo.docusign.com in the sandbox) because their DocuSign session is still valid.
The only way to 'secure' this is to provision each sending user their own membership on the DocuSign account so that users cannot see each other's envelopes (unless explicitly allowed to do so via Document Sharing).
In addition to Drew's answer: please ask your DocuSign account rep or customer service contact to add your customer information to internal ticket EC-1009. That will help raise prioritization of providing a secure edit screen for applications to use.
I have a Java program utilizing the Gmail API that authenticates with our G Suite via OAuth 2.0, downloads all attachments for messages in a specific user's inbox, and processes said attachments.
I am experiencing a very specific issue where for some messages sent from certain fax servers that are being forwarded to the account, where the "to:" field is addressed to something other than the account itself, using
service.users().messages().get(userID, messageID).execute();
will not retrieve these attachments. This is even true if I am using the universal "me" identifier.
If I forward the message to myself and the "to:" field changes, the program is able to pick up on it, but not if it is addressed to someone else. This is a problem because these messages are addressed to an email that is outside of our G Suite domain. I have tried all methods of forwarding and filtering within Gmail, including forwarding to another provider like Yahoo, but automatic forwarding does not change the "to:"/deliveredto: field in the original email, and thus causes the same issue.
I have tried using a different method for authenticating, where I tried utilizing a Service Account for domain-wide delegation with the full Gmail scope, as referenced here Gmail API domain-wide delegation and following the exact steps outlined by the Google documentation.
The problem is, even when I use domain-wide delegation and specify the setServiceAccountUser as the fax user from the "to:" field, it says that is not a valid user, which makes sense as that is not a Gmail user or user within our domain, it is being forwarded from an external source we have no control over.
I have attempted to build a program that manually forwards these emails back to this platform account, but I run across the same issues as the service.users().messages().get(userID, messageID) method requires a userID and messageID.
Message message = service.users().messages().get("xxxxxxxxx#faxmail.vonage.com", messageID).execute();
Above is the section of code I've isolated where the .get() method is not allowing the program to get attachments for this external user, which seems to be directly defined by the "to:" field in the email - if I forward this email to myself and the "to:" changes to my user, it instantly is able to grab the attachment.
When I tried domain-wide delegation with a Service Account or changing the userID in the detailed method to the faxmail.vonage.com address, it would give me a 403 or 400 error - either complaining the user doesn't exist, or saying "Delegation denied for platform#xxxxxx.com"
If you are using G Suite you can use the Forwarding rules in the Control Panel to send all the emails coming for that address to whenever you want.
edit:
With the content compliance rules on the G Suite Admin Panel you can adjust the envelope information allowing you to change the "to" field.
I'm trying to create a web service to use the Google Plus API. I'm writing it in java, however I can't figure out what files I need and how I would go about posting to Google plus groups using Java
If you have any insite please could you post relavent links and helpful tips to help me out.
EDIT 1:
I have been playing around with the GooglePlus API provived by Google and have written a project based on the sample code given from this page: https://developers.google.com/+/domains/posts/creating
The code runs fine until it gets to the GoogleTokenResponse tokenResponse = flow.newTokenRequest(code).setRedirectUri(REDIRECT_URI).execute(); line. Where it returns a null error. I am copying the link provided in the console and pasting in the code, however everytime it just returned a null error, is there a specific part of the returned code given that causes an issue?
Posting to Google+ is only supported for accounts in a Google Apps Domain (and even then, with restrictions).
If you are logging in using a GMail account - you don't have an Apps Domain account. If you're logging in using some other email address (ie - you have an email address, but you can't use Google account features such as GMail or Google Drive with it) then you don't have an Apps Domain account. If you are using a Domain account, your Domain admin may need to enable Google+ for your Domain before this works.
See https://developers.google.com/+/domains/getting-started for the differences between what you can do with the Domains API and the regular Plus API.
Note that neither API lets you post to a Google+ Community or post publicly. The Domains API does let you post to a user's circle, as long as the members of that circle are also part of the Domain. The Domain API also lets you post to everyone in the Domain. The normal Plus API does not allow posting at all.
There is a third API, knows as the Pages API, which allows Pages to publicly post on their stream. This API, however, is available to a limited number of partners such as Hootsuite. You can read more at https://developers.google.com/+/api/pages-signup, but there isn't much more available publicly.
Your web service should first authenticate against Google. This authentication can either be using a service account (if you want to post only through one account) or users's account (if you want to post via user's account) using oAuth mechanism.
For more details about how to authenticate, refer to How to authenticate our users in our website with Google Account
Have a look at https://developers.google.com/+/api/ for detailed information about how Google Plus APIs can be used.
I'm have implemented a module for Java web application that users will need to request for them to access the secured data. It works like this: when users that does not yet have access clicks on a certain link, a request is made and is received on the server side. It now generates an email and sends to people who are "approvers". The email contain links on approving or denying the access of that user.
Approved Link:http://hostname/App_name?action=actionClass&approved=true
Denied Link:http://hostname/App_name?action=actionClass&approved=false
Now the question is, is there a better way to do this which also takes into consideration the security?
I did try to look for other posts that are related to this but the results don't seem to be touching on this regard. If there are any that I have missed, I would appreciate if you can also point them so I can revise the question.
Thanks in advance
I'll assume that you are authenticating the users when they click on the given link, because otherwise it's just bad mojo.
You can have some privileges assigned to that user and check that to see if you are going to allow the approve or not.
That depends on how you are sending out the email. Assuming you are doing it client-side, then a user could intercept their own approval link, which clearly you don't want.
A better way (assuming you aren't doing this already) would be to send the user information (via HTTPS of course) to your server and then have the server generate and send the email. This way no one has access to the approval link except those emailed by the server and those in control of the server (you hopefully).