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
Related
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.
I have a fully functional Keycloak setup with verify email and then update password features enabled. I have tested multiple times and the mail sending part is working perfectly. But some clients reporting that they didn't receive the registration mail. This maybe due to their firewall, spam filter and so on, now I want way to check whether the email has sent from my system or not. Logs won't help at all, cannot find anything related to sent mails in logs.
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.
The Google+ Sign-In button bears a striking similarity to the Facebook Login API, and I like that.
The Facebook JS SDK has a signed_request parameter that's provided on the client side but which can be passed to my server, verifying that client-side authentication has taken place. It's cryptographically signed by Facebook, which allows me to verify that the client is logged in without talking to the Facebook on the server side.
Is there a way to do something similar with the G+ JS API? Specifically, I want to do client-side authentication, then POST some data to my server and verify that the client really is logged in to Google, without initiating a server-side request to Google.
(I want this because I only want to use the sign in button as a registration mechanism; I don't want to post to Google Plus or get the user's list of friends or anything like that, which would normally require a full access token.)
Google+ does not make requests to your application on the user's behalf at this time, outside of a callback URL set as part of a vanilla OAuth 2.0 flow.
When receiving a new token or authorization code, you should make the tokeninfo request server-side in order to verify that the token you've received is legitimate, and for the intended user.
I'm not sure which platform your server is using, so I can't paste the relevant code, but please see here for a code sample.
So, actually there is a pretty good match for that parameter, the id_token that is returned along with the access_token. It's a signed json web token that includes a userid, the client ID and so on. It sounds like this would address your use case! Take a look at http://android-developers.blogspot.nl/2013/01/verifying-back-end-calls-from-android.html this blog post by Tim Bray - it's Android focused, but the same logic pretty much works for any client.
Once you get this, you know its valid at the point of delivery, just liked a signed_request. Of course in either case if the user signs out or revokes access to your app the access token may no longer be valid for making calls.
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)