Skip to content

Casbin only takes string parameters(Note for others). #113

Closed
@IvRRimum

Description

@IvRRimum

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

hsluoyz commented on Jul 24, 2018

@hsluoyz
Member

Thanks for pointing it out.

Casbin treats the pvals elements in a policy rule (like p, 0, /v1/login, read) as strings, because there's no way to tell Casbin what the type is. And when you provide integer arguments in Enforce() as rvals, Casbin will compare pvals against rvals in the matcher. And the string "0" won't equal integer 0.

If there is anyone thinking this issue should be fixed in some way, we can discuss about it:)

IvRRimum

IvRRimum commented on Jul 24, 2018

@IvRRimum
Author

I think this is more of convenience thing, definitely not in the priority list IMO.

Few ideas:

  1. We could check the type of the identifier and then compare them with the type that is passed in.
  2. We could add ability for user to define type in policies file ex p, 011:int, /v1/login, read.
  3. Add note in README(haven't checked, might already be there tho).

Amazing package,
Thanks!

hsluoyz

hsluoyz commented on Jul 25, 2018

@hsluoyz
Member
  1. We could check the type of the identifier and then compare them with the type that is passed in.

The question is that pvals and rvals are not always corresponding to each other, for example, I can define a function: older_than(person_name, age), person_name is a string in pvals and age is an integer in rvals.

  1. We could add ability for user to define type in policies file ex p, 011:int, /v1/login, read.

It complicates things and also needs to escape.

  1. Add note in README(haven't checked, might already be there tho).

Added here: https://github.com/casbin/casbin/wiki/Policy-definition

ColmBhandal

ColmBhandal commented on Jun 16, 2021

@ColmBhandal

It complicates things and also needs to escape.

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.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Metadata

Metadata

Assignees

No one assigned

    Labels

    No labels
    No labels

    Type

    No type

    Projects

    No projects

    Milestone

    No milestone

    Relationships

    None yet

      Development

      No branches or pull requests

        Participants

        @hsluoyz@IvRRimum@ColmBhandal

        Issue actions

          Casbin only takes string parameters(Note for others). · Issue #113 · casbin/casbin