I am using DocuSign for sending email to client/end user by using createEnvelope API of DocuSign. if the end user forwards the email to someone else he /she can view the document and sign on his/her behalf.
so I have used signer.accessCode = "random value" and passing this value again to end-user/client so that while viewing document he/she needs to place the code which I sent in a different email and its working properly till now.
The problem arises when the recipient views the document and did not sign it and accidentally forward the email to someone else..now that person can view document easily without entering the access code as DocuSign does not ask to place an accessCode second time or once the document is viewed. Is there any config setting or any property in code which I can apply for this case?
I want DocuSign to ask the accessCode popup every time when the end user wants to view it.
Secondly, is there any provision to automatically delete a document from DocuSign if the end user did not sign the document for any specific number of days.
There are two options under Go to Admin > Security Settings that can mitigate this concern. The primary option you want is Recipient Authentication Triggers: Every Time a recipient accesses an envelope. You may also want Login Requirements: Login Required if Signer has an Account.
For the second question, you'll want to set an Envelope Expiration. When an envelope has expired, recipients who have not signed are unable to access it.
Related
I've been trying for few days and couldn't really find answers about what I'm trying to do.
Take the example of a registration where a link to confirm your email is sent, and then when the link is clicked the account is confirmed.
I want to achieve this to do a kind of validation for announcement publication.
I tried taking the example of the symfony verify email feature, but in this case it's using the authenticated user when the link is clicked. In my case, the person clicking the link doesn't have an account on the website and shouldn't be authenticated.
How could the mail link, when clicked, change a booleon in the database, like 'is_confirmed' from 0 to 1 without needing a user authenticated?
Thanks
You're still going to need to authenticate, but you'll do it with a one-time token instead of a userid and password. For each message:
Generate a unique unguessable string, like a UUID v4.
Generate an expiration timestamp for however many minutes/hours/days in the future you want the token to be good for.
Save the token and the expiration timestamp in the db so it's associated somehow with the record in question. This might mean adding two columns to an existing table, or creating a new join table.
Generate an email to the recipient, including a link that has the token embedded in it, like http://example.com/approve?token=whatever or http://example.com/approve/whatever
Create the /approve page. Configure it to not require any traditional Symfony authentication. It should then:
Look up the token that was provided.
Verify that the associated timestamp isn't expired yet.
Perform whatever process you want to occur.
Wipe the token and the expiration from the db.
We have a PHP/MySQL based User Management System and are integrating it with Keycloak version 16 where we will store users credentials.
Our application does not allow users to self register. We create user accounts on the system. When we do this we do NOT specify a password because we want users to set up their own password.
The current system sends 2 separate emails in 2 different circumstances regarding passwords:
If it's a completely new user who does NOT have an existing password, we send them a link to set up a password.
If it's an existing user who already has a password, the system allows them to reset it, e.g. if they forget their password and can't login.
Keycloak seems to cater for scenario (2) because the login forms have a forgotten password link which opens a form where the user can enter their email address and receive a link which lets them do (2).
Unfortunately it doesn't deal with scenario (1) very well and that's where our problem starts. This has been asked a while ago Send password forgotten mail but it seems that Keycloak didn't support this very well in 2020 and perhaps still doesn't now.
Our "workaround" to this was that we added custom email templates and a custom page (reference: Themes on https://www.keycloak.org/docs/latest/server_development/#emails) which includes wording that caters for both scenarios, e.g. "set your password" rather than "reset your (existing) password". The result of this is that our email and form now reads appropriately for both scenarios (1) and (2).
The problem
We want to be able to send a link to the user that allows them to set their initial password to cover scenario (1).
We know that this page exists because on the login page for Keycloak there is a link to the forgotten password form that handles scenario (2). However, the form requires the user to enter their email address and submit the form. The user then receives an email from Keycloak which contains a URL to the page where they can do this. The URL has the following format:
https://example.com/auth/realms/foo/login-actions/action-token?key=...
The key= contains a ~945 character token. Going to the URL above redirects to the form where the user can reset their password. This next URL does not contain a token but a cookie has been set in the browser - by the previous URL - which makes it functional:
https://example.com/auth/realms/foo/login-actions/required-action?execution=UPDATE_PASSWORD
We can't send either of these URLs to the user because the first one (containing key=) has no API method for us to find out what it is - it's only possible to generate this by going through the "forgotten password" step during login, in the browser.
The second URL (/login-actions/required-action...) won't work either because it relies on the previous URL (containing key=) setting the cookie in the browser. If you try and go to this second URL directly (i.e. bypassing the first URL) it will error.
So neither of these URLs will work because we can't find what the first one is programmatically, and we can't use the second one without knowing the first one.
I found https://lists.jboss.org/pipermail/keycloak-user/2018-October/015910.html and the suggestion is using the Keycloak API to trigger a password reset email. This works - sending an HTTP PUT request containing 'UPDATE_PASSWORD' along with the relevant user ID sends the user an email. The request endpoint has the format PUT /{realm}/users/{id}/execute-actions-email which is documented on the link above.
Up to here all is fine - the user gets an email. However, this email does NOT contain a link that goes directly to the "reset password" page! Instead it sends them an email containing the following text:
Your administrator has just requested that you update your account by performing the following action(s): Update Password. Click on the link below to start this process.
Link to account update
When the user clicks "Link to account update" it then shows them a web page like this:
It is only when they click on the link on this page (the one that says "click here to proceed" on the screenshot) that they arrive at the form where they can reset their password.
This is a really poor user experience because the user gets sent a (badly worded) email with a link to... a page with another link! It should just take them to the password reset page directly. What's more frustrating is the fact that Keycloak is clearly capable of generating/sending the exact email we'd like in this scenario: the one which gets sent when a user manually does a password reset via their browser.
So the problem seems that Keycloak's API doesn't support this incredibly important and common use-case of a user being able to set an initial password, in a user-friendly manner.
I am adding the js script in the template to automatically click "click here to proceed". It's ugly but at least the user doesn't see the page
looking for a little advice on HTML emails and GDPR re-permission.
With the new GDPR regulations I have to create an email to send out to an existing list requesting their consent to continue contacting them.
My intention is to have an 'I'm in' button in the email, which when clicked takes the user to another page/url which has a simple form on it requesting the users email address and checkbox for them to tick to opt in.
My question is can I achieve this another more simple way. For example in the email itself when the user clicks the 'I'm in' button, can a post submission be made automatically with their email address, that gets sent to clients email, and they then just get re-directed to a standard success message. Is something like this possible? It would save having to create a form somewhere and make the process easier for the user.
I don't normally do HTML emails so I'm a little unsure - any help on this would be greatly appreciated, thanks in advance
Yes, you could embed their email in the query string of the URL and then have a webapp at that URL pick up their email from the querystring and process it. Obviously you'd need to code the webapp side accordingly.
E.g:
I'm in!
If you can still send an email to the user, the collection of consent can be quite simple. It will be sufficient to send each user an email containing a link to accept the newsletter (e.g. "Yes, I want to receive the newsletter"). The email should also contain the terms and conditions of the service, and the privacy policy. What come next can be either automated, or handled manually.
The best option would be to automate the process. This can be done in multiple way, the simplest being with a customized link for each user pointing to a website capable of interpreting the data transmitted by the link itself. To achieve this result, the link contained in each email should contain an identification code - which should be anonymized where possible - so that it will be possible to link the new consent to each user. In this way, when the user clicks the link, he or she will be taken to the website. At that point, the backend will be able to collect the code passed by the link, identify the user and, finally, re-subscribe the user to the newsletter.
In practical terms, in the email there could be a link with a value to be passed as a `GET« parameter:
Yes, I want to receive the newsletter
The server-side logic could be as follows (in PHP synthax):
// re-subscribe.php
$uuid = $_GET['uuid'];
$user = getUserByUUID($uuid); // assumed function that gets the user infos by a UUID
subscribeUser($user); // assumed function that re-subscribes user to the newsletter
echo 'Thank you!'
This could even be accomplished manually, provided that a link tracker service/tool is used.
In this – less ideal – case, in the email there should only be a single clickable link, the one required to express consent (e.g. "Yes, I want to receive the newsletter"). This link could take the user wherever deemed most appropriate. What matters, in this case, is the ability, through the tracker service/tool, to know which users have clicked the link. As long as there is only one link in the email, this would inform us that the user has expressed his or her consent, and thus we could manually re-subscribe them to the newsletter. In this case, the link to the terms and conditions and to the privacy policy should be included as static text, and not as an actual clickable link.
For more info, check out our blog post, inspired by this question, at blog.autoprivacy.eu/2018/05/newsletters-after-gdpr-existing-and-new.html
I'm building a website with a login and registration system where the users' information will be stored on a database. I'm implementing a standard e-mail verification step after the account creation. The process is the following: An account is created, but has a 'verified' flag set to False. Then, an e-mail is sent to the user with a link to verify the account. Finally, after the user clicks the link, the 'verified' flag is set to True.
This should be sufficient, but it got me thinking. What happens to the unverified accounts? Someone could set up millions of unverified accounts that fill up my database storage space and available usernames. This could be problematic.
Is there a way to build a similar system in which the account would only be stored in the database AFTER the verification?
One way to solve your "Problem" would be to use a Capchta at the registration and/or to delete all not-activated accounts when the registration date is further ago than x days.
You could encrypt all information of the registration in the verification link, instead of storing that information in a new user account.
When the user clicks the registration link, you would decrypt that information and create the account.
To keep the verification URL as short as possible, this would require to minimize the amount of information you request during registration. I would suggest to ask for the E-Mail only and to request all the other attributes on the verification page.
Many sites implement different methods and I am having a hard time deciding on which method would work best for my site.
My user profiles contain the following data:
username
password (in hash/digest form)
email
I'd like the password reset method to be secure, user-friendly, and efficient.
You should add two fields, reset_code and reset_expiry
This is the process for a secure password reset functionality.
User selects "Forgot password".
User prompted for email/username.
If valid, generates a GUID, and stores it in reset_code and also stores Now()+24 hours in reset_expiry in the database against that particular user.
Then it sends an email to the email address with a link to confirm the password reset. This email would contain a link to your website with the user's username AND reset_code embedded. (This stops a malicious user resetting a third parties password just by knowing their email)
Once the user clicks on the link in the email, they will be directed to your website.
Your website will validate that: the username and reset_code matches, and the current time hasn't exceeded the reset_expiry time.
If all is okay, we can complete the password reset. This can be done by either:
a) Onscreen a new randomly generated password
b) A new randomly generated password via email
c) The ability to enter a password of his/her own choosing
You should not store the passwords of your users, not even in encrypted form. You should only store the hash/digest necessary for authentication. Then, you can't "recover" the password (because you don't know it), you can just reset it, and/or give the user a temporary one-time password that allows him to set a new password.
Update: if you are doing the above, the standard procedure is to have a "require-password-reset" form. The user enters his id (typically his email) and a "token" (eg, a random string) is generated, stored in some table with some expiration date, and sent to his email along with a link to the "password-reset" form. In this form the token is checked, the user is allowed to enter a new password, and instructed to attempt a new login.
Update 2: A small privacy issue might arise: What should we do if the user id (email, user name, or whatever) entered in the request form does not exist in our database? To output a message "User does not exist. Check the id and retry." may be ok, but in some cases it would cause a privacy problem: anyone can check if other someone is registered in your database! If you want to avoid that, you must output the same message ("a mail has been sent with instructions...") even if the user wasnt found (and hence a mail was not actually sent).
Similar privacy issues advise to just output the message "login incorrect : bad user or password" when the user tries to login unsuccessfully - don't disclose if it was an incorrect user or password.
I agree with Leonbloy. Storing the password leads to trouble like the Gawker incident from a few weeks ago (1.5 million userid/pwd combinations were discovered and published).
You should, however, have a "reset password" function that e-mails the new password to the original e-mail address used to open the account.
There should be no provision for changing the e-mail address during the password reset. If the user doesn't have access to the old e-mail account anymore, too bad. Abandon the account and start over.
And use a good Captcha on the reset screen.