-
Notifications
You must be signed in to change notification settings - Fork 20
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Allow apps to request permissions, and explain why #31
Comments
I don't understand what do you mean by 'default checkboxes'. In #29 I suggest that person should have a way to chose which app they want to use to manage permissions for all the other apps, so we can't assume to much details about how this application UI functions.
👍 I thing we should have this as requirement. Since we talk about text presented to user it may also have some @solid/internationalisation-panel related aspects.
👍 It sounds related to #24 - general management of app authorizations, in that case changes initiated by application iself. To clarify your general use case, I understand that user always wants to grant to application some subset of permissions they have for certain resource. Does it require application to know what permissions the user oneself has to that resource? Could it happen that application want to request permission which user onself doesn't even have? |
@elf-pavlik Regarding the "default checkbox" comment, right now the app permissions popup that is shown has 3 out of 4 of the permissions checked. What I am proposing here is that the application itself should be able to show what permissions it needs to function properly, instead of having 3 permissions checked automatically. I'm approaching this from an application developer perspective, and we had several people not know they were missing permissions on our sample app because they had already granted incorrect permissions. We also had people who just click "Ok" assuming the popup will take care of everything they need, when in fact it didn't because the Control permission we needed was unchecked. |
and earlier
I still lack clarity if we talk about user specific access modes in ACL files or app specific access modes - which to my knowledge we currently don't even have proposed way to express (maybe except doing it with Maybe you could share two snippets with 'permissions' in question
I must admit lack of familiarity with mentioned React SDK. Given 'tic tac toe' app lacks specific permissions, with what app user will modify the permissions (and where those permissions get stored)? I appreciate your patience with helping me clearly understand your scenario. |
My apologies, I lost track of this! In this request I am specifically talking about application specific access modes, not user-based. Those are, in my opinion, two different things. The React SDK deals with both, but the application itself can help manage user-access permissions (either by displaying an error, or by granting access if appropriate).
The root problem is that the example app requires Read, Write, Append, and Control permissions for tic tac toe to work. This is due to many factors - Read is pretty obvious, as well as Write. We need Append control as we create notifications, and we need Control permission as well to grant access to your opponent. Right now, with NSS pods, the trusted app dialog is displayed showing the 4 choices, and 3 are pre-checked by the dialog. They are Read/Write/Append. Control is unchecked by default. Many people have simply clicked "ok" and accepted these settings, but in fact we need all 4, and this breaks parts of the app. What I am asking for is a way for the app requesting the permissions to explain what they need (which it sounds like you agree with) but also perhaps give a list of permissions we want, to pre-check what we need. Either that, or uncheck everything by default, instead of providing a list of 3 permissions that may-or-may-not be correct. |
@james-martin-jd I'd say this is a feature request for NSS not a spec request. The full solution to attenuated access control will be much more complicated, but if I'm understanding you correctly, this is something desired in the short term. |
@jaxoncreed yes, this is a problem we're currently having to work around in the SDK apps. Currently we show a little popup with a link to a dokieli doc that explains how and what permissions to set for the SDK to function properly. It's also an issue we've seen many, many people have, because it seems most people just rubberstamp the permissions dialog and select whatever is already checked by default. |
I think we can take it as one of Use Cases here. For that it would come helpful to besides read, write, append, control access modes document what kind of information the app wants to access.
All those question relate to three common aspect of permissions / authorizations
Often, for each 'kind' of data authorization will have specific access mode and sometimes location detail (or left global). |
That is a very good point. Some folks have commented that having to give an SDK-generated application Control permissions is "scary" because it can do a lot of things. Same with Write and Append. Really it only needs access to a few things (profile info, public and it's own app-specific inbox, and a few files it manages in its own folder). |
i think that giving any app (other than a designated sharing-control app) the Control permission is scary. |
As part of building the React SDK application, we recently added a "tic tac toe" game. The idea isn't that Solid now supports TTT, but rather to demonstrate to developers the best way to create a game that sends notifications, creates it's own data files, shares the data files in a collaborative way, and so on.
Because of this, the SDK application requires specific permissions. We create game files, then update the permissions for others to edit. We also create an inbox and change the permissions there so anyone can push notifications into it. For this reason, the app (and likely MANY apps) need Control permissions. However, this is not part of the default set of checkboxes when granting permissions, and additionally many people when using our test servers and deployed application at generator.inrupt.com had already visited previous versions, meaning they'd already granted now out-of-date permissions via the handy popup.
For this reason, we think it would be a nice addition to have the following features:
That last one came up during testing, as some users (I believe Vincent and Michiel) had run the app prior to Control permissions being required, and couldn't receive notifications as Everyone was not set to the proper permission on the inbox. But they had no way of knowing it, so it just failed silently. Ideally, we could show the popup again saying "Hey you tried to do something that requires Control permission but you didn't give this app permissions, change it?"
The text was updated successfully, but these errors were encountered: