-
-
Notifications
You must be signed in to change notification settings - Fork 276
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
Really hard to grasp the concepts as a newbie #135
Comments
Hi, Thanks for your interest in CASL. Probably I need to create such a begginer guide, so thanks for your questions :) it’s ok (the most stupid questions which were not asked ;)) Could you please tell me your app stack (frameworks) so I will try to talk using words which have some meaning in your app? |
By the way have you seen articles/examples in #5 ? |
Hi there and thanks very much for your reply :) it's nice to have that kind of support :) My stack is pretty basic: Vue 2.5.16, vuex 2.4.0, vuetify 1.2.5, for now i'm working with a mock backend that's supposed to return an array of roles for the user like roles: ['admin', 'mod']. like i said, all the articles and docs seem to be assuming that part is already understood by everyone :D so i'll probably just need a more abstract visualization of how everything is connected, how and where things are defined and how it plays together. thanks again very much :) |
You create/define abilities, actions and subject types based on your business requirements. So, for the blog application their may be this subject types:
User can read info about any other user and can update own info Any user in the system can create posts, update own posts and read any other post which was create by somebody else. Having this knowledge you define your business models/dB scheme (this is usually done by backend team) Later based on that scheme you define rules in CASL. So, eventually the ability for regular user in blog app looks like this: const user = ...//this should be returned by backend. Info about currently logged in user
const ability = AbilityBuilder.define((can)=>{
can(“read”, [“User”, “Post”])
can(“update”, “User”, { id: user.id})
can([“update,”create”, “delete”, “Post”, { authorId: user.id })
}) This should be read as: In your case business models already defined in mock server and you get them by REST API (my assumption). So, what you need to do is analyze requirements for each role, create a list of possible actions for each role (the easiest way to think is in terms of CRUD on REST endpoints), give names to your business models (usually it equals to the last URL part of requested resource, e.g., for http://example.com/api/posts business model name is Post or post name as you wish) |
When you finish with definitions of your ability, you need to identify places in UI where you need to hide/show something based on permissions. To do so, you can use @casl/Vue package . In case you need to check permissions based on fields if your business models you need to read this part in docs : https://stalniy.github.io/casl/abilities/2017/07/21/check-abilities.html Hopefully this helps :) |
Where/how do i define what a "Post" and a "User" is? how does CASL get to know that? Thank you very much so far :) |
You don't need to define that. It's just an agreement and that's it :) That strings has meaning only to you and your app. You don't need to register that subject is subject You can also use your models (i.e., classes) instead of strings. CASL will use |
To get better understanding of AbilityBuilder usage with classes (I.e., models) you can check this feature request Obviously I want to make things more clear for wider audience, so your questions will help me to think about and later create “Getting started” resources |
ohhhhhhhhhh i think i got it now! so all those abilities are actually just the whole definition of it? i can write whatever i want in there, and THEN will have to check it myself on any actions/api calls/renders? so that would mean, i could define is this the right way of thinking about it? |
Exactly :) |
ok very nice, thank you very much, you've been a great help :) |
Here i am again :D so now i've defined roles as collections of abilities
then in main.js, now i want to update that on login. my idea is to get an array of roles from the api (that can ultimately be mixed, like "[user, moderator, support]" for example) i have a vuex action that looks like this:
the questions now seem to be:
i hope you're having a great start in the new year and thanks in advance <3 update:after some fiddling around, i've got a solution now that seems to be working for the most basic use case: App.vue
this works, as long as i have ONE role. (and i'm happy about it :) )
regards :) |
You need to update your existing ability instance by rules from each role. The example in docs is more for backend but you can check example for vue integration with vuex and api: https://github.com/stalniy/casl-vue-api-example Thanks for the issue, I close this and will plan an update in docs (#144) |
Hi there! I really want to use CASL for my app, i've read the docs and examples multiple times, but i pretty much have no idea how to use it exactly.
What i don't get especially is:
What exactly are things like 'read' and 'all' ?
where/how are they defined? how can i define them myself?
if i want to give users the ability to delete a post and display a button if they can... like
can('delete', 'post')
how does CASL know what 'delete', 'post' and 'button' are? it has to be defined somewhere, but i haven't found out where. probably it's related to db-query verbs, but then again there are cases where it can't be just translated to CRUD, right? it seems to "just work" in all the examples i have seen. so basically i have no idea how to translate that to my app, where i have to customize that.is there a beginner-friendly explanation somewhere that i have overlooked? something that covers the absolute basics?
sorry if this seems stupid, i just can't get my head around it it seems :/
regards :)
The text was updated successfully, but these errors were encountered: