sidecus / authzyin Goto Github PK

I've been battling for a day with building this on both my Mac and PC due to this known npm issue.
After a day with no luck I decided to switch to yarn instead with this PR #6 .

If you have this repo before, this will cause an interruption to your local build after syncing the new commits.
Please make sure you install yarn and clean up the npm build related files first (please make sure you don't have any uncommitted changes):

npm install -g yarn
git clean -xdf

Then just F5 from VSCode or dotnet run from the sample folder. I added custom dotnet build tasks to help with automatic yarn dependency restore and authzyin.js lib building in the same commit.

By default asp.net core serializes AuthZyinContext property names as camel case. To reuse the JSON path requirement definitions on the client, right now a brute force ToLowerCase is done on the client for each property name reference before the JSON path evaluation.

We should:

1. Give user an option to turn on/off this behavior (e.g. user website might have a global setting to use Pascal case for JSON serialization and in that case there is no need for special JsonPath processing on the client).
2. Use a more efficient way to process the JSON pathes instead of doing that before each evaluation.

Right now the client lib is a bit harder to use - for example user is responsible for loading and saving the AuthZyinContext to some global state which can be used by the useAuthorize hooks.

We need to make it simpler.

This repo contains both a server library and a client library to share policy/requirement based authorization.
Certain users might only want to use the client library - for example the server stack might not be using asp.net core.
Providing an option for users to use the client library standalone will maximize the potential benefits.

One potential solution is to let user provide their AuthZyinContext object as part of the initializeAuthZyinContext call.

Now we are serializing all policies and their requirements to the client. If there are many policies the data can be big - there is unnecessary network bandwidth used when a lot of requirements are being reused in different policies.

It can be optimized by putting all requirement definitions to an array and use references to requirements (like an id) in the policy definitions.

It's low pri but can be a future enhancement.