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!


This topic was automatically closed after 60 days. New replies are no longer allowed.