Catching Auth response from Safe authenticatior.

I am using Electron -react boiler plate for client side.
I am simply sending Auth request from client side
using this function

const safeApp = await initialiseApp(appInfo, null, opts);    
const authUri = await safeApp.auth.genAuthUri({ });
await safeApp.auth.openUri(authUri);

then Safe authenticator sending me an response
Which I have to use in below function

await safeApp.auth.loginFromUri(???);```
How Do I catch that response??

Hey @Avirup, you can use as reference. It helps you to understand the authentication process. Or you can check safe_app_electron_quick_start example.

1 Like

side thought

you (@maidsafe) know all the sysuri stuff and how to get the authenticator information back into a running program …

we [the api-user/developer] communicate with the API though asynchronous callbacks all the time anyway - normally the answer is there pretty fast - but it doesn’t mean we cannot wait for some seconds or minute for the callback to happen… … why doesn’t the api just do the sysuri-magic and catching the authentication-answer in the background and returns it through a callback right into the user code …? just like all the other api functions do it …? [or is this not possible for some reason …?]

(instead of forcing all the world to learn about sysuris and how to use them and how to integrate them into their programs oO)

this was a hurdle for getting my python poc running too … (or am i mixing stuff here now because i’m talking about the c api …? … but still … if it’s not in the c api it is not available for third party developers in new languages …)

1 Like

Has Anyone tried safe browser authentication.Using React electron boilerplate ??

@Avirup I’ve replied in the other thread you started on this topic.

Actually, the safe client libs can and will do the registering of this for you automatically. So that part is taken care of.

It really depends on the platform / language / where hooks are coming from. So theoretically, it could be possible to make a package to use in electron, for example, to fire an event or hook to be caught. But there’s no simple way to do this across languages/frameworks etc.

I understand it’s still a pain though. And we are actively looking into other IPC methods. (You will soon, for example, be able spawn a call to auth_cli and simply read its response directly in your program.)


The auth_cli will also be providing the option of running a web server to easily query for auth calls etc.


That’s a good point @riddim, the question is where to place this functionality as I think you realise, plus when and who will do it.

Wrapping this up and simplifying auth can be done in a library, but I suspect hard to do outside the particular client side implementations. So you might need a library for each language/client type.

We do currently have this for JavaScript, but not yet for other languages. For JavaScript we have:

Safenetworkjs achieves this with a core of common code (courtesy of @bzee) which does the auth, plus different ways to build for Web or desktop. But for the programmer the API is the same, with some simple authorisation functions. So very easy to use.

This model can probably be extended so that the same Safenetworkjs client API can also support the new headless authorisation methods (ie not via SAFE Browser). At least I hope so, but have not looked into that.

Wrapping this up in a language specific library simplifies development by providing a common API for each language, not just for auth but also other simplifications and common application functions. Creating public names, uploading and managing files for example, which are all quite tricky to do using the SAFE API.

It is though a lot of work to provide this (because it is tricky!), because I think for now at least it needs to be done for each client language/platform, and so is not going to be a priority for Maidsafe for a while at least.

So I think it is up to us! :slight_smile: I hope that others will develop similar helper libraries as they master the SAFE APIs, making it easier for those who come after (as well as for themselves - having created Safenetworkjs I will find it much easier to new build applications myself too).

I know Maidsafe do have plans to simplify the developer experience, so I’ve no doubt even better options will come but it will take time because there are many things they could do, and many languages and platforms to support.

It is also possible that Maidsafe will tackle this area (cross language /platform auth) on its own, because you are right that it is a big stumbling block.

I think though that for now they have so much to do that making things possible is the priority for the time being, rather than making things easy.

1 Like

The “regular authenticator” too? The lib itself could use this Web server then…?

Sure - I see there are many issues (it’s not like it would be easy even with python… Pipes are not used in a platform agnostic way… Then a local rpc server sounds like a plan and writing a temporary response script - but then again temp files have different properties on Linux/windows… And how do we get rid of the no longer needed file in case no response is sent by the authenticator without tempfiles? When do we decide that no response will come anymore?) - but as you might see even with a very capable programing language like python it’s not like the solution would be super simple… So one solution per client type would still be better than one solution per safe program imo :roll_eyes:

One option is to use Safenetworkjs which is independent of the framework, and can be used for desktop (eg electron) or Web. But whether you want to build on the Safenetworkjs API or not is something you’d need to think about.

Or you could also extract the relevant code from Safenetworkjs (see src/bootstrap.js) as auth is fairly well isolated. It might even be a good idea to produce a very cut down library ‘Safeauthjs’ to do just that, but I’m too busy to do that myself.

I’m not sure what you’re asking here, can you clarify a bit please.

With auth_cli you were referring to the command line authenticator and not the one in the browser - weren’t you…?

Because I do understand that the whole authenticator concept is needed for mobile but I don’t understand why we wouldn’t expose a simple launcher scheme with local server interface with the browser for desktop applications …?

Well… Sure - all within limits… If everything is possible but you need to invest weeks to get started the bird will look ugly and never fly… If you make it easy for people to fall in love with the project but some pieces are missing they might want to help to add those pieces …

Indeed. The CLI authenticator project.

This is what I’m suggesting exists at the moment:

Only different being it’s not tied to the browser.

1 Like

Agreed, and that’s why I try to fill in where Maidsafe don’t have time, by offering help on here, building stuff to learn and show, and creating projects that help people use and develop.

We can’t have everything at once so each of us must prioritise. We can debate priorities of course - that’s what we’re doing no!? :slight_smile:

I know what you’ve had to go through is hard and a big barrier for everyone who wants to build because I had to do it too. Not just the SAFE API, but the whole JavaScript ecosystem was new to me. I was lucky I had the time… and that the project has taken so long :rofl:

All along the way I’ve looked at where I was and tried to figure out the most productive thing I could be doing to help the project. To start it was mostly learning, and discussing, then researching what to build and how, followed by porting simple Web apps created by others, then starting on a library, then more learning and trying to integrate with Solid, and eventually creating my first thing from scratch (SAFE Drive).

All of this is hard. But I like that because I get bored doing stuff I know too much about, so again I’m lucky that I have the time and enjoy the learning.

Most people have much less time and so I do get it, that more people could do more stuff if it was easier and quicker. So I hear you and am always trying to help people with that, at the same time as trying to encourage and share.

The hard work you’ve done is incredibly valuable - not wasted - and can help others. I think you can see this already, I certainly can.

So I hope you and others are not discouraged by things being hard, but realise there’s extra value created by those like you who can do some of the hard stuff, and make it easier for, and give help to those who follow. :+1:

1 Like

I cannot get any response uri from safe browser after authentication…

My problem is still there…

1 Like

In the docs it is stated there…

const asyncFn = async () => {
  try {
    const app = await safe.initialiseApp(appInfo);
    const authReqUri = await app.auth.genAuthUri(containerPermissions);
    await app.auth.openUri(authReqUri);
    // After URI is opened by SAFE Authenticator and authorised,
    // this snippet assumes that your application has an
    // IPC strategy to receive returned authorisation uri.
    await app.auth.loginFromUri(authUri);

Can anyone tell me how to create ipc strategy??

Sorry @Avirup for highjacking your topic

I guess the best way for you would be

Since you are using JS aren’t you?

If you want to do your own implementation I would advise you to research system uris and have a look at

You need to open the link safe-authenticator://encodedAuthenticationRequest or so to initiate the authentication process and the authenticator then opens a link for your app where it puts the answer as argument

How to implement this in Electron ipc??

Hi @Avirup, have you taken a look at what @ravinderjangra suggested?

If you look at that tutorial and look at the boilerplate code we use there you will see how an auth reponse is received from an electron app:

If you are creating an electron aplication you’ll need to do the same as we do in that boilerplate.

EDIT: I see there is also another thread where you’ve been helped out, so we can continue on that one.

We tried few other methods we could find. Now we are using Peruse browser to authenticate our app. Our authorization request as follows…

async requestAuth() {
    try {
      const safeApp = await initialiseApp(this.appInfo, null, this.opts);
      const authUri = await safeApp.auth.genAuthUri(
      console.log('Auth URI generated: ', authUri);
      await safeApp.auth.openUri(authUri);
    } catch (err) {
      throw err;

This is called from our actions

And we try to get IPC message on our index.js

We have been trying to pass this initial authorization step for past few weeks and failing. Kindly have a look into our source code. Any help is appreciated.

@joshuef @happybeing @bochaco