re-design casbin model conf to achieve Turing-complete about casbin-rs HOT 6 OPEN

What you need is a rules engine in this case, and not a language per se (although the rules may be expressed in a language syntax). You probably also need to trade off the complexity of maintaining a rules engine vs. keeping to the most common usages but be simple.

The main difference between a rules engine and a language interpreter is that, in a rules engine, you have to topological sort the rules (basically a dependency graph) according to execution order (layers) and to detect cycles/loops, because the rules will not be run in the order scripted.

I have written such rules engine years ago on top of a expression syntax. Maybe if I have some free time, I'll whip out a simple module based on Rhai for you to test out.

from casbin-rs.

See also: casbin/casbin#432

from casbin-rs.

If someone would like to design, based on casbin needs, what the rules will look like (hopefully they're all similar to Rhai syntax), then I can just code according to that design.

from casbin-rs.

@schungx Yeah it can be interested in testing your rule engine module, I have used some rule engines but they are quite limited and lack of powerful expressions.

If someone would like to design, based on casbin needs, what the rules will look like (hopefully they're all similar to Rhai syntax), then I can just code according to that design.

For this moment, I think we pretty need some methods on array like:

• any
• all
• reduce

JS syntax is fine I think

from casbin-rs.

So if we stick to normal function calls syntax with no wierd symbols, plus assignment statements to define rules, that should be enough?

Normally rules are something like:

Rule_1 -> Conditon1:all, Conditon2:any | Condition3

This will be expressed as

rule_1 = all(condition1) && any(condition2) || condition3;

In fact, if you order the rules in the correct execution order, and put let in front of the rule names, then you really get a Rhai scriptlet. If I put in a feature to omit the let keyword (i.e. assignment to a non-existing variable creates it), then it'll be a valid script by itself.

Actually you'd want to decide whether you really want a true rules engine, or whether you want your rules to be scriptable -- meaning that your user can actually write a mini-program for the matching, returning a value, with full language features such as loops, if-else etc.

from casbin-rs.

From what I can tell, Teaclave has a solver engine (or inference engine), which is one step up from a rules engine. A solver engine does back-tracking to try different combinations to find a solution.

The problem is that running a full-blown solver for each enforce operation is gotta be very slow, unless a lot of optimizations are done. However, logic is obviously much simpler to express for a solver than to actually write a program to search for a solution. So essentially, you're trading off power/ease of expression vs. ease of implementation.

Another problem with expressing logic rules is that it is hard to do calculations (at least not without going through a lot of hoops). Depending on the engine, simple things like p.sub.age > 16 is going to be clumsy to formulate without first defining what it means by greater-than.

If you really want a solver, maybe something like https://github.com/rust-lang/chalk is a good choice, since it is the future engine for Rust's trait solver.

from casbin-rs.