Adapters should not be part of the API about casbin-server HOT 12 CLOSED

I pushed an example to demonstrate what I mean: iotbzh@5b17273

from casbin-server.

I pushed a working version of what I'm saying: iotbzh@fd5f4d1

Is there any chance such a modification can be merged some day? I understand that it will break existing usage, but I still don't see any reason to use casbin-server over casbin if it's not a "centralized adapter-model-policies" server.

from casbin-server.

I think adding command-line params is OK. But please don't break the current usage. Let them both work.

from casbin-server.

I don't see how both model could live together.
In the current version, client should use this workflow:

1. connect to server
2. ask server to create an adapter and get it's handle
3. ask server to create an enforcer using the adapter's handler plus a model path from server's and get the enforcer's handle
4. use the enforcer (load, add, remove, save policies, and enforce)

In my forked version, client workflow is this:

1. connect to server
2. ask server to create an enforcer without any argument
3. use the enforcer (load, add, remove, save policies, and enforce)

In fact, I wonder if I will keep the step 2 or not, creating one enforcer for the only existing adapter.
The client can't choose the adapter or the model, it's enforced by the server. If you want another adapter/model, then start another server with corresponding arguments, the client just have to point it's url to the right server.

The whole point of this is to have the possibility to write an "on premise" application that does not ship it's permission system. Customers should then start their own casbin-server, setup as they want, and setup the app to use their casbin-server instance. Meaning that they can provide their own permission model/adapter without any change in the app.

Allowing casbin-server's client to choose the adapter and the model is not a good idea in this context in my opinion. Also, allowing both approch would lead to a weird API I think. Because an adapter will exist before any client ask for it (so client don't know this handle), but functions will still ask for an adapter's handle. Same thing with the NewEnforcer function with will still ask for a model that is already loaded. We can specify that a handle of 0 or -1 means "the already existing adapter" for example, but I don't really like that, do you?

I think the best way to keep both version is to make a "v2" branch and use the semantic import mechanism so that people can choose which version the want. Also, without explicitly import the "v2", you will stick to the current version, so nothing will be broken.

My only concern is that calling my version "v2", it mean that "it's the new official behavior" from users point of view. But if current users do want to create multiple adapters/models, etc..., they won't be happy with this change. This is why I asking if anyone have any reason to have a server that can create multiple adapter/model, because I don't see the point of that over the casbin lib.

from casbin-server.

I think adding command-line params is OK. But please don't break the current usage. Let them both work.

from casbin-server.

@ctxnop, I just stumbled on this issue and do agree that I was also surprised by the behaviour currently implemented by CaaS. This issue has been inactive for quite a while and actually closed. I wonder what the last decision on this topic was and whether there now is the possibility to skip the adapter (and enforcer) creation by the user?

from casbin-server.

The issue is still open. It's an unrelated issue that is closed. So there is no decision. I mean my proposal is not accepted so it's as it was. It could be accepted if I can manage to have both behaviour with a command-line param to switch from one behaviour to the other. I had no time to do that so I forked and use my custom version. Which is not really up-to-date.

from casbin-server.

OK, I'm happy to help out on a version which accepts both, if you're still interested in working on it, as we're currently facing the same issue for our product. It doesn't make sense, in production, to not have all the configuration and the adapter with the Casbin server itself. I ended up doing the same thing as you did and we're currently running a custom version of CaaS which obviously is not optimal for maintenance.

from casbin-server.

The client can call API to create an adapter instance at the server-side. So someone can even create a "controller" client to manage the instances of models, adapters and enforcers.

Of course, if you don't need this, you can just create a "static" set of instances from config or env vars. We want to support both modes.

from casbin-server.

@hsluoyz I'm sorry, I don't get it... I mean, I understand what you said, but I don't get why on earth someone is willing to do that over simply using the lib version of casbin which provide the exact same features, as it's the exact same public interface. I see no advantages of using the server version over the library version.

@rico-ci I'm personally still interested, but unfortunately I have no time at all to work on such a thing right now. If you want to do it, please feel free to do it using my work or not, as you wish. I'll be happy if such a thing is merged upstream so I can drop my fork and stop maintaining it.

from casbin-server.

Because enforceing policy is CPU intensive. Someone may want to use another machine to run the enforcement.

from casbin-server.

Closed as stale.

from casbin-server.