Closed
Description
Just wanted to make a note for everybody else(Most likely it can be resolved from model)
Example:
p, 0, /v1/login, read
p, 0, /v1/register, read
p, 2, /v1/home, read
Doesn't work:
var currentUserType int
if auth_rules.AuthEnforcer.Enforce(currentUserType, r.URL.Path, "read") == true {
Works(Convert int into string and then pass it to the Enforcer):
var currentUserType int
if auth_rules.AuthEnforcer.Enforce(strconv.Itoa(currentUserType), r.URL.Path, "read") == true {
Activity
hsluoyz commentedon Jul 24, 2018
Thanks for pointing it out.
Casbin treats the
pvals
elements in a policy rule (likep, 0, /v1/login, read
) as strings, because there's no way to tell Casbin what the type is. And when you provide integer arguments inEnforce()
asrvals
, Casbin will comparepvals
againstrvals
in the matcher. And the string"0"
won't equal integer0
.If there is anyone thinking this issue should be fixed in some way, we can discuss about it:)
IvRRimum commentedon Jul 24, 2018
I think this is more of convenience thing, definitely not in the priority list IMO.
Few ideas:
p, 011:int, /v1/login, read
.Amazing package,
Thanks!
hsluoyz commentedon Jul 25, 2018
The question is that
pvals
andrvals
are not always corresponding to each other, for example, I can define a function:older_than(person_name, age)
,person_name
is a string inpvals
andage
is an integer inrvals
.It complicates things and also needs to escape.
Added here: https://github.com/casbin/casbin/wiki/Policy-definition
ColmBhandal commentedon Jun 16, 2021
Just a thought. It would probably be less complicated to escape if we typed the argument at the policy definition level rather than the policy rule level. Since policy rules are storing the actual values of items, then yeah, I'd imagine escaping would be a bit complicated. But for policy definitions, we're just defining variable names, and in that case surely it would be OK for Casbin to reserve some special characters such as ":" for type? Of course, there would still be some work to parse such expressions for their types, and I agree with (https://github.com/IvRRimum) that this isn't a top priority.
Of course, doing it that way would mean we'd enforce homogeneous types of each argument across the whole policy i.e. all policy rules would have to conform to the same type-tuple. But IMO that's OK; in fact, I think that's cleaner than allowing policy rule tuples to vary in their types e.g. some are (
int
,String
,String
) while others are (String
,String
,String
). The way I see it, the type makes more sense at the policy definition level, just like the type of a field in OO programming is defined at the class level, and not per-object.