-
Notifications
You must be signed in to change notification settings - Fork 25
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
use inquiries data in policies #20
Comments
Hi Thomas, SubjectEqual & co are still there so I can't say they are dropped, but indeed they still work only in case your policies (and inquiries respectively) are String-based like it was prior to 1.2. I have underestimated their usefulness when implemented Rule-based Policies support (Policies where you can define various attributes with dicts, like in your example). Besides, as far as I remember, there were some implementation issues with composition of Rules (And, Or, ... Not, etc) for such Rules, so they remained overlooked. Unfortunately the only way to achieve this is to deal with them in the old-fashion (like prior to 1.2), but in this case you're loosing attributes dict definition facility. We need to add new Rules, or new way to define such cases. Something like: Please, don't close this issue - it will be the reference. |
Hi, |
@ThomasChiroux, here is the initial PR for this feature. |
Resolved as of vakt v. 1.4.0. |
Hi, sorry wasn't available last week. 1.4.0 works perfectly for my use case. Thanks a lot !! |
Hi,
Is it possible to use inquiries parameters in element of the policy ?
The use case is to limit an API call to only raws that belongs to a particular user.
(stored in the example below in 'route_instance_id')
I want to authorise the rule only if the route_instance_id in the inquiry resource match the user_id in the inquiry subject
The only way I've found for now is to add dynamic policy at each request, but it's not very efficient and hard to maintain.
ex:
against policy:
I've seen there was a first support before 1.2 for string with SubjectEqual & co, but it has been dropped and did not support dict, is there a reason for dropping this ?
I think the use case is quite common (below is an example, but i've plenty of use-case like this one for the api).
Or perhaps there is another way to do the same thing i've overlooked ?
Thanks,
Regards,
Thomas.
The text was updated successfully, but these errors were encountered: