Target casbin to wasm

[xcaptain]

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

[xcaptain]

First trial failed, because casbin depends on tokio depends on mio depends on net2, and net2 doesn't compile on wasm32-unknown-unknown. To achieve this we have 2 solutions.

1. Design a core casbin that is synchronous and minium so can compile to wasm
2. Wait until async-std support wasm [tracking] browser WASM support async-rs/async-std#220

[PsiACE]

I like option 1, more lightweight, better structure.

[GopherJ]

I would say we can have a synchronous feature or wasm feature, All the adapters can also implement this feature.

If someone is interested in this please comment below.

[parqbanq]

Currently using CASL in js, which is 'isomorphic'. Looking for something similar in rust, so yes, interested.

[hsluoyz]

We had a plan for developing casbin.js, which is based on Node-casbin because of the JS language: casbin/casbin.js#2 . We may even have a GSoC student to work on it this year: https://github.com/casbin/SummerOfCode2020#casbinjs

Of course it's also welcome if Casbin-RS can achieves front-end authorization too via WASM!

[parqbanq]

@hsluoyz That's even better I suppose as at this stage many solutions will have rust for backend and js in the client.

[GopherJ]

async-std = "1.6.0-beta.1" # Async version of the Rust standard library

has been published with smol as runtime, so we can retry to add wasm support. @xcaptain

[GopherJ]

I'll try to upgrade async-std to 1.6.0-beta.1

[GopherJ]

I upgraded async-std to 1.6.0-beta.1 but found a big bench regression, I think maybe the bench code need to be adjusted because the two runtimes seem to work differently.

See also: async-rs/async-std#770

[GopherJ]

@xcaptain In #136 , we already be able to run cargo check with all our features:

cargo check \
--target  wasm32-unknown-unknown \
--no-default-features \
--features runtime-async-std,cached,glob,ip,watcher,logging,incremental

[GopherJ]

Ref: async-rs/async-std#843

[GopherJ]

with the release of async-std@1.6.4, it's now passing wasm CI check