currently we are using:

pub type Result<T> = std::result::Result<T, Box<dyn std::error::Error>>;

Ideally we should use our own error type.

We should add a Casbin example to: https://github.com/actix/examples

And list Casbin into their README.

One of the more interesting features of rust are proc-macro's, I have wondered if it was possible to use a diesel style "schema" generator to create the Model and by doing so create a type that can hold policy lines and have this also used in enforce possibly? This example is more a proof of concept to start a conversation about this feature.

I created a repo with a minimal-ish example
Casbin-proc-macro

Questions

Is it even wanted?
How would this be integrated without breaking existing code or have a simple upgrade path ?
Any other thoughts

Advantages

• gives type safety to the model definition compile time errors, instead of runtime
• by reading in the model we can dynamically define the Policy struct and the function to compare a request to a policy
• no rhai this is maybe a positive not sure about the trade offs
• maybe others?

The current implementation of role inheritance has a big problem, it can handle direct link between 2 roles but can't handle indirect links like user -> role -> role.

#[test]
fn test_role() {
    let mut rm = DefaultRoleManager::new(3);
    rm.add_link("u1", "g1", vec![]);
    rm.add_link("u2", "g1", vec![]);
    rm.add_link("u3", "g2", vec![]);
    rm.add_link("u4", "g2", vec![]);
    rm.add_link("u4", "g3", vec![]);
    rm.add_link("g1", "g3", vec![]); // problem occurs, u1 is already in g1, but can't infer that u1 is also in g3
    rm.print_roles();
}

the print result is:

{
    "g3": Role { name: "g3", roles: [] }, 
    "u2": Role { name: "u2", roles: [Role { name: "g1", roles: [] }] }, 
    "u1": Role { name: "u1", roles: [Role { name: "g1", roles: [] }] }, 
    "g1": Role { name: "g1", roles: [Role { name: "g3", roles: [] }] }, 
    "u3": Role { name: "u3", roles: [Role { name: "g2", roles: [] }] }, 
    "u4": Role { name: "u4", roles: [Role { name: "g2", roles: [] }, Role { name: "g3", roles: [] }] }, 
    "g2": Role { name: "g2", roles: [] }
}

When using has_link to check link between u1 and g3, we will iterate over roles in u1 that is g1, but this g1 has no related roles, while in fact in role manager, g1 has a related role g3.

This problem occurs because we are constructing Role using a clone

#[derive(Clone, Debug)]
pub struct Role {
    pub name: String,
    pub roles: Vec<Role>,
}

So when a role changes, it's original clone doesn't change. I have 2 ideas to solve this problem:

1. Keep using a clone, so when g1 has changed(added to g3), all roles related with g1 must be updated, that is u1 becomes

   "u1": Role { name: "u1", roles: [Role { name: "g1", roles: [Role { name: "g3", roles: [] }] }] }, 

2. Pass by reference using Rc

3. Copy all_roles in DefaultRoleManager to every Role object, since all_roles has all the role infomations.

I will try the second way first. @GopherJ @XanthusL Do you have any ideas on this problem?

Deref inheritance is an anti-pattern in rust because it's just passing actions/tasks to specific field. That means in our function we'll never be able to get child's reference.

So I propose to have better design and remove the usage of Deref in CachedEnforcer.

What can we do?
I think we can use trait inheritance, that means we should have a base/parent trait which can be called as CoreApi.

Then imple<T> InternalApi for T: CoreApi, impl<T> MgmtApi for T: InternalApi, Impl<T> RbacApi for T: MgmtApi

So finally for different types of enforcers they just need to implement CoreApi to get all the management functions.

How can we have different behaviours for different Enforcers?

No idea for now.

CachedEnforcer will have extra functions comparing to normal enforcers
SyncedEnforcer is a wrapper over Arc<RwLock<Enforcer>> or Arc<RwLock<CachedEnforcer>>

casbin and diesel-adapter are synchronous, but it's worth adding async support to casbin and create a new async adapter.

https://github.com/async-rs/async-std
https://github.com/launchbadge/sqlx

The new adapter can be called sqlx-adapter, it's not ORM, but it's full asynchronous.

While doing the same bench test suite like casbin golang: https://github.com/casbin/casbin/blob/master/model_b_test.go

I found we can get similar results with CachedEnforcer but the normal enforcer is 6x ~ 7x slower than golang version.

Can someone help investigating?

@xcaptain @DevinR528 @PsiACE @hackerchai

eg. running small size of rbac model test:

Casbin Golang

BenchmarkRBACModelSmall-8                     	   10000	    113285 ns/op	   28528 B/op	     790 allocs/op

Casbin Rust

test b_benchmark_rbac_model_small                ... bench:     729,440 ns/iter (+/- 266,774)

Ref

• https://github.com/casbin/casbin/blob/master/model_b_test.go
• https://github.com/casbin/casbin-rs/blob/master/benches/benchmark.rs

It'll help the developpers a lot if we can add more examples like what actix-web has done: https://github.com/actix/examples

Currently we don't have enough docs. I hope me or anyone else can find time to add them.

But at the same time we can already start to prepare some examples like:

1. actix-web + casbin example with fileadapter
2. actix-web + casbin example with diesel-adapter
3. actix-web + casbin example using CachedEnforcer (default cache)
   ...

Maybe we can also add some examples on other web frameworks.

I added an repo if anyone wants to contribute.

https://github.com/casbin-rs/examples

A proper logger is missing util now with the following features:

1. show the request (sub, obj, action) etc
2. show the enforce result
3. show if it's cached result (by adding a prefix [CACHE])

Currently we load all the policies into casbin and then do the matching, this would cause a lot of memory when we have many policies(millions or more). A filtered adapter means when an enforce request happens then query the adapter for result.

diesel-adapter and sqlx-adapter should implement this feature.

We usually use casbin-rs in a web server, that is when a request comes in, a middleware or controller asks casbin whether it's authenticated. A common situation is that we also have a frontend ui that needs to do permission control. If we can compile casbin to wasm file, then we can do enforce at browser, no need to ask for the server all the time.

Rust has very good wasm support, I think this idea can be implemented. After that we need to consider how to sync user's policy from server, maybe we need to add a get_all_policies_for_user in internal_api.rs

We have very active development for Casbin-RS now. However, our popularity is still under my estimation (129 stars). I hope we can do more advertisement in future to let people know and use our project.

The first thing we should do is to add Casbin middleware: https://github.com/actix/examples/tree/master/casbin to Actix official middleware list: https://actix.rs/docs/middleware/ . So Actix website visitors will also come to our GitHub page.

Can anyone work on this?

At the beginning we would like to use &str because the conversion from String to &str is cheap.

However, if we consider the production environment and the real use case, we will find it's hard to generate &str with the "correct" lifetime ('static).

For example:

fn fetch_policies_from_db(conn: &Conn) -> Vec<&str> {
 // hard to implement because &str borrows policies (String) but policies will be released after this function call
}

The better solution is to have: Into<String> but we need to guarantee it's Send and Sync.

Clippy is a static analysis tool, Recently I tested this project using cargo clippy and found a lot of errors and warnings.

We have already setup cargo fmt in travis-ci, should we fix cargo clippy errors before committing?

Setup clippy with travis-ci is easy, https://github.com/rust-lang/rust-clippy

A general case in casbin is to share the same policy storage with several enforcers, once an CRUD operation has been made through one of the enforcers. The others need to pull these changes immediately from policy storage.

And during the execution of the pull operation, enforcer needs to be locked. No more enforce can be made util the finish of pull.

Also it'll be good if we can pull only the changes instead of reloading all the policies.

Hi, is there any relation between this project and https://github.com/Devolutions/casbin-rs?

On the casbin homepage, it links to the other repo, but the overview page links to this repo. The goland and node repo's for casbin also link to the other repo.

See: https://casbin.org/docs/en/overview#feature-set-for-different-languages

Currently, our APIs are separated in different modules, like:

use casbin_rs::model::Model;
use casbin_rs::enforcer::Enforcer;
use casbin_rs::adapter::FileAdapter;
use casbin_rs::RbacApi;

which are not convinent to use, should be exported from crate root like:

use casbin::{Model, Enforcer, FileAdapter}

See also: casbin/casbin#439

My idea is to make effector a writable stream (Sink + Stream), once a policy has been analyzed, we write it into the stream and the stream will use different strategy to analyze the result.

Once the final result is produced, we return it as the result of e.enforce

I don't really like the idea of watchers because it's buggy and heavy, image when one enforcer AddPolicy, the others need to reload all the policies from DB.....

we should find other solutions.

See also: casbin/casbin#421

• implement an actix casbin actor which accepts messages of rbac request (subject, domain, object, action and more). The actor will return the result of enforcing.
• implement an actix middleware using actix-web-httpauth and actix casbin actor

Please comment below if you have sent proposal and if you'll work on this.

casbin doesn't have cache support, but it'll be good to have it, especially for realtime applications.

See casbin/node-casbin#105

Current we are matching directly over object, means subject can act on object, with ABAC we can do matching like: subject can act on object is this object has specific attributes.

ABAC doc

This problem may be a little hard because we are using Vec<&str> as the parameter for enforce, which requires every element in the vector has the same type that is &str. I have 2 ideas about this issue.

1. Change from Vec<&str> to tuple, so we don't need to worry about the type.
2. Still passing obj as a string, parsing this string into a struct in rhai then do the matching.

Currently, we use casbin-rs as the package name in Cargo.toml, would be better to use casbin directly. Also the name casbin is available, see: https://crates.io/search?q=casbin

• Design Logger trait and implement the default logger which implements Logger trait.
• Logger can show if the enforcing result is cached or not by the prefix [Cache].
• Logger support levels (info, debug, error...). Logs can be filtered by specific Level.
• Logs are by default colorful.

Please comment below if you have sent proposal and if you'll work on this.

Todo list for the v1.0 release

• Optimize model.rs, add more tests @GopherJ #8
• Optimize rbac.rs, implement get_roles and get_users method @xcaptain #7 #9
• Setup travis and codecov @hsluoyz
• Check whether domain can have a length more than 2 strings. This affects if we should define domain as Option<&str> or Vec<&str> @hsluoyz
• Implement RBAC apis for enforcer @xcaptain #14 #20
• Add clippy to travis-ci and fix clippy warnings @GopherJ #15 #16
• Add autoSave, autoBuildRoleLink option in enforcer @xcaptain #17
• Investigate how to use variadic parameters in rust. e.g. enforce, generate_g_function, add_permission_for_userand so on. Currently we are using Vector to store those parameters, but this way is not elegant @xcaptain #22
• Refactor api structure. #29
• Rename the package name. #30
• Default implement some APIs for Enforcer. #31
• Create model from file directly for easy of use. #32
• Better error handling. #24
• Create a diesel adapter
• Investigate how to replace a boxed trait at runtime. e.g. replace e.adapter with a new adapter at runtime. @DevinR528
• Fix module visibility, remove unnessarry pub
• Add benchmark @GopherJ @DevinR528
• Investigate how to parse in operator in config file @GopherJ
• Automatically publish package to crate.io when a new git tag is created
• Add cache support (@GopherJ @xcaptain ) #45
• Add watcher support (@GopherJ @xcaptain ) #46
• Add async-std support (low priority @GopherJ @xcaptain ) #43
• Implement a FilteredAdapter #79
• Implement ABAC model #78
  People who want to contribute please reply to this issue, apply for a task and then make a pull request.

https://github.com/rhysd/github-action-benchmark looks pretty cool. I put it here in case anyone would like to give a try

Currently, we wrapped APIs in 3 traits: RbacApi, MgmtApi and InternalApi, When user want some APIs they need to manually import the corresponding trait where enforcer was created, it's not very convenient to use. We can consider using ether ways below

1. Remove the 3 traits and directly implement these APIs to Enforcer
2. Default implement these traits for Enforcer at lib.rs

some times users just need part of all the features. It's important to let users choose what they want so that we can decrease the binary size.

We can have the following features:

• cached => add the dependency: ttl_cache, default enabled: false
• glob => add the dependency: globset, default-enabled: true
• logging => add the dependency: log , default-enabled: false, [done]
• ip => add the dependency: ip_network, default-enabled: false
• watcher => add EventEmitter, every policy change will need to clone the changes and pass it to watcher which added some overhead, default-enabled: false

We can use github actions to generate rust doc and then push to an gh-pages branch, so we can have a doc site.

We can learn from https://github.com/rust-analyzer/rust-analyzer/blob/master/.github/workflows/rustdoc.yaml and https://github.com/peaceiris/actions-gh-pages#1-add-ssh-deploy-key

Using this way we need to generate a ssh key pair for github actions so it can commit to this repository.

Here the link where we'll use for GSOC casbin-rs and future communication on improving casbin-rs. Please join if you would like to do contributions on casbin-rs or if you have sent casbin-rs proposals.

Workspace: [email protected]

Join: click me

We (Devolutions) are looking at switching to the new casbin-rs project, leaving our initial port of casbin to Rust from a year ago behind in favour of this one. Overall, the new project looks good, but our primary concern is the lack of proper error handling.

A quick search in the code base reveals there are 92 unwrap() calls. Some of them are benign in nature, like unwrap calls in unit tests, but there are a bunch of them that could cause issues in production. We intend to run this code inside a server process, and unwrap() would cause the entire thread to panic, which is obviously not desirable.

Our old code had a simple error type with an enumeration of a few errors (evaluation error, parsing error, invalid value, etc.). The new code has a simple string error type, but it should be improved with a real enumeration of errors to facilitate error processing.

The idea would be to replace all unwrap() calls with errors, which would affect the function signatures (it would return a Result, which is either a success value or an error value). In addition to this, the error type would be improved with an enumeration of error types. Once functions are modified to return Results with the same error type, it should become easy to use the ? operator to reduce the amount of boilerplate error handling.

We would like to know what would work best to make these kind of improvements. Should we do it ourselves according to the way we have described it and submit a PR, or would you prefer doing it? The side effect of adding proper error handling is that changes will affect a lot of files.

Please let us know, and we'll begin putting our efforts on the new casbin-rs. Thanks!

Currently, we use load_model to load model definitions from a config file, which is not convenient to use (2 lines), should consider adding a new from file API so we can create a model in 1 line.

Following up from #55 need to add unit tests for the following apis:

async fn add_policies(&mut self, paramss: Vec<Vec<&str>>) -> Result<bool>;
async fn remove_policies(&mut self, paramss: Vec<Vec<&str>>) -> Result<bool>;
async fn add_named_policies(&mut self, ptype: &str, paramss: Vec<Vec<&str>>) -> Result<bool>;
async fn remove_named_policies(&mut self, ptype: &str, paramss: Vec<Vec<&str>>)
        -> Result<bool>;
async fn add_grouping_policies(&mut self, paramss: Vec<Vec<&str>>) -> Result<bool>;
async fn remove_grouping_policies(&mut self, paramss: Vec<Vec<&str>>) -> Result<bool>;
async fn add_named_grouping_policies(
        &mut self,
        ptype: &str,
        paramss: Vec<Vec<&str>>,
    ) -> Result<bool>;
async fn remove_named_grouping_policies(
        &mut self,
        ptype: &str,
        paramss: Vec<Vec<&str>>,
    ) -> Result<bool>;
async fn add_permissions_for_user(
        &mut self,
        user: &str,
        permissions: Vec<Vec<&str>>,
    ) -> Result<bool>;
async fn add_roles_for_user(
        &mut self,
        user: &str,
        roles: Vec<&str>,
        domain: Option<&str>,
    ) -> Result<bool>;

See: https://github.com/casbin/casbin/blob/04c96314107df0803aa1e7ffaf3cd4784911a88c/rbac/default-role-manager/role_manager.go#L50

https://github.com/casbin/casbin-rs

@xcaptain @GopherJ It's still PHP code. Can you help rewrite these two sections in Rust?

Apache Teaclave (https://github.com/apache/incubator-teaclave) is an Apache incubator project focusing on SGX. They implement a similar modeling language as Casbin but seems to be more powerful (Turing-complete). See: apache/incubator-teaclave#265

acs: https://github.com/apache/incubator-teaclave/tree/6d53e8b4fe841598e0472a9abd27776c91e90469/mesatee_services/acs

Can we make our Casbin language Turing complete too?

• Design Cache trait, make CachedEnforcer being able to accept external cache.
• Implement redis TTL cache.

Please comment below if you have sent proposal and if you'll work on this.

Rust 1.42 will provide some pattern matching improvements and will be released on Mar 12, for details see https://blog.rust-lang.org/inside-rust/2020/03/04/recent-future-pattern-matching-improvements.html

I think it's a good opportunity to replace the current Vec<&str> apis to [&str; 4] and pattern matching whether the passing argument is of length 3 or 4

See: https://github.com/semantic-rs/semantic-rs

Does anyone have time to do this?

In the main repo, it says this project is "work in progress" and the crate is also not published. Does this mean it isn't usable at this point in time? If so, can you give an ETA on how long it will take? It looks like there hasn't been much activity in here lately... Thanks!

• Make async-std runtime (the current one) a feature runtime-async-std and enables it by default.
• Implement the new feature runtime-tokio which use tokio as the executor of async/await.
• Implement a fully asynchronous adapter: sqlx-adapter using sqlx.

Please comment below if you have sent proposal and if you'll work on this.

Hi!

Do you have an example to add new policies from a function, not just a file?
I saw that you can use a MemoryAdapter but I can't make it work.

let adapter = FileAdapter::new("/policy.csv");
let e = Enforcer::new(Box::new(model), Box::new(adapter)).await.unwrap();
let enforce = e.enforce(&["alice", "/admin/users", "GET"]).unwrap();
println!("Result: {}", enforce);

Thanks!
Lucas

Rocket is one of the top web frameworks in Rust. We already made a Actix middleware (#92) but haven't got a Rocket one.

I think this demo (https://github.com/oiatz/Rocket_Casbin_Demo) is not enough. We will need a full-fledged rocket-authz middleware here: https://github.com/casbin-rs/rocket-authz

The Rocket community has urgent need for good authorization:

• rwf2/Rocket#8
• https://github.com/SergioBenitez/Rocket/search?q=auth&type=Issues