Multiple Request Types with Eval

[msfreed]

This question seems similar to #108, but that seemed to be resolved, but I am not able to get my test working. I am trying to use a single model that uses eval with different request models.

Using Casbin.NET v2.7.

model.conf

[request_definition]
r = sub, obj, act

[policy_definition]
p = sub, obj, act, rule

[policy_effect]
e = some(where (p.eft == allow))

[matchers]
m = r.sub.Name == p.sub && \
    r.obj.Object == p.obj && \
    r.act == p.act && \
    eval(p.rule)

policy.csv

p, bob, /data1, read, r.obj.Property1 == "prop-1"
p, bob, /data2, read, r.obj.Property2 == "prop-2"

Program.cs

using Casbin;

var enforcer = new Enforcer("model.conf", "policy.csv");

var sub = new { Name = "bob" };
//var obj = new { Object = "/data1", Property1 = "prop-1" };
var obj = new { Object = "/data2", Property2 = "prop-2" };

var result = enforcer.Enforce(sub, obj, "read");
Console.WriteLine(result);

When executing I receive, DynamicExpresso.Exceptions.ParseException: No property or field 'Property1' exists in type. Is it possible to have multiple request models and a single policy?

edit: I should say that this same behavior occurs if using anonymous types or not.

[casbin-bot]

@sagilio @sociometry @AsakusaRinne

[hsluoyz]

@sagilio0728

[sagilio0728]

Thanks for your feedback and for bringing this to our attention. I've done some digging into the issue you've reported.

Upon investigation, I've found that issue #108 has addressed the use of different Request Value types, and the ABAC eval model can now operate without errors. However, it's still crucial to ensure that the request types match the parsing conditions for each matcher, which I understand might not be the most user-friendly approach.

Regarding the use case you mentioned, I've come up with a potential solution that could work. I propose modifying the system to ignore parsing exceptions only under the ABAC eval model and assume that the result of the matcher is false. Additionally, for performance considerations, I suggest caching the type and the parsing results for each matcher.

This approach seems promising and I believe it's worth trying out. I'll be looking into implementing this solution and will keep you updated on my progress.

[msfreed]

Thanks! Any ETA on when you'll know if the proposed solution will work and if it can be merged into the main branch?

[github-actions[bot]]

:tada: This issue has been resolved in version 2.9.0 :tada:

The release is available on GitHub release

Your semantic-release bot :package::rocket: