Until yesterday I was using the default mechanism of sending mails like "verify mail" or "forgot password mail". These mails have specials tokens included inside the mail. Both of these endpoint also returns tokens in the response body.
I am now changing the way of sending mails in my application and I want to do it with a separate service. So to activate my users or change their password I need these tokens, but I dont want FusionAuth to send emails. When disabling "verify mails" or "forgot password", calling these endpoints results in a 403. Is there a way to get this tokens without starting the process of sending a mail by FusionAuth ?
The workaround is to add a fake host to the mail config. But it isn't the best idea since I see then an error in logs when generating tokens.
You can use the /api/user/forgot-password API and set sendForgotPasswordEmail to false.
In the Forgot Password API it is the second example :
Start the forgot password workflow using an API key
This will create you a token and will not send the email. You can then build the link yourself and send the email through an external service.
Related
So i try smtplib to send gmail automatically, however it fail because of a error, after some checking, my username and pass are True. So i want to ask if there were any mistakes that can lead to this error.
Here is my code, the port is 465 and i don't want anyone know my pass and my username.
The error message "username and password not accepted" is the standard error message you get from the smtp server when sending the users actual google password.
This method of authentication is not acceptable by the SMTP server after (May 30, 2022). Partially due to the removal of Less secure apps & your Google Account mostly because client login is not considered to be secure.
Your options are to to enable 2fa on our google account and use and create an apps password. Simply use it in place of the password in your code.
smtp.login(username, appsPasswrod)
Or to use XOauth2 and authenticate the application.
Create a sendEmail() function, which will help to send emails to one or more than one recipient by calling the function.
def sendEmail(to, content):
server = smtplib.SMTP('smtp.gmail.com', 587)
server.ehlo()
server.starttls()
server.login('youremail#gmail.com', 'your-password')
server.sendmail('youremail#gmail.com', to, content)
server.close()
content = "Message to send"
to = "useremail#gmail.com"
sendEmail(to, content)
NOTE: Do not forget to make sure that the smtplib requires 'enable the less secure apps' feature in your Gmail account. Otherwise, the sendEmail function will not work properly..
Create App Password: App Passwords
I'm sure I am missing something here but...
I have an angular application that allows users to fill out forms. The application calls a backend NODEJS service that has a responsibility of building the HTML envelope and document to sign. This back-end service does not have access to a browser.
I have 2 options for flow:
User fills out form -> clicks sign button -> back-end service called to gather the url for the user to redirect to in order to get a code back (consent) -> USER DOES NOT LOGIN TO DOCUSIGN -> redirect back to application -> get token with users code -> prepare envelope on BEHALF of the user -> send application the ceremony URL -> user redirects to ceremony -> signs document -> redirect back to application.
*User fills out form -> clicks sign button -> back-end service called to create envelope and tell DOCUSIGN to send an EMAIL to the user which I don't want to sign up for DOCUSIGN. (Effectively removing the need for them to create an account with DOCUSIGN because I am sending an email and they can authenticate him by knowing he is coming from his own email). -> user signs document through email -> (Would be nice for application to get redirected back to but not necessary)
All examples and chats I have seen discuss only having to login one time. Well in flow 1, I don't want the USER, signing the document, to login or have to make an account for this one signing. And in flow 2, I can't seem to grasp how to keep the back-end service authenticated if it is a BACK-END service. It's headless. No Browser.
These guys are so large that I figure it's something I'm not grasping here.
I understand to impersonate the user, I would need his consent. And possibly... because they don't KNOW the user without him signing up for an account to verify his email, they can't offer consent to a user they can't verify email with. So if that is the case, I would want to authenticate my BACK-END user to send emails so they can just click the email, it MIGHT verify in DOCUSIGN without having to sign up for account, and offer the contract to the user to sign on the spot from the email WITHOUT asking for credentials or NEW account.
If you are going to answer this with a link back to DOCUSIGN authentication examples. Or suggest use a JWT to authenticate from BACK-END services... please explain in detail the steps to authenticate my BACK-END user and keep him authenticated without using a web-browser or how to use the users consent from a redirect from DOCUSIGN without the user having to EVER create an account.
I have tried sending the user to the redirect URL with success if they already have their credentials cached in browser or already have a DOCUSIGN user. The flow works fine there. I get the users code, exchange it for token, create envelope, redirect user to ceremony, redirect back to application after signing complete.
I have read a bunch of articles that all point back to DOCUSIGN help with authenticating 1 of 3 ways with a browser. I need no browser login, or a better understanding of how to avoid the user creating a DOCUSIGN account.
Thank you so much!
Signer, user that signs, does NOT need to have a DocuSign account. They do not need to log in to DocuSign in order to sign. They can sign via email or embedded in your app, but they do NOT need to have an account or log in.
Your app's back end needs an access token to make API calls. This doesn't change the headless nature or the fact that it's back end. A token is a long string that your app uses to authenticate. This authentication is tied to a user in DocuSign that has an account. That is NOT the user that signs, but the user that make the API call. You have to have a user that makes an API call.
You can get a token using JWT authentication and your back end can generate it using the Node.js SDK (npm package) without the need for UI or for anyone to log in.
My goal is to somehow send the email and click the link to reset the password, access that link and write a new password. Don't really know if this is possible or could only be mocked.
I would also like to catch the content of the email and check it. Is there a way within TestCafe to do this?
You can use TestCafe to fill out and submit the password recovery form that will initiate a request to your backend. After that, you can use either of the following solutions:
Intercept this request to the backend using TestCafe features for Intercepting HTTP Requests. Then, make sure that the "an email with a retrieval link was sent" message was shown, navigate to the known in advance retrieval link and log in with a new password.
Make this request to the backend actually initiate sending an email. Then, in your test, connect to an email service (using some of the Node.js email clients), receive the email, and navigate TestCafe to the link.
The first approach seems to be more robust because it doesn't rely on any third-party services.
The problem I have is that I need to test if user verification is working. We generate a verification token, and an email is sent to the user. Whenever the user clicks on it, it checks if the verification token has expired. I've tried mocking this, but it just won't work. We have an endpoint to verify a user, but we still need the verification token, which is not available on any endpoint.
I think this article may help you: https://www.testingexcellence.com/automated-api-testing-emails-karate/
To summarize:
use the API at http://qamail.ala.se/ to create a test mailbox
initiate the flow that sends the e-mail
use the API to "read" the e-mail and grab the token
EDIT: looks like the link is dead. but you should be able to find similar offerings on the internet. since the source-code seems to be available, it may make sense for you to host this e-mail server somewhere so that it can receive e-mail from whichever system is the sender
Background
We are integrating third party email solution into our site. When a user goes to the Mail page it must be automatically authenticated at the Mail site.
For now, the Mail link points to our page which automatically submits a form with the user's login and password. After clicking submit the user is redirected to the Mail site with authentication cookie.
The problem with this approach is that we do not want the user to see his Mail password, because we generate it automatically for him and there are some sane reasons not to show it.
Question
Is there any way to receive mail authentication cookies without sending the login information to the client and performing form.submit operation from the client's browser? Is there a better way to do what I'm trying to do?
Edit
Of course "I am trying to do it programatically". Looks like that there are no sane solution except pass these login/password to the client. Looks like we must accept that user can see his mail password and somehow make sure he cannot use this information to change password to some other value we will not know.
Edit: I didn't read the post correctly, I thought he was trying to login to a remote mail application, not one hosted on his own server. Ignore this answer.
When you login to the remote third party mail website, they will create a cookie (since HTTP is stateless, it's the only way it knows the user is authenticated unless they store some kind of session ID in the url). When you send the user to that site, the site needs to know how to authenticate the user. Even if you logged in from your application and grabbed the cookie, you can set a cookie on the users browser for another website. The only way for this to work is if there is some kind of development API on the third parties website you can hook into, or they allow you to use session id's in the URL.
Possible solution but has a security risk
If they allow you to set a session_id in the URL (for instance, PHPSESSID in PHP) then you could grab the session ID and append it to the URL when sending it to the user. I don't really like this idea since if the user clicks on a link in an e-mail, the new page will be able to check the referrer and see their session ID in the URL. This can become a huge security risk.
Lookup topics related to your mail vendor and "Pass-through Authentication." You did not mention what vendor/software you are using for your web mail solution, so I can't help you very much there. Other than forwarding the user's information (in a post request) to the login handler.
Generate unique IDs before sending an email and put them as hidden instead of username/password into form. Make them disposable (usable only once or usable once before successful entering the site)