The function authorises and connects a retrieved appToken and stores it in a global variable in order to use it at a later point. So far this works as intended. However, when I reload the page (e.g. because I made code changes) and call this method again first the authenticator opens the auth popup, I click accept and then after a few seconds I get the following error:
Unexpected (probably a logic error): Could not connect to the SAFE Network
at onCbReply (C:\Users\Mindphreaker\safe-browser\resources\app\node_modules\pauls-electron-rpc\lib\import-api.js:203:19)
at EventEmitter.onIPCMessage (C:\Users\Mindphreaker\safe-browser\resources\app\node_modules\pauls-electron-rpc\lib\import-api.js:118:14)
at emitMany (events.js:127:13)
at EventEmitter.emit (events.js:201:7)onCbReply @ C:\Users\Mindphreaker\safe-browser\re…:203onIPCMessage @ C:\Users\Mindphreaker\safe-browser\re…:118emitMany @ events.js:127emit @ events.js:201
The main question is, the app itself is already authorised, but I don’t know how I can reload the page without loosing the authorised appToken. I read somewhere that it’s recommended / allowed to store the authURL in a secure way, but again, where should I store this (securely) in a web app?
My preferred outcome would be to reload the page and continue interacting with the network (e.g. retrieve data) without having to re-authorise. Is this currently even possible? Can someone point me in the right direction here?
Side question: If the obove is not possible, how do I retrieve a new appToken from an already authorised app correctly?
Thanks @daniel, because of JS I didn’t even think about using the session. ^^ Local storage seems also a good approach!
But what happens if the user decides to delete the cookie, cache etc. This would leave me currently with the same error.
Could someone verify if the above approach is even correct? If not, how can we request an authorised token from an app which has already been authorised in the past?
You just need to execute the same functions, if you still have an initialised safeApp instance, then just call window.safeApp.authorise(appToken, access) again.
Okay, then I think it has to be a bug. As stated above, I have this simple auth() method which calls initialise, authorise and connectAuthorised. On a fresh attempt (no previous attempts) it works. If I try to call the same method again it fails which - if I read your answer correctly - should not be the case!
I’m starting to think it could have something to do with the new rate limiter or some other spam prevention maybe?
After many attempts I have tried calling each api function from the above auth() method individually and documented the following error which occures in the connectAuthorised function:
BTW: This was absolutely reproduceable, but now I get a low balance error when calling connectAuthorised (why does this touch the balance?), so can’t test it any further.
I’m getting the same error when I try to use connectAuthorised() directly after authorise() initialise() with an authURI I stored previously. Then if I try to do another API call the browser will crash.
The error you were seeing is due to the limit in the number of clients, please look at this explanation here.
I wouldn’t expect this either, but we’ll have to research about this to try to reproduce it. Were you just uploading files with the web hosting app until you ran out of PUTs/credit?
Thanks for pointing this out. I might add that I not only would expect the browser too free ressources on tab closing, but also on hitting F5 / refresh.
Also: The fact, that even after freeing ressources it needs some time to do so (in combination with such a strict client limit) makes it really hard to work with atm. For example, even after restarting the browser I sometimes got this error.
Maybe you can discuss this internally if the limit can be loosened a bit or if there is another way to prevent such issues.
Basically, I just tested the auth() method above extensively. For this reason I uploaded many versions of a simple index.html file through webhosting manager. I think the uploads exhausted the limit, but strange that connectAuthorised() triggers the limit error.
The browser has a main process, and the renderer processes (one per page).
The safe-app plugin runs in the main process but the API is exposed to the renderer processes, so when you call one of the DOM API functions, the renderer is actually sending an IPC message to the main process, and the objects are actually created/instantiated in the main process by the plugin when it invokes the underlying safe_app_nodejs functions, that’s why you receive handles to reference these objects.
So, the page/app has to actually let the plugin know when they can be freed by calling free functions.
So as always, it’s expected that the app will free the resources, but we know that won’t be always the case, so we are trying to have the browser to automatically free the resources used by a page when it gets closed (or refreshed as suggested by @Mindphreaker).
Make sense, it does sound like the proper way of doing it. It’s not practical to call free since the safeApi will be used constantly by the web page, so you never know when you don’t need it anymore. You could call initialize and free on each call but that would be tedious.
@Mindphreaker Following up with more information about low balance issue.
What’s expected, and confirmed, is that tokens are needed to initially register an application that has been authorised, in order to create and configure it’s access container. However, upon subsequently connecting an app that has already been authorised and registered, it will not cost tokens.
)