gitcloud VS accesscontrol

> However: you seem to target developers. Why do you force me to leave my IDE and use your "rules editor"? Can I not write all those things in my IDE, with all the support it brings, and integrate this into my CICD flow? (yes, there is the .polar file, but why force me to jump through hoops?)

Hey valenterry! Oso CTO here. You can absolutely write policies locally and integrate this with CI/CD. We have vscode extension for the former, and CI tools for running local dev environments and CI for running this locally or in CI or whatever.

The UI is mostly nice for getting started development experience, e.g. it integrates directly with Oso Cloud without needing to configure credentials.

> Then, why did you create a new DSL and not a merely a (de-)serializable datastructure (which will indeed look like a dsl)? One, that is powerful enough to represent the capabilities you need. Then, I could in fact use any language (library) of my choice and create the rules from this language, which just has to create the datastructure.

We have a post on this coming soon! The short version is that Polar is a logic language based on Prolog/Datalog/miniKanren. And logic languages are a particularly good fit for representing the branching conditional logic you often see in authorization configurations.

And it made it easier for us to do custom work like add inline policy tests.

> Apart from that, I really like the `yes, if` idea! Would be nice to hear a bit more about that (unfortunately, the article pretty much ends there). Such as: how to deal with actions that change things and can (or must) potentially be run before the authorization is completed and such.

We typically recommend authorizing in two places: at the start of a request, and then when fetching data.

e.g. in our demo app, authorizing "can a user create an issue" involves authorizing a "create_issue" action against the repository itself: https://github.com/osohq/gitcloud/blob/sam/list-filtering/se...

Whereas anything listing issues calls the `list_local` method and does the `yes, if` style approach.

You can mitigate the pain by using libraries like accesscontrol, express-rbac, django-guardian, etc., to manage authorization more declaratively. But making sure nothing leaks is still a significant challenge.

2- https://www.npmjs.com/package/accesscontrol https://github.com/onury/accesscontrol

I used nestjsx-crud in the api we prepared. This library makes CRUD operations very easy. However, there is no support on the authorization side. That's why I made use of the accesscontrol library, which can be easily integrated with both nestjs and refine.

Access-Control

not a big fan of DSL(s), I think it adds complexity to the code, checkout this library accesscontrol all the configuration is javascript objects and more maintainable I think.

I am going through the docs accesscontrol npm library and came across code to limit the user to only readOwn resources.

what do you think about this library accesscontrol. It seems easier to grasp with its fluent syntax and no custom DSL