-
Notifications
You must be signed in to change notification settings - Fork 2.2k
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
Permissions #803
Comments
Hi, I got a solution without changing the source code of keystonejs.
Let me know if you have any issues. Thanks, |
Is this on the roadmap, and if so when should we expect something more than "isAdmin"? I am hoping to see role based security down to the field level. With respect this is a shortcoming in such a great project. |
Hi, is @wangpingsx standard ways to apply permission settings so far in Admin UI? The permissions is very important for most projects. Looking fowards to some standard methods. |
@arthurtalkgoal , I haven't use keystone for a while. I have't check the latest version. but so far as i know, there is no standard way to do this. However, the solution I suggested is kinds of standard way. I didn't use any hack method. what I did was all follow keystonejs architect, nothing special, nothing crazy. If you look into it you will know. Thanks, |
@wangpingsx could you share it as a pr? |
I'm starting work on this for my needs. So far after a very small amount of time I've added a For example:
Will show the list filtered to only show items created by whichever user made the request. I did this just as a proof of concept as I believe this can now be expanded upon so only certain roles etc can see certain things. Do you guys think this is worth continuing? Do you see me running into problems down the line? My use case is that each client should get a login but that user should only see information relating to that client, not the whole system so a
would be enough for me, but I can create a PR with a more fleshed out implementation? I suppose I can do a similar thing on a per-field basis too |
What do you think about this implementation? User.roles([{
label: 'superuser',
value: [{
collection: 'restaurants',
permissions: ['read', 'write'],
filter: 'all'
}]
}, {
label: 'owner',
value: [{
collection: 'restaurants',
permissions: ['read', 'write'],
filter: 'mine'
}]
}, {
label: 'chef',
value: [{
collection: 'orders',
permissions: ['read'],
filter: 'mine'
}]
}]); |
@JulianCeballos Looks good. |
@JulianCeballos yeah, as far as configuration, that looks good to me as well. What is label though...is that the user id? Would it make more sense to think of roles per group? Then it would force users to be part of some group. Also the permission set would probably need expansion. |
@webteckie is an identifier for the permission. I agree with your idea about the use of groups to attach roles. |
is it possible to toggle the |
If anyone is curious has to how I set my instance up, I simply added the following in
No perfect by any means, but it means I can do this:
And:
Note: They are simple examples I've created while testing out this functionality Hidden option requires an additional code change in
|
Another possible implementation I can envision here is as follows:
cc @JedWatson |
@webteckie thanks for the idea. I'm definitely new to Keystone, but I've tried testing out this implementation but for whatever reason I'm getting a |
@mattcrum the idea is not implemented, yet :-) working on it on my spare time, which is very little and this no easy task :-) hoping to have something soon for the community to comment on. |
@webteckie Sorry for the goof! I was getting pretty hyped on how easy it would have been to get moving. I've been playing with Keystone for the first time for a prototype that will require an Organization model which would contain users and those permissions would cascade down to the user (but can be changed at the user level as well). Great that you guys are thinking about these things and very much appreciated. |
@mattcrum no worries stay tuned for updates! |
I just found out there are A LOT of acl and rbac implementations on npm https://www.npmjs.com/search?q=acl |
Just wondering where this is at on the roadmap, bc it's key to what I'm building and would increase the value of keystone by an order of magnitude. |
Also interested in knowing progress on this, right now we have implemented @wangpingsx suggestion, using middleware to check permissions before rendering the admin views. |
Is there plan to include permission/role functionality in near future? |
Yeah, soon! |
I'm pretty new to Keystone, been using it for basics and performance has been awesome but now I want more and reading through all thats been explained here, I believe this is worth giving a try. I'm currently developing an app and want to use a custom user model(not the shipped Keystonejs one). I have created this and associated all necessary Admin UI fields
Will it be possible to have a user registration form and automatically assign role and allow user post into my Report model? Thanks in advance. |
tl;dr it would be amazing if we could implement complex permissions based on relationships and the state of fields in the models. Four things I'd like to add on this:
Not sure if this would already work given the above or if it's a bit of an extra effort. It's a little more specific than just giving |
@jstockwin re: item 1, yes, any approach should account for that use case. Re: 2, that seems like some sort of workflow problem, which not sure fits here. Re: 3, any approach taken should let you do that. Re: 4, I think for specific use cases like this you would do via the rbac or acl api. |
Is there an update on this? Thanks. |
Huh, still no update? |
Hi @niallobrien, no update on this issue specifically, other than to say that it's still a priority we're hoping to address in the 4.0 release or as a feature release soon after. I see you've commented on the open PR on the test-project. Other than that work, I don't think this has progressed past that although we're happy to hear any feedback on that implementation? |
Any more progress on this? Thanks! |
I don't know what you are looking for, but for me there is only one thing missing in the current implementation. Keystone already support permissions with this: const User = new keystone.List('User')
User.add({
name: { type: Types.Name, required: true, index: true },
email: { type: Types.Email, initial: true, required: true, unique: true, index: true },
password: { type: Types.Password, initial: true, required: true },
}, 'Permissions', { // << That is it
isAdmin: { type: Boolean, label: 'Can access Keystone', index: true },
isRoot: { type: Boolean, label: 'Administrator', index: true, dependsOn: { isRoot: true} },
isManager: { type: Boolean, label: 'Channel manager', index: true, dependsOn: { isRoot: true} }
}) So you can consider them as roles: Admin, Root, Manager ... For me the missing part is that I would like to be able to do this: const Model = new keystone.List('Model', {
noedit: function() { ... },
nocreate: function() { ... },
nodelete: function() { ...},
hidden: function() { ...}
}) If it could be possible to use a Is that possible ? |
@acmoune Instead of isAdmin, isRoot, isManager should we not have a Select Field say "userRole" with option to choose the role? |
Keystone 4 is going in maintenance mode. No major changes expected. see #4913 for details. v5 has more advanced access control which can be extended easily. see Access Control API |
Any update on access contol , i want some user to have an access of read,create,edit and delete, but some have only on read and create |
@alokkumarjha, please see @gautamsi's comment. |
Consolidates #269, #334 Keywords: ACL, Access Control List, rbac, role based access control
The text was updated successfully, but these errors were encountered: