Container Access - any recent DOM API changes?

[happybeing]

I’m using some old code which used to work fine. I’ve modified it quite a bit but can’t see how I might have broken this! So I wonder if I’ve missed a change to the DOM API in this area.

I’ve successfully called window.safeApp ... initialise() ... authorise() and connectAuthorised(), but when I do the following with what looks like a good appHandle, I get (r) is false. I wondered if the canAccessContainer() API had changed but the docs show it hasn’t.

return window.safeApp.canAccessContainer(appHandle, '_public', ['Read']).then(r => {
	if (r){
		...

I tried this in both peruse (a custom build) and SAFE Browser 0.7.0 with the same result.

The code is live at safe://solidpoc5 (inside js/solid-safenetwork.js).

[Joseph_Meagher]

I don’t think the API has been changed. Trying the code window.safeApp.canAccessContainer(appHandle, '_public', ['Read']) works perfectly in the API Playground and returns true after connectAuthorised. If your code returns false then I would think there would be an issue with timing because if the appHandle was null it would return an error not false so it might be checking whether it has access before it is fully authorised, maybe you could try renaming and passing on the response of connectAuthorised and see whether getMdHandle() is able to access that variable or maybe set a timeout function or else have the appHandle as a global var and try testing out in the console.

[happybeing]

Thanks Joseph, much appreciated.

I’m not sure this would explain it or not. I have console output showing the appHandle, and I’ve also stepped through the code on the way and compared that with what is being used, but I will look into your suggestion.

It does seem plausible though, given the symptoms, so thanks

[happybeing]

I’m going to raise this as an issue, possible bug because I can’t make sense of the behaviour.

If I break at the if (r) I see r is ` false.

If I do the following in the console at that point:

window.safeApp.canAccessContainer(appHandle, '_public', ['Read'])

…then examine the Promise, it is always resolved to false, which I think means it is not a timing issue. Given it doesn’t generate an error I don’t think it should ever return false for those parameters. So either it’s a bug in not generating an error, or I’m falling over some other bug. Unless… stupid

See github Issue #119

[bochaco]

Hi @happybeing, I think what could be happening is that you are re-authorising your app, i.e. your app has been previously authorised with a set of permissions (presumably without Read permissions) and now you are re-authorising it with a set of permissions which does include the Read permission?
Can you please confirm this is the case, and if it is, can you please try by first revoking the app and then authorising the app again and verify the access granted?

EDIT: When you authorise an app, the Authenticator generates the encryption keys for the app and it stores all this data on the network along with the list of containers permissions details, based on that, the authorisation URI is then constructed and it contains all this information for the app to be able to connect and access the data.
If the app is then being re-authorised, this set of encryption keys and related access information is not re-generated but just retrieved from the network and provided back to the application.
This is why we expose two different type of authorisation pop-ups on the Authenticator UI in the browser, when the app is authorised for the first time, you get the list of permissions being requested in the authorisation pop-up, but when the app is being re-authorised, the Authenticator’s pop-up shows only the following message (i.e. there is no details of the permissions granted)
This app is one that you have previously authorised. Please note it is not requesting any new permissions, it requires re-authorisation as it is starting a new SAFE Network session.

[drehb]

@bochaco

If the app is then being re-authorised, this set of encryption keys and related access information is not re-generated but just retrieved from the network and provided back to the application

This bit me when I did a safe:// site too. I would have expected it to pop up a new authorization prompt if my site was requesting something that it didn’t have permission for previously.

[happybeing]

Dang it. I thought you were onto something @bochaco but I just ran peruse, revoked the app and re-auth’d it. No change

Oh wait, no - I didn’t change the original auth perms…

THAT’S IT! Thank you Gabriel.

That’s a sneaky one indeed @drehb. It’ll catch a lot of people out so I think the browser should indeed handle it differently. If not I will no doubt forget and end up here again!

[drehb]

An analogous situation is upgrading an app on your Android; if the app requires new permissions, the Play Store will prompt you to allow them before proceeding with the update.

[bochaco]

What you are describing @drehb was exactly what triggered some internal discussions when we came up with the authorisations pop-ups we currently have as we reviewed different types of flows and scenarios, so it seems we are on the same track. I’ll try to summarise some of the reasoning behind this.

We thought that having the same type of popup could be problematic since the user might not notice that the app is being re-authorised with a different set of permissions so we came up with the second type of pop-up I mentioned before, and I think we all agree on this.

Also, one important thing to consider is that authorising an app with a new/different set of permissions implies to automatically revoke the previous set of permissions to then create a new set of permissions (encryption keys etc.), which in turn might imply re-encrypting some data to be able to enforce the new set of permissions (I’m not sure if it’s only when the new permissions are more restrictive, or simply always).

Then, you have the case you mentioned of an app being upgraded, so a new set of permissions may be required in such a case, but not always. What the app is expected to do is to send a second request with window.safeApp.authoriseContainer as soon as the app realises the set of permissions granted is not enough, and at this point the app can decide to still work and disable some new features, kinda fallback-ing to previous version’s set of functionalities.
It can otherwise decide to just stop working since it now requires the new set of permissions to be granted, or perhaps explain this to the user and perform a new authorisation attempt (again with authoriseContainer) to give the user a new chance to approve it.
In any case that’s something to be defined by the app’s creator, and the list of permissions granted can be inspected by the app using window.safeApp.getContainersPermissions and/or window.safeApp.canAccessContainer.
So what happens is that after an app gets more permissions granted with authoriseContainer, the new set of permissions is stored in the account and any subsequent re-authorisation will provide the same set of permissions that were granted, allowing the app to go back to a normal flow after the upgrade was successful.

On the other hand, we also envision that we could have more granularity in the authorisation flows, i.e. the user could select a subset of permissions to be granted when an authorisation request is received; or even at later moment by going into the app’s details page in the Authenticator UI.

When you think of all these scenarios, you can quickly realise that the authorisation flows need to be distinguishable between the case of just re-authorisation (due to re-launching/re-opening an app) and the cases when new a new/different set of permissions is being explicitly requested by the app (e.g. due to an upgrade).

I hope this helps to understand the background; the current state is one solution to all this, there are/might be other alternatives but this is the one we thought was the simplest and the one that covered all cases quite well. Nevertheless, I love this was brought up since it’ll be good to hear other ways that could possibly be a better and simpler approach to all this.

[happybeing]

Great response Gabriel, lots to think about isn’t there! I think this should be a topic in its own, so maybe repost your reply and put a link to the new topic in its place?

[bochaco]

I’ll try to gather some additional info to make a new topic and link it here

[happybeing]

I have a related question, no hurry…

One thing that confused me is that I was being refused Read permissions on _public.

I think there must be a way for even unauthorised apps to Read public information, so I’m confused as to how I would go about this if I need to get user authorisation for Read permission on _public.

So how can an unauthorised app:

• read _public
• read the services of a public ID (ie not owned by this user), and read the mapping for each service

Obviously the browser does something like this to access websites, but am I missing something about how to do this using the DOM API? Or just being dumb!

[bochaco]

The way I see/understand it is that the containers are meant to be for the owner and its own apps to be able to keep and reference files & data the user owns on the network. The data that is being referenced/linked from the user’s containers is what should be shared and/or made public and allowed to be read by unauthorised apps.

Thus, an app would request permissions to read your containers to properly function but that type of information is still personal and private to the user authorising the app, remember that apps are just acting/manipulating the user’s own data on the user’s behalf.

Now, for the case of public IDs and published services, the _publicNames container is a private MD with its entries all encrypted, it contains the list of public IDs the user owns, and a reference to the corresponding Services container for each of them.
However, unauthorised apps are able to access the services published under a public ID by finding the Services container which XoR name is the sha3 hash of the public ID string. The Services container is a public MD and its entries are unencrypted and available for the unauthorised apps to read freely.

[happybeing]

Thank you, that explains a lot.

I’m thinking we can create a node module for SAFE services, and could integrate it into the DOM API at some point.

All flowing from the Solid work, which I hope can be implemented as SAFE service for LDP. Then we could add RemoteStorage, BDS.Briefcase a link sharing service etc.

Or maybe not. Fingers crossed! Thanks for your help.