Investigate local handling of permissions.

[n1k0]

What should we provide as features/API for frontend developers regarding permissions in the client?

Thoughts? @leplatrem @Natim @almet

[Natim]

We should provide a share this record and share this collection feature. I think.

[n1k0]

We should provide a share this record and share this collection feature. I think.

Indeed. Something like this would be convenient:

const db = new Kinto();
const tasks = db.collection("tasks");
tasks.share({scope: "public"}); // => https://…
tasks.share({scope: "<FxA_Token_Here>"}); // => https://…

If you guys have better ideas for the API, please shime in :)

[Natim]

I think we should stay closer to what the Kinto API provide in order to keep the same scope of functionality:

const db = new Kinto();
const tasks = db.collection("tasks");
tasks.permissions({"read": [Authenticated]}); // => https://…
tasks.permissions({"write": ["<kinto_user_id>"]}); // => https://…

[Natim]

There are three levels of permissions to handle here plus groups management.

We need Buckets permissions management:

const db = new Kinto("bills");
db.permissions({"read": [Authenticated]});

We need Collections permissions management:

const tasks = db.collection("tasks");
tasks.permissions({"write": ["<people_ids>"]});

We need Record permissions management:

tasks.recordPermissions("<record_id>", {"write": ["<people_ids>"]});

[Natim]

About group management, I have in mind something like:

const db = new Kinto("bills");
db.addGroup("readers", ["<peopleIds>"]);
db.addToGroup("readers", ["<peopleIds>"]);
db.removeFromGroup("readers", ["<peopleIds>"]);
db.deleteGroup("readers");

[almet]

I love how hoodie does it, they have .publish and .unpublish methods. We could probably use the same thing and pass it users or groups?

[n1k0]

I'd rather use share/unshare here, as a synced collection is already published for the user.

[almet]

True. I prefer this naming :)

[Natim]

I think there are two different things:

• Live server update for Bucket and Collections permissions (when creating/updating a collection or bucket)
• Per records sharing which will use the record / sync mecanism.

The one things that is blocking us at the moment, if finding a way to get other users ids. (Note that we can also create them in URL tokens for them to access the data.)

[ghost]

I would like to +1 the need to handle (at minimum) item level permissions. I can handle container level permissions in my app requiring online access (only admins can do that anyway), but without being able to set item level permissions, I can't support offline at all.

To keep things simple, I would agree that just attaching the same permissions object that I would otherwise call the permissions API with seems easiest.

[leplatrem]

I think this can be closed since the permissions handling is now covered in kinto-client.js

[n1k0]

We should probably expose the permissions in the record objects, but that would mean synchronizing them as well...

[ghost]

I would suggest you examine this from the perspective of your goals, rather than technical implementation.

• How offline first can you really be if when creating content offline you can't read or write permissions on content? None of my applications could work that way. If an application needs item level permissions, they need to work offline too.
• How offline first can you really be if you only support IndexedDB when IE, IE Edge, Safari and IOS Safari don't really support it?

My two cents. I know they are really hard issues to deal with. I have been struggling with the complexities of offline sync now for a while and it is really tough.

[Natim]

I know that PouchDB use IndexedDB when possible and fallback for other browser that doesn't support it yet. That's something we are opened to do. We do not have a usecase ourselves for now.

I know that kinto-client and kinto.js doesn't supports Safari because of missing fetch support as well.

Offline first and permissions are not really related IMHO.

Permissions are for server side records only, on client side you have permission on everything you've got locally.

When you want to add permission on records you want an acknowledgement that it has been done.

Can you explain me in which case your application won't be offline first if the permission is done directly with the server without an offline first approach?

[ghost]

Use Case #1 - User Experience between Read/Write I have synced a bunch of content locally. The content has synched locally because I have read access, but maybe not write access. I am working offline on some content. It would not be a very good user experience to allow someone to edit content they should not have permission to edit, and then later, when they reconnect and sync, show them a bunch of errors that they edited content they don't have permission to. While there is no real security on the client, and yes, permissions have to be enforced on the server, knowledge of permissions on the client so the user interface can assist in keeping users from doing the wrong this is preferred. Yes, the application needs to be written to accommodate for permission errors on sync anyway, but without supporting this in the user interface, these types of permissions errors are going to happen much more frequently, and user's are not going to be happy about it.

Use Case #2 - Authoring/Editing and Assigning Permissions Offline This is in my mind, a VERY common use case. I have just authored some content offline and need to set some permissions to it for my team. Permissions are most commonly applied when content is created, so the application user interface probably has the permissions UI close to the content editor. If permissions are not synched and cached on the client then a) I can't show that user which groups or other users have existing permissions on the content, and b) I can't allow them to set those permissions at the time they are editing the content.

I have to respectfully disagree that offline first and permissions are not related. If you are doing single consumer applications where the local content is largely personal and only for the current user, then I can agree with you... but if you are writing business applications where groups and item-level permissions are used to coordinate content across teams... they are absolutely related.

Do you think knowing what the permissions to an item are is confidential, or a security risk? I personally don't. If a user doesn't have the permissions to change permissions on the server, they won't be able to circumvent any security on the client. In my mind, permissions on all elements (buckets, groups, collections and items) should be synched to the client to give the application UI an opportunity to help ensure a good user experience that respects permissions, even if it is not real security.

I understand if you don't have a use case for this, but for my applications, which are business/team focused, if Kinto.js doesn't sync and store permissions for elements, then I have to do it myself . Writing the UI for an application without being able to see (and attempt to enforce) current permissions on that item (even offline) is simply not going to be acceptable to my users.

I understand if you do not have a current use case for support anything other than IndexedDB. Since Firebox supports it, that is probably your primary mandate, but please understand how limiting that is for the just about everyone else that does not have the privilege of dictating which browsers the user is using. For me at least, the inability to support iPhone and iPad for a hybrid mobile application or inability to support Cordova, is a non-starter.

As a small independent developer this is getting so exhausting. Outside the US, the numbers show that web application usage is actually still quite a bit higher than mobile, but inside the US, mobile apps rule - capturing an increasing market share of overall web traffic. Given the choice to use a web application interface vs a mobile interface, users and businesses, at least in the US, are showing a clear preference for mobile, and are making significant purchasing decisions because of it.

For people like me that really want to support open source and open standards, web applications need to evolve to be able to support rich and seamless offline experiences. Sadly, the state of offline in HTML5/CSS/JavaScript is as bad today as it was 3 years ago. Mobile operating systems are not adding capabilities to allow installing web applications as home screen apps, and even if they did, mobile browsers and the community as a whole are not making progress to allows those applications to work effectively offline.

I am no longer planning on using Kinto.js :( I am now at a crossroads where I either build the sync experience myself so it can meet my requirements, or I abandon hybrid mobile and go web only. Both decisions are probably going to put me out of business before I have even really got started. I am already having to build far too much myself, and adding the sync experience on top of everything else would probably make a severe challenge an insurmountable challenge. If I abandon hybrid mobile then I probably can't compete in the US markets with a web-based product alone.

I am sorry for the rant. Good luck with Kinto :) The need in the community is certainly real, and it has a lot of potential.

[Natim]

It would not be a very good user experience to allow someone to edit content they should not have permission to edit

That's true, but if the person wants to edit a record, it probably means she needs the permission to do it, so she can edit, have an error and later ask for the correct permission.

She can also not be allowed to edit, ask the permission, resync and then be able to edit but in that case we loose the offline-first benefit.

How would you solve this, does having the permission object locally helps you do decide in a UX point of view to show the edit button?

Would a warning before editing makes sense? "You apparently don't have the permission to edit this record, ask the permission before doing so"

Btw, this also means we can have unsolvable conflicts between a local records that has been updated with no permission to edit and a remote one, in that case (403) we should assume a SERVER_WINS policy.

[Natim]

I am no longer planning on using Kinto.js :(

Too bad, I think you've made your point and our collaboration would be of great value. Good luck with your projects.

[Natim]

@chrismbeckett Before you go, if you have mockups to share about this offline-first permission handling, it would be great to see what kind of informations are needed.

A question I have, if you want to give people permissions, it means you need to sync the list of user locally too right?

[almet]

You could get the permissions alongside the data you're retrieving from the server (e.g. downloading permissions and data), and then having the Kinto.js library tell you whan you're trying to e.g. add an item to a collection you don't have write access to.

I believe that's what this issue was all about: what kind of API should we have to handle this permissions management?

[ghost]

• Yes, I do sync a list of user profiles to the client for all users that are in the same organizational account as the user. This is used for displaying user information in the feeds, change history on items, etc. I have plans to also have extended profiles for all users that are in the same groups. The extended profile for team mates keeps track of content changes so users can see what their team mates are working on. I also need to sync groups and group membership which is why I opened a ticket asking for Group metadata. I was having to manage the information about groups in a custom collection.
• The API stores the permissions on each item anyway. Yes, having that information locally synced with the item would help the UI be able to make decisions about where to enable the edit button is primarily what I am asking for.
• I am NOT asking for Kinto.js to enforce the permissions on the client. I can have my application do that, but I need the permission information to do that.
• It would be very nice if I could modify the permission information on the item, and have permissions updated on the server as part of the sync.
• Permission conflicts as part of sync are something an application is going to have to deal with regardless. There will always be the chance that permissions on the server changed while they were working locally. What I am suggesting is that by trying to enforce permissions through the UI, it will minimize having to resolve permission related sync problems. It is much easier to keep a user from creating or making a change they should not, then having them make the change and then have to show them errors later.
• Integrating an Ask for Permission function into the client can be a useful feature (depending on app) but don't assume that restricting the UI based on permissions has to go hand in hand with a user asking for a permission every time. People are curious, and if you give them the ability to create a folder, or add a group, or comment on an item when they don't really have permission, they often will. If the option is restricted they will either just accept it, or they might send an email to an admin asking for that folder, or group, etc. Typically, I do not integrate an "Ask for Permission" feature directly into my applications - it is just handled through a normal support ticket feature.

I think what you guys are doing is very cool, your whole team are a bunch of smart developers, and open-sourcing it and actively working with a community is amazing and very much appreciated. I really like how you push to understand the use cases behind every feature/issue submitted - a great technique.

After 2 years of struggling to fold in various open-source and cloud services into my stack the single biggest lessons I have learned are:

• Don't expose any technology you don't control to you client application. Define your own API Gateway and make all client requests route through your own gateway. Despite functionality issues with sync we are discussing here, this is the second reason I won't be using Kinto.js on the client.
• Abstract all server side technologies from your business logic/services layer. Technologies are evolving, changing, dieing too quickly these days and everything is in constant flux. I am spending way too much time on technology selection and re-writes.

To address these issues, I put my application development on hold a few weeks ago, and am about to launch my own open-source project: Kato-js. Its a micro-services framework for NodeJS that provides an abstraction layer for pub/sub, remote procedure call, and data storage so I can write my services code and no longer be directly dependent on anything. I am currently hacking out providers for a variety of technologies including WAMP, Socket.io, Express, Redis, Firebase, MongoDB. I should have docs in Gitbook completed this week and the framework soft-launched over the weekend.

I am still considering using the Kinto server as a storage service, but if I do, I will be writing my own microservice layer around rather than calling the API directly from the client.

Regardless, I have learned a lot from digging into Kinto (client and server), and a big kudos to the Kinto team for building something valuable.

[Natim]

I was having to manage the information about groups in a custom collection.

This was fixed in https://github.com/Kinto/kinto/issues/469

Its a micro-services framework for NodeJS that provides an abstraction layer for pub/sub, remote procedure call, and data storage so I can write my services code and no longer be directly dependent on anything.

This make me think about a discussion I had the other day with developer of ZetaPush

Regardless, I have learned a lot from digging into Kinto (client and server), and a big kudos to the Kinto team for building something valuable.

Thanks :)

[almet]

I don't understand how #435 fixes this issue ? Can you elaborate?

[Natim]

It fixes this issue because it let you set permission using kinto.js by using the kinto_client permission api.