Hey @bzee, you wouldn’t be able to do much more than what you already found out with those hard-coded auth URI’s, as you can see in our tests we use them just to test the decoding and log-in functionality, but for storing/reading data we use the
loginForTest. We have a task in our backlog to allow such a thing to be able to authorise apps in the mock when in dev mode, thru some utility function/s exposed by safe_app_nodejs, we’ll see if we can prioritise that task depending on how other things we are working on evolve.
In the meantime you can do the following:
1- run the browser with mock
2- create an account and log in
3- run your app and make it send and receive the auth request/response to the authenticator
4- make sure you log the auth URI you get from the browser in the response and copy it
5- use that auth URI, with that mock file, from your app to log-in (with
loginFromUri) to the mock and you should be able to store data, assuming you requested the right permissions for it, without the need of the browser/authenticator anymore.
I’d recommend you make a backup of the mock file as I’m aware of some cases where it can get corrupted (there is a bug reported for it and client libs team is already looking at it), in such a case you can copy it over and keep using the same auth URI.
Steps 1 to 4 from above are what we exactly do to generate the ones that are hard-coded in the tests
Let me know if you run into issues. I know @nbaksalyar is also taking a look at the other issue about