Enforcer lifecycle, caching etc. about casbin-aspnetcore HOT 4 CLOSED

@sagilio @xcaptain @huazhikui

from casbin-aspnetcore.

Model and Enforcer have the default Scope lifecycle at the current version, you can change it by optional parameters,
And in Casbin v2.0, we can use synced model, so the model can have a singleton lifecycle.:

If you use the default option, the changes to the database will be active immediately, Would you like to provide a sample for us to handle this problem

from casbin-aspnetcore.

I feel like I'm on a fairly steep learning curve here.

What I'm trying to achieve is:

1. Use EFCoreAdapter with a PosgresSQL and a custom CasbinContext (VerjiCasbinContext)
2. Access Enforcer in service components which are resolved from contiainer/ServiceCollection
3. Use CasbinAuthorize attribute with custom RequestTransformers
4. Use filtering to avoid loading all data
   • Filtering must be made from request parameter (i.e picking from HttpContext somehow)

I think the approach I have now is wrong and has issues with component lifecycles. Currently I'm registering Casbin components in an Autofac container. The CasbinAuthorize middleware resolve the Enforcer from the DefaultEnforcerFactory which resolves it from Autofac/ServiceCollection. In other components I inject Enforcer directly. I think this is causing issues with lifecycle management and concurrency.

So to elevate my understanding of Casbin, I would like to hear about the recommended ways to achieve the goals I described above.

• What is the recommended way to use EFCoreAdapter instead of DefaultFileAdapter?
• What is the recommended way to get access to an Enforcer object using DI
• What is the recommended way to use filtering in an enforcer in the middleware? (Filtering on parameters in HttpContext)

I hope there is a better way than to re-implement most of the servicecollection registrations, and that overriding the correct dependencies will do the trick.

from casbin-aspnetcore.

We have come a bit further, so I'll just summarize what we've done in case there are comments, or in case this could be of benefit to others:

To leverage the most of the logic already in place we abandoned most of our custom DI registrations, and try to rely more on the casbin built in handling of scopes etc. So now we instead:

• Register our custom VerjiCasbinDbContext
• Register a custom VerjiEnforcerProvider

In VerjiEnforcerProvider we inject:

• ICasbinModelProvider
• VerjiCasbinDbContext
• HttpContextAccessor

This lets us create an adapter, and an Enforcer, and lets us customize the adapter and enforcer to ensure:

• We have added the appropriate matching functions
• We applied the appropriate filtering of policies

With this approach things started to behave a lot better wrt. object lifecycle, and data staleness.

from casbin-aspnetcore.