Hacker News Reader

Comment by mritchie712 | Hacker News Reader

How do you handle logging in to the app that needs to be tested? We use Google OAuth.

We fully support e-mail based logins, but OAuth can be challenging.

Github OAuth for example will issue a 2FA email-based challenge non-deterministically. We handle that by detecting the challenge and filling out the challenge code based on the contents of the email sent by Github. This requires a one-time setup where you add an email address we control to your Github user so that we can read and parse it.

For Google OAuth we can execute all the steps but the two issues there are (1) we run everything in a single window and some web apps don't like that because they assume the oauth flow will happen in a new window, and (2) sometimes Google prompts you to answer a security question and we don't yet support marking test steps as optional.

What our customers have been doing instead is setting up a mechanism to auto-log in the test user using a magic link. Basically sending in a one-time-use auth code to a URL in their app that then authenticate the user. I think some platforms (Firebase?) have built-in support for this.

I'm certainly happy to brainstorm what could work best for you though if you'd like (my email: todd at reflect.run)

I'm using Hardware keys to secure my personal accounts. What are the alternative auth methods suggested for this situation?

I would suggest adding the ability to auth via a magic-link in your web app. This would allow your tests to bypass the auth flow entirely by passing an auth token as a request parameter in the first URL of your test. You can pass new auth tokens when you go to run your tests either via the UI or via our API if you have it hooked up to your CI/CD pipeline. More docs on how to do it via the API is here - we call these 'request overrides' in our docs: https://reflect.run/docs/developer-api/documentation/#run-te....

In terms of added security, some options there would be to only enable these "magic links" in staging and only enable this type of auth for a least-privledged user account (e.g. no admin or employee accounts could auth this way).

Magic links sound like they have several pitfalls (the potential for security incidents like Twitter are beeping here) and require significant changes on our end to use this platform

You're right, there's certainly security implications for magic links. Unfortunately for an auth that incorporates hardware keys, I can't think of how you would test behind that without some sort of workaround, but I may be overlooking something.

I generally have service accounts specific for testing with significant restrictions. Hardware keys present their own complications for non-human ops, so they don't really belong there.

More just seeking bounds of possibilities, thanks for your replies.

I asked this elsewhere in the thread to a different user, but it seems relevant here as well:

Curious how your service would handle a app that mandates non-email based MFA like SMS or TOTP.

Additionally, what about testing a onboarding flow that might require some form of manual approval?

Thanks!

We have the ability to handle MFA logins that use email as the second factor. The way it works is you configure your user account to have an email address that we control (e.g. foo@account-randomchars.email.reflect.run). When the multi-factor challenge comes in, we receive the email, parse it for the challenge code, and fill it in live in your test. We don't have SMS support at the moment but we could take a similar approach there if SMS is used as a second factor. There's a one-time setup here where we set up our system to parse your challenge email.

No support for TOTP unfortunately, but if the SMS or email-based challenge support would work for you feel free to reach out and I can talk to the specifics of the one-time setup - todd at reflect dot run

Ungh Google OAuth is kind of frustrating - the major reason is that websites are pretty good at blocking pages that are coming from automation - and you get all sorts of issues and problems (not to mention if a company like Google (not the real example) uses you to test their platform and then SafeSearch picks up their staging login as a phishing site and blocks you ^_^).

I warmly recommend _not_ testing Google OAuth and instead passing a token and bypassing it on your server's side.

The way automation can work around it (in Testim.io for example) is "mock network" which is supported in our codeless solution but also available in most test infrastructure (like Playwright which is FOSS). You would mock out the parts that leave the user with a token they can use to authenticate.

Reply on news.ycombinator.com