Eval not supported in non-generic enforces (request of policy size > 12)

[mabvanaartrijk]

Hi, we ran into an issue where the eval() or other matcher functions are not supported for large request or policy sizes:

[Fact]
public void EvalInNonGenericTest()
{
    var model = DefaultModel.Create();
    model.AddDef("e", "e", "some(where (p.eft == allow))");
    model.AddDef("r", "r", "sub, obj, act, r1, r2, r3, r4, r5, r6, r7, r8, r9");
    model.AddDef("p", "p", "sub_rule, obj, act, p1, p2, p3, p4, p5, p6, p7, p8, p9, p10, p11");
    model.AddDef("m", "m", "eval(p.sub_rule) && r.obj == p.obj && r.act == p.act");
    var enforcer = new Enforcer(model);

    var success = enforcer.AddNamedPolicy("p", "r.sub.Age > 18", "/data1", "read", "p1", "p2", "p3", "p4", "p5", "p6", "p7", "p8", "p9", "p10", "p11");
    Assert.True(success);

    var sub = new { Name = "alice", Age = 20 };
    var context = enforcer.CreateContext("r", "p", "e", "m", false);
    var allowed = enforcer.Enforce(context, sub, "/data1", "read", "r1", "r2", "r3", "r4", "r5", "r6", "r7", "r8", "r9");
    Assert.True(allowed);
}

Results in an error: DynamicExpresso.Exceptions.ParseException : No property or field 'Age' exists in type 'String' (at index 5).

It seems that when context.View.SupportGeneric is false all request arguments are handled as strings. Would it be possible to add support for this? Or do you recommend a workaround? Thanks!

[casbin-bot]

@sagilio @sociometry @AsakusaRinne

[hsluoyz]

@mabvanaartrijk why size 12 is the limit? Does this have anything to do with size?

[sagilio]

@hsluoyz @mabvanaartrijk

1. Support is possible. We can expand the scope of generic support or use a dynamic approach to support more values.
2. I would like to know approximately how many values you are hoping for, as the limit of 12 is related to performance optimization, and within this number, there will be an order of magnitude improvement in performance. At the same time, our adapter persistence will also control a certain number of fields by default.

[mabvanaartrijk]

@sagilio We now have a policy size of 14, possibly in the future we have use cases that need a few more. I understand that expanding the generic support has some drawbacks.

Would it be possible to add support for matcher functions outside the generic support? I'm now looking at creating custom eval functions that deserialize the string objects. I guess this will work too.