4 ms·
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 to
by tmcneal 6y ago
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-tests-associated-with-a-tag 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).
- verdverm 6y agoMagic 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
- tmcneal 6y agoYou'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.
- verdverm 6y agoI 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.