-
-
Notifications
You must be signed in to change notification settings - Fork 278
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
Wrong results testing abilities - bug correction suggested #59
Comments
Hi Joel, Thanks for the issue! I see that you misunderstood how to use There are 2 different So, in your example you cant pass object as a 3rd argument into class Post {
constructor(attrs) {
Object.assign(this, attrs)
}
}
console.log(ability.can('manage', 'Post')); // => true, correct because potentially you can manage at least 1 post whose `{ author: 'joe' }`
console.log(ability.can('manage', new Post({ author: 'al'}))); // => false, correct because you can manage only `{ author: 'joe' }`
console.log(ability.can('manage', new Post({ author: 'joe' }))); // => true, correct because you can manage only `{ author: 'joe' }` Please read checking abilities page in documentation to understand the details :) I'm going to close the issue as there is nothing to fix. |
Good idea, libraries! Please explain why I need to create multiple instances of this class to check in the same Post context? What's funny? To work in a browser (especially with React) is a bad idea, don't you think? |
Hello @wmwart , The point is not in that you need to create a separate instance for every object in your app. The point is that you need to understand the object type from object instance (otherwise you don't know with what you are working, what fields it has and so on). The easiest way to illustrate is to define class and its instance (what I did, and the same stuff is shown in docs). By default CASL, checks instance This is explained in docs, in the section about Instance checks Why I don't like suggeted API:
What I do (suggest) on frontend:
If you don't like this, then you always can extend |
Thanks for the detailed answer! Your logic has become clearer. Yes, indeed, I use 3 services: backend on GraphQL-yoga, frontend React, and CASL authorization service. The same rules should be used in all services that require authorization. I'm used to seeing what's on the box, what's in the box. Therefore, the syntax:
for me it is more evident. In addition, in GraphQL in type Post there is no data about the value of the fields, so there is no sense in
More logical:
In this case, you can really check the availability of the required fields and so on. As you may have noticed GraphQL is gaining popularity, but CASL examples are not added. Do you have any information or usage examples? Please help with the idea. I need to create a rule for example:
how can this be implemented? Maybe there are already examples? |
Unexpected results in the code sample below are probably originated in line 110 of file
casl/packages/casl-ability/src/ability.js
which reads yet :if (rules[i].matches(subject)) {
but when updated to :
if (rules[i].matches(field)) {
gives correct results with the following code example :
Without the suggested correction all results are unexpectedly
true
.Hope this helps !
Joel
The text was updated successfully, but these errors were encountered: