I'm just starting to look at this php test file for Docusign and it makes reference to two autoload.php files at the top that I down see in this repo, Where would I find them please?
https://github.com/docusign/qs-php/blob/master/qs-02-php-send-envelope.php
Scott, this is an older example and we may need to update the documentation for it. Thanks for bringing this to our attention.
As to your general question of "how to start off with PHP?" I would recommend you check our newer versions after you decide which oauth flow you would prefer.
If you want to use JWT - https://github.com/docusign/eg-01-php-jwt
If you want to use the code grant - https://github.com/docusign/eg-03-php-auth-code-grant
The first one (JWT) is a bit less secure but does not require the end user to log in themselves to DocuSign, while the code grant does require it which makes it more secure. It depends on your needs. You can read about oauth flows here - https://developers.docusign.com/esign-rest-api/guides/authentication
Related
Looking into Docusign's API Auth0 documentation and sandboxes and the examples for making a successful 0Auth are based on the following SDK methods:
getAuthorizationUri()
generateAccessToken()
getUserInfo()
These methods work as expected.
However in the Node.js SDK there is also the AuthenticationApi with following methods:
getOAuthToken()
revokeOAuthToken()
What is difference for both set of methods and in which use cases each should be used? I can't find examples of when they should be used?
Also for 1st set of methods couldn't find a SDK method to revoke the current access token of a user. What is the suggested way to do it using DocuSign's API?
The DocuSign SDKs are based on our swagger spec which include properties and methods from older versions of our APIs. With the previous versions of OAuth it was necessary to make these calls to obtain a permanent access token and to also revoke it.
In terms of the methods used, our SDKs are meant to use industry standard dependencies to handle the token requests and creation. If you'd like to see it in action and how you can tap into it, I would recommend having a look at our quickstarts or git repository for Node. Included in the download are methods for invoking both Code Grants and JWT Grants. The quickstarts operate in Demo only, however when you go to download them it actually configures an OAuth workflow in your Demo account for you -- then it feeds the necessary configuration file into the quickstart download. Under ideal circumstances you would be able to simply run npm start / install and see how it works.
If you need further assistance with this, feel free to open a case on support.docusign.com where someone from my team can work directly with you in terms of consultation and troubleshooting.
Links:
https://developers.docusign.com/docs/esign-rest-api/quickstart/
https://github.com/docusign/code-examples-node
Regards,
Matt
I would like to develop a new web-app in node.js (using express). I am relatively new to node.js world, so I assume there are frameworks that I am not familiar with.
Is there any framework (like Spring for Java) that manages authentication (and save the trouble from the developer)? Or each developer has to write this code over and over again?
Login/Logout is not all. There are other flows:
registration (create account),
forgot-password (and then set new password),
locking/unlocking an account,
change password
and I think I have covered all flows.
I know that each application has its own UI, forms, maybe with its logo, but the flow itself is similar for most applications.
In addition, I know that it is not that hard to implement, but it could be great to have some kind of tool / framework / infrastructure which implements the flows.
Is there such a tool/framework which helps applications' developers and implements these flows?
I've searched this issue but could not find anything.
Thanks!
Long ago I have developed authentication-flows for Java over Spring, and recently I wrote authentication-flows-js.
It is a module that answers most flows - authentication, registration, forgot-password, change password etc., and it is secured enough so applications can use it without the fear that it will be easily hacked.
It is for node.js applications (written in TypeScript) that use express. It is an open source (in GitHub). A release version is on npm, so you can use it as a dependency in your package.json.
In its README (and of course in the npm page) there are detailed explanations for everything and if something is missing - please let me know. An article will be published soon (I will add a link as a comment).
You can find here an example for a hosting application.
NOTE: I have heard comments like "It's not so difficult to implement". True.
But you have to make sure you take care of all cases. For example,
what happens if a user tries to create account that is already exists?
what happens if a user tries to create account that is already exists
but inactive? what about the policy of the password? (too long/too
short/how many capital etc.) what about sending the email with the
activation link to the user? how you create this link? should you
encrypt it? what about the controller that will receive the click on
the link and activate the account? and more...
I'm having to debug claims in production and I have no idea which claims a user have. This is a SharePoint application.
Given a username, is it possible for ADFS/DC/whatever to give me the claims that would be associated with that user? If so, how?
I can have the IT guy run something (configuration, exe, etc.) in production (very quick)
I can redeploy the whole application including debug code to extract claims (days)
I've already done #2 in the past. I'm wondering if ADFS has an command line or a menu somewhere that would provide me that information.
After talking with Dominick Baier on Twitter (author of IdentityServer), that feature apparently doesn't exist. So I'll mark this as answered and move on with my life and find some other ways to fix this problem.
Screenshot of the conversation:
I'm trying to develop a site, where users will be registered directly on it, as opposed to being authenticated by Google mail etc. Beside the usual username/password I need to collect more data from the user - name, address, etc. What would be the quickest way for adding the desired functionality? Short of writing my own Auth plugin I see two options:
Create my own registration form (which I kinda need to do anyway) and use HashDB for storing the passwords and later authentication. However, yesod.auth.hashdb seems to be gone from the latest version (why?) and is only available separately here: https://github.com/ollieh/yesod-auth-bcrypt/ . Is something wrong with it? Security flaws?
Use http://hackage.haskell.org/package/yesod-auth-account - looks much closer to what I need, because it already provides registration page, but it doesn't seem to be supported by the latest yesod 1.2.5 and it is not clear how to integrate my additional fields into the existing registration process
Since this article http://symfony.com/doc/2.0/cookbook/security/custom_provider.html has not been written yet, has anyone an idea of how to do that ? (In my case it would be using LDAP authentication).
Thanks for your answers
To help you get started you can check out my blog post which outlines how to create a very basic user provider system:
http://clintberry.com/2011/custom-user-providers-symfony2/
EDIT: This post only covers the custom User Provider. To use LDAP authentication you will need to create your own Authentication Provider as well or use a third party library. http://symfony.com/doc/current/cookbook/security/custom_authentication_provider.html
This first thing I would suggest you is to do a search for a LDAP bundle on the great website KnpBundles (results here). I saw two results. If you are willing to use an external bundle, you could just use of the two given in the results.
If you prefer to create your own bundle for this task, what I would suggest is to inspire you from these two bundles. Another useful suggestion is to check the FOSFacebookBundle. It is in no mean related to LDAP but, they implements their own provider, so all the glue is there to implement your own.
Just a small notice, if you are developing against Symfony2 master branch, it is good to know that security factory registration has changed a bit. So, be carefull when looking at other bundles to be sure what version they are targeting.
Hope this helps.
Regards,
Matt