How to pick up openUrl auth response in a non-electron desktop app?

[happybeing]

The documentation for AuthInterface.openUri() does not explain how to receive the response (no return parameter is indicated). The examples (Tutorial etc) only show how to do this in electron (using electron.app.on('open-url',...)).

So I would like to know how to pick up the auth URI response when I call AuthInterface.openUri() from a non-electron desktop app (not DOM API).

[bzee]

I got into the exact same question myself in my attempt last week to build a non-Electron app.

Inspect the following from my example from https://dev.autonomi.community/t/how-to-handle-system-uri-response-in-the-main-js-process/1679/9:

@bzee

const info = {
    id: 'example', name: 'example', vendor: 'example',
    customExecPath: [process.execPath, __filename],
};

The authenticator will call an executable with the URI as an argument. With customExecPath this executable and the arguments can be configured. If customExecPath is ['C:\main.exe'], then the authenticator will call C:\main.exe <URI response>. It’s then up to the executable to read the URI.

This is also the reason my minimum viable example is a little complex.

In short: The Authenticator spawns an executable with the URI response as an argument.

[happybeing]

Thanks, I have all that (thanks to your help last week) but I still don’t know how to pick up the response in the app.

It may be I need to use the single instance thingy @hunterlester pointed to last week but I’m not sure yet.

UPDATE…

Ah no, hunter’s thing is also an electron function:

const shouldQuit = app.makeSingleInstance((commandLine, workingDirectory) => {
  const uri = commandLine[commandLine.length - 1];
  if (commandLine.length >= 2 && uri) {
    sendResponse(uri);
  }

  // Someone tried to run a second instance, we should focus our window.
  if (mainWindow) {
    if (mainWindow.isMinimized()) mainWindow.restore()
    mainWindow.focus()
  }
})

So I guess I need a similar thing for my app. Going back to your reply above, I’m not seeing my app being called by repeatedly being started again and again, recursively after each openUri() (although I think at one time last week that did happen but I think that was when I was still doing stuff in electron).

So I think that the mechanism you describe there @bzee is not yet calling the executable after a successful auth.

[bzee]

I see.

What you need to understand is that the script will actually be run twice. The first time, when you execute it, and the second time when it’s run by the Authenticator.

My example runs the first time, calling openUri, then closes. The Authenticator then calls the script a second time (with the URI!) and it can continue connecting to the SAFE Network.

Now, this seems inconvenient, as you might want to run a single instance that runs inside of the cmd.exe or whatever that you call it from.

That’s why I started working on another implementation that uses IPC to communicate the URI response back to the first instance. (https://github.com/project-decorum/decorum-lib/blob/safe-ipc-uri/src/Safe.ts)

@happybeing

It may be I need to use the single instance thingy @hunterlester pointed to last week but I’m not sure yet.

Yes, that’s why Electron is very much suited, as it can communicate with the ‘main process’ to pass the URI when it’s called again by the Authenticator, while the first instance just keeps running to wait for that response…

[happybeing]

Thanks Benno, I understand the issues much better now, just not how to solve them. Also, as noted in my update above, I’m not sure my ‘script’ is being called although it might just be that I’m not seeing it as all it does is output to the console. If it is ‘working’ I guess I’ve just spawned an infinitely running chain!

Ok, I see how you are trying to do this via ipc, is that working?

[bzee]

@happybeing

So I think that the mechanism you describe there @bzee is not yet calling the executable after a successful auth.

It might be because it disappears instantly as the script finished without pausing. Try pausing the script:

async function sleep(ms) {
    await new Promise(resolve => setTimeout(resolve, ms))
}

await sleep(50000); // 50s

[happybeing]

I already have that so I will look at the path. Thanks for helping.

Does the ipc code you linked to work?

[happybeing]

Just a note for anyone follwing this topic. @bzee has solved this so expect more from him at some point, and I shall try to create a simple CLI boilerplate which anyone can use to build cross platform CLI apps that authenticate with SAFE Browser (based on JavaScript and nodejs - so very a powerful platform, just like other SAFE Apps).

Later maybe someone will I hope write an authenticator module which extends this ability to headless apps. Any takers?

[hunterlester]

I’m still under the impression that you are using electron, but only utilizing the main process.
Is that incorrect?

Are you building a CLI app in Nodejs without an application framework?

[happybeing]

@hunterlester

Are you building a CLI app in Nodejs without an application framework?

Correct, not using electron, no framework, just SAFE nodejs and decorum-lib (for ipc comms) packaged with pkg.

[happybeing]

UPDATED at end.

@bzee I’ve created a stripped down cli boilerplate which includes just the code I need from @decorum-lib (so no longer dependent on @decorum-lib itself).

In doing so I’ve discovered that while your fix works, we’re not finding the libsafe_app.so in the package, but retrieving it from disk (in ./node_modules) so for now I’ve made this part of my ./dist output.

I’m not sure if your fix was meant to work like this. It is workable but would be better if we could package the dll and get them from the executable. This is supposed to be possible I think, by specifying “assets” for pkg in the package.json but I have not managed to get this to work. Using pkg -d I see lots of stuff being packaged but never the libsafe_app.so no matter what I try, and I see others have had problems with this from pkg github issue #102 which was sorted, but by mods to pkg itself! Others had success with the “assets” setting such as in issue #216 but I’ve tried and can’t seem to get libsafe_app.so to be packaged (at least it never appears in the '-d' output).

I’ve pushed my stuff here in case you want to take a look. I’ll update if I get it working:

GitHub - happybeing/safe-cli-boilerplate: SAFE Network command line application (CLI)...

UPDATE: I now have it being packaged but it is not being picked found when I run the exe. I hadn’t realised you need to include package.json in the pkg command line for it to find the “assets” entries!

[bzee]

@happybeing

In doing so I’ve discovered that while your fix works, we’re not finding the libsafe_app.so in the package, but retrieving it from disk (in ./node_modules ) so for now I’ve made this part of my ./dist output.

Yes, I did this on purpose because I could not get pkg to work on embedding the assets into the executable. Also, I didn’t really want to make a pkg specific solution per se. Perhaps there are other packagers out there, and this seems like a generic solution (loading it from the filesystem).

Your post did encourage me to dive a little deeper into why the executable built by pkg is not able to load the library. I think it has to do with how node-ffi works (which is what safe-node-app uses to load the SAFE library). node-ffi loads the file from disk, with platform specific Dynamic Library functions (LoadLibraryW for Windows).

[happybeing]

The following release of SAFE CLI Boilerplate is a stand alone command line application which includes code which solves the problem presented in the OP, courtesy of @bzee: How to pick up openUrl auth response in a non-electron desktop app?

Release v0.0.1 · happybeing/safe-cli-boilerplate

[Thomashighbaugh]

Thank you, seriously. You found a problem, fixed it and offered it tpo the community. I hope to be at that level asap