To build my own Electron app that uses the SAFE Network, I studied an example app that is linked to from the ‘How to develop for the SAFE Network’ post on this forum. It took me a few hours of playing around with it to realise that the example does not work fully on macOS. @hunterlester’s https://github.com/hunterlester/safe-app-base is a fantastically simple app that I am sure is beneficial to many beginners.
I have been in communication with him trying to solve the issue but we haven’t made much progress. The issue is that the app never receives the auth-responseipc message back from the SAFE Browser. The result of this is that you won’t see a print to the console for the mutableData.newRandomPublic(15001) that is created. I tested the app on Windows last night and it worked straight away, so I am confident this is a macOS only quirk. The app can successfully communicate with the SAFE Browser and register itself on that end (it shows on the Authenticator page) but it is the ipc message back to the app that doesn’t work.
So far I have built the app under numerous versions of Node to see if that was the issue, I tested it on everything from Node 7.9.0 to the very latest version and I still had the same issue. @hunterlester suggested it may be something to do with the macOS equivalent of how Windows registers applications through Registry Editor. I delved into this a little and discovered that the application was not generating files in (~/Library/Preferences) like the Maidsafe sample apps do. I tried to improve the package.json to include proper configuration for electronPackager to see if this fixed the issue, but alas it did not. It is worth noting too that I am building this with NODE_ENV=dev for mock routing support. I am using the latest version of macOS and the latest pre-built mock SAFE Browser 0.8.0
Is there anyone that could lend a hand to figure this issue out? If we cannot get this sorted then the only logical thing to do would be to mark the app as Windows/Linux only until a time when we can solve the issue.
Hi @DaBrown95, from what I get it sound to me that the issue is with the URI scheme registered for the app, so your app is able to trigger the authorisation popup by opening a safe-auth URI since the browser is correctly registering it on the system, but your app may not be registering its own safe- URI correctly and that’s why the response is not reaching your app (note this is not IPC messages though, it’s just launching apps based on the URI scheme registers on the system).
One thing to consider is if you are running your app as a packaged electron app executable or using electron command instead, since that implies that you need the Exec path for the URI scheme registered to be different, we handle this in the safe-app plugin by providing the customExecPath attribute in the appInfo: https://github.com/maidsafe/beaker-plugin-safe-app/blob/master/src/protocol.js#L25
Another thing to consider is that perhaps what you are missing is the bundle attribute in your appInfo, look how we provide that from the safe-app plugin here: https://github.com/maidsafe/beaker-plugin-safe-app/blob/master/src/protocol.js#L28-L31
I’m not a OS X expert but we did have issues when the bundle was not set in OS X as that seems to be what it uses to map the URI scheme to the app that has to be launched.
I hope this helps a bit, please give it a try to both things and let us know.
I also tried again to set the electronPackager config but alas this didn’t solve the issue. At least we now have it working through the electron command which is good. Any other suggestions with how to solve this for the packaged version?
Glad to hear that @DaBrown95!
I’m not that familiar to how you can verify the URI registered and the exec path registered for each URI on OSX, perhaps @joshuef can help us with this, but I would first confirm what’s the exec path registered for your app’s safe- URI, and then try to manually launch it from a shell console with open <exec path>. You should get an error there if there is anything wrong with the exec path being registered, and if so, you can then make sure the customExecPath value you are providing in the appInfo is what it should be. If the app is otherwise launched upon executing that command from the shell console then it’s likely to be related to the URI or perhaps again the bundle Id, in such a case again @joshuef could help us I believe.
By using the RCDefaultApp that was suggested, I can view all the registered URL’s on the system. URL’s for web hosting manager and email client exist, along with the ‘safe-auth’ URL for the SAFE Browser. But nothing is there for this example app… It’s almost as if it fails to register the URL when running packaged.
I had a look, the Info.plist must be automatically created for you. I compared it directly with the Maidsafe example apps but couldn’t find a discernable difference. I really don’t understand how the sample Maidsafe apps can work when compared to this example app! Very strange.
Think I/we need a fresh set of eyes on this one, it is probably a very simple fix but after hours of investigation I am no closer to solving it.
Wow, thank you! By pointing me too that link I went on a tangent that fixed the issue… So I am guessing there is some subtle differences to the way that electron-builder works when compared to electron-packager. So the ‘email app’ uses electron-packager as compared to the ‘web hosting manager’ which uses electron-builder. What I noticed in the package.json for the electron-packager powered app is that it sets "appBundleId". I tried this with @hunterlester’s example app (electron-packager) and bingo, it worked! So the application can now successfully work on macOS through either yarn start or when packaged.
The web hosting manager that uses electron-builder uses an "appId" in the build section of the package.json. Although I haven’t tested/researched this, I am going to make the assumption that this is analogous to the "appBundleId" that electron-packager has. Just adding this here so anyone looking at this thread in the future might gain a little insight into an issue they are having.
Big thank you to everyone that has helped here.
@hunterlester I have created a pull request that brings in the fix. Very minor but it might be worth other people testing it or at least verifying that the changes don’t break Windows/Linux environments.
