One issue we ran into with the old Safe Launcher workflow was the fact that testing our app required user-interaction, and running a GUI. I wanted to know if there are any plans to try to make automatic testing against a native library that has been built against mock routing totally headless. It would be great if there was a way to run tests against a mock version of one of the client libs with travis-ci.
2 Likes
Hey @ethanpailes,
yes, in mocked-routing the safe-app-crate is exposing some extra features, that allow us to run automatic tests with full apps. Those are not available outside of mocked routing though.
2 Likes
That sounds like exactly what I want. What is the right way to get access to this? Right now when I run the examples from safe_app_nodejs it fails with what I think is a missing-authenticator error. I’m building the beaker plugin right now to test for sure, but it would be nice to be able to make requests with a client lib built against mock without touching the authenticator.
Well, it is meant for testing only - examples aren’t tests, those are actual “apps”. They should authenticate against authenticator (actually that’s the main thing those examples show at the moment).
Well, the idea is that apps would store the access token in a secure location and thus can just run independently after an initial sign up. We might provide something like that through nodejs’s keytar later, but that isn’t implemented yet: right now they act as session keys.
Well, it is meant for testing only - examples aren’t tests, those are actual “apps”.
Ok that makes sense. So in order to get the test functionality that I’m looking for I should use the same stuff that createAuthenticatedTestApp uses to just generate a test app. I really should have read your post more fully before replying.
Well, the idea is that apps would store the access token in a secure location and thus can just run independently after an initial sign up.
I really liked the fact that you could just re-request an auth token from the Safe Launcher every time that an app started up. For end users this seems like absolutely the right thing to do because it acts like a builtin password manager for every safe app. I don’t think safe apps should ever really be storing auth tokens in the clear anywhere, and any sort of encryption to store them safely would lead to another set of keys specific to that app. This means more passwords which means reuse of weak passwords, which is a bad thing. My guess would be that the case for re-authing on startup is much weaker for mobile.
Thanks for the help!
If you use nodejs and are running it within mocha, you can import it through something like:
const lib = require('safe-app/native/lib');
lib.test_create_app().then( (app) => ...)
The test helpers aren’t exposed at the moment. Though we could argu about moving those helper (only) over into the package to make that slightly easier.
Please note, that I said secure location. Keytar provides access to the system owned keypass management part. That is fairly secure. One reason, we want to integrate it, is because otherwise apps start storing these tokens insecurely. If we built this in, you’d get both: security and convenience.
2 Likes
The test helpers aren’t exposed at the moment. Though we could argu about moving those helper (only) over into the package to make that slightly easier.
I think that it would be great if they were eventually exposed. For now hacks will suffice to get the functionality. Thanks!
Installing the keys into a system keychain does seem like a solid UX improvement. It’s good that the endorsed policy is not to store tokens in the clear.
1 Like