Hard coded URI to test app container


The safe_app_nodejs library contains tests that use hard coded URIs:

In my pursuit to test ‘inter-app communication’ (see loginForTest with two apps) I came across these hard coded URIs. I’m unsure how they work or why they would work. Are they authenticated against the MockVault file? Does it only work with a pre-defined binary MockVault? Can it be used to access own containers?

I can login with that URI using loginFromURI and a subsequent call to getOwnContainerName also works, but getOwnContainer does not (-103: Core error: Routing client error -> Requested data not found).

Hope someone from MaidSafe can help me out, thanks!


I’m asking around for you @bzee

Or, in layman’s terms… I don’t know myself and having to get help!



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 :wink:
Let me know if you run into issues. I know @nbaksalyar is also taking a look at the other issue about loginForTest.


Thanks @bochaco. I was thinking about using a pre-setup MockVault as a last resort but it seems reasonable.

Hope you guys are able to make some progress on the the loginForTest issue! Thanks again for all your work!