CAMI Privileges not being handled correctly
bigdogmat opened this issue · comments
Steps to reproduce
- Register a privilege using
CAMI.RegisterPrivilege, set MinAccess touser - Remove privilege from group
userusing something such as ulx menu - Call
CAMI.PlayerHasAccesson a player that has the rankuserand pass the registered privilege
Expected behavior
The callback should be called with false
Actual behavior
The callback is called with true
Version
Latest
To give the detail behind this look here, this is what prevents the default CAMI function from handling the check. The reason this falls on it's ass is because ULib.ucl.query returns nil when it assumes a players group doesn't have access (as noted here). Because of the above the default CAMI handler function is used, and because of the MinAccess group, it calls the callback with true.
I'm guessing a real fix to this would be to use ulx in any case instead of the default CAMI handler, or return false instead of nil in ULib.ucl.query. Considering I'm not sure I'll leave this for you to fix
That is a very interesting conflict. There's no straightforward solution since CAMI must have a minimum access (it doesn't allow free-floating access like ULX does). Returning false instead of nil for "no information"-access would have other consequences. Probably the best way forward would be to convince @FPtje to make MinAccess an optional field. Thoughts, @FPtje?
This is not a "no information" case. I've tested it with FAdmin, and here's what it does:
- Register privilege with CAMI,
MinAccessbeing"user" - FAdmin registers the privilege and gives it to every group inheriting from user and up (you have to restart to see this clientside, but w/e). It thus treats the
MinAccessfield as a default/initial setup. - Remove the privilege from user (from the FAdmin "Edit groups" menu)
- FAdmin removes the privilege from the user. This means people with usergroup
userdo not have access anymore. - Groups inheriting
userdo still have the privilege. After all, they got the privilege from when it was created, and removing it fromusershould not remove it from inheriting usergroups. This is a design decision. I think it should be OK for ULX to decide to do this in another way. - Call CAMI.PlayerHasAccess on a player that has the rank user and pass the registered privilege
- FAdmin returns false.
MinAccess exists for two reasons: for admin mods to know the preferences of the privilege's author on what the default rule should be and as a fallback. The bug described in this issue occurs when the MinAccess is treated as permanent truth. After all, even after removing the privilege from user in ULX, the MinAccess being set to user is still considered true, causing ULX to return true when asked if user still has that privilege.
Making MinAccess optional would not affect this issue. The issue occurs when MinAccess is set to user and some superadmin presses some buttons in the ULX menu. Making it optional will not prevent addon authors from setting MinAccess to user. Also, making it optional would create quite a few new problems, with there not being a default/fallback access anymore. How would the CAMI fallback decide whether a player has a privilege that doesn't have MinAccess set? Abritrarily return true or false? Bound to be confusing for everyone involved.
@FPtje has weighed in, this issue will remain. Sorry we can't help further @bigdogmat.
But you can help by fixing this in ULX?
There's nothing to fix in ULX. I could try to hack around CAMI's implementation, but I refuse to do that.
surely removing a privilege from user should deny user that privilege. There's no hacking to be done anywhere. FAdmin does it right, so why can't ULX?
Because of @Nayruden, DPP would not work with ULib. Sorry, @bigdogmat
Hold on with that politics stuff just yet, I think there might be a misunderstanding.
What is DPP?
some prop protection
@Nayruden, ULib does NOTHING when third party addon asks for some permission when it was denided from player group, and returns true if player or his group have that permission. Understand?
No. Please explain what you mean, @roboderpy. Is your comment related to DPP? If there's a conflict, please open a new, separate issue and we will investigate.
He's referring to this very issue.
Create privilege.
Grant acces to it in ulx group settings. - Returns true!
Deny access from it by deny acces from entrie player usergroup. - Returns nil!
Deny access by ulx userdeny. - Returns false!
This is not a conflict, i came here because @bigdogmat was unable to restrict access in DPP using ULX.
Basically ULX should not let the CAMI fallback decide whether a user has a privilege. The CAMI fallback is a fallback for when there's no admin mod installed.
Instead of returning a boolean conditionally, it should always be returned. That way, the CAMI fallback will never "conflict" with the admin mod.
No need for the passive aggression, @roboderpy. I think I've figured a way to work around CAMI that will make everyone happy.
the words "work around" worry me.
wow, you really fixed it. But you was able instead of not not use result or false
Thank you