I am trying to implement the email verification system on Parse-Server (/Heroku), when a user account is created; so that the user can confirm his/her account creation.
Things are working well for those matters:
I can create a working account.
The user receives the verification email that is expected.
The problem is this:
When the user clicks on the link inside the verification email. This is what appears in the browser:
{"error":"unauthorized"}
Has anyone seen a similar issue and knows how to solve it?
Related
I've signed up for a developer account with Docusign. We have about 15 users that access a Windows Forms page from another program where they fill out the proper information and click a button that calls a NET Core Web API which creates an envelope and sends to the signer. Those 15 users don't have accounts in Docusign and don't need them to. I want to use one admin or service account that will send and receive the emails, but I can't figure out how to do this.
I used my name for the developer account and now all my (test) Docusign emails show they are from me and once the signer signs, my email receives the signed documents. I've tried creating another "Admin" account, but I don't see any way to associate that user as an "API User". When I try using that user's GUID as the ImpersonatedUserID, my RequestJWTUserToken request comes back with "consent_required". But, when I go to the link I just get an error with "The client id provided is not registered with Docusign".
Everything in the Web API is working perfectly except for the emails showing they are from me and then the signed docs coming back to my email. This should be an easy thing to change the user, but apparently it's not, or I just can't figure it out.
You were on your way to fix this, but didn't follow through.
Create new user (you did it)
Find the new userId (you did)
Update JRequestJWTUserToken (you did)
Consent error - expected, the new user did not consent.
Obtain consent. You need to have a URL built correctly like this to do this:
https://account-d.docusign.com/oauth/auth?response_type=code&scope=signature%20impersonation&client_id=7c2b8d7e-xxxx-xxxx-xxxx-cda8a50dd73f&redirect_uri=http://example.com/callback/
Once you do 5, you need to log in with the same new user account you created (you may be automatically logged in with your original developer account, so log out) and provide consent.
Then step 4 will work just fine.
https://developers.docusign.com/platform/auth/consent/obtaining-individual-consent/
I need to change the forgot password link in firebase authentication template emails from a URL to a 6 digit verification code only.
The code will be generated on 'forgot password' and emailed to the user, once received the user would need to enter this verification code into the app... and after confirmation, he/she can change their password. How can I achieve this in firebase.
If you check the Customize account management emails and SMS messages documentation you can see that the oobCode is generate and added directly to the URL, and you cannot generate it otherwise.
On this community post a similar problem to yours is suggested and the proposed solution is to generate you own verification mechanism, although it is possible it represents a lot more work on your end than using the pre existing email with url configuration.
I tried signin button on the "My Account" page. I enter a email, and it told me to create a password to use with Persona.
It supposed to send me a email with couchdb api link if I registered account successfully. But it hasn't.
So, how can I get an account on iriscouch? Is there any services can do the same thing of iriscouch?
Can anyone help me? I'm in emergency.
I have a registration form in my website. I don't want to give away information about the existence of an e-mail address for security reasons. How should we, security wise, handle the "e-mail already exist" scenario without giving this information away?
Theoretically, its impossible, think about the email as the user name, you will inform the user that the user name is already reserved or taken, the same applies for the email address.
You can let the user enter his email twice by typing to ensure that he didn't enter other email by mistake, how ever, if the user entered his email wrongly twice, then, its his problem!
On the other hand, you won't send the confirmation email for already confirmed users, also for emails that are not stored at your side, you need to put this message in your confirmation emails:
If you are not {First Name + Last Name} then please ignore this email or something similar.
I hope this will help.
You could make it so the user can create an account / sign in with openid/google/facebook/yahoo. That way those sites hand the auth and if they can log in successfully through those you can collect any additional information you need.
You could alternatively have them create an account by first only providing an email. You would email the user with a link where they could continue the registration process if they don't already have an account. If an account is already created you can send an email saying something like: a request was made to create an account using this email address, but an account already exists. If this wasn't you then....
I have a question about security flow of confirmation link.
I have a website on which you have to fill your email address and password after filing these information my app sends an email with a secure link to user email address. After clicking on confirmation email user automatically gets logged inside the application.
Now question :
Is there a security risk to auto login user on clicking of confirmation link ?
Is there and security risk to auto login user on clicking of confirmation link? Yes and no. It depends on what is in the link. What I would do is I would have two field in database activate_code, that is randomly generated and is_activated which is defaulted to 0. Then I will send a link to activation code and another email with activation link. Once at activation link, user will fill code and account will be activated. redirect him to login page.
Do not send user emails or any other information. just send random codes or something similar
That is my cent!
Yes there is a security concern, as Gumbo points out.
Since the user has provided an email & password, why not require he be logged in to access his confirmation page?