“checking for permissions on client side” seems a bit weird, especially as the authority for the ACL is the server. I believe the intention is that if you’re going to bind an access control entry to affect client logic, you’ll have the server tell you the state of the relevant ACE, either on request or on update.
The first obvious solution to making this easier this would be to have the server automatically notify clients of all changes to their ACL but this may also unintentionally disclose secret information. An access control list is unopinionated, a resource may store state as an ACE which is not meant to be seen by the player it is stored on.
Even if that wasn’t an issue, it would be unhelpful to further lure people into a false sense of security where the trust is put in client controlled logic. A modified client could very easily report to client scripts that they are allowed to perform an action when, in fact, they are not. On the server however it would be impossible for a modified client to simply report to have permissions they do not as the server is the authority, not the client.
I’m making an administration menu and I want to check access to an item on client side and then on usage actions obviously double check it on server.
For now when I’m constructing menu i need to call a lot of callbacks that returns only IsPlayerAceAllowed, wich isn’t good networking practice. Instead i want to simply use one native on client side wich will do the same thing, but without for example 100 C → S, S ->C events in one second.
In my opinion the purpose od having that kind of native isn’t a security reason, but kind of someting like my purpose - checking initial access for enabling/disabling menu items.
This isn’t a ‘bug’, this is intentionally not implemented at this time (as synchronizing part of an ACL that applies to certain principals only is a somewhat failure-prone scenario, and this is a relatively rare request + server owners wouldn’t want their ‘full’ ACL to be ‘sent to every client’, so this kind of evaluation would need to account for a lot of scenarios).
Doing so is somewhere on the todo list, however, but it’s not a very high priority (you’re probably the fifth person asking thus far, since ~2017). As an alternative to ‘calling a lot of callbacks’, however, you could also batch checks, and tell clients their ‘effective’ access in advance, like for example vMenu does.
Moving to the ‘feature requests’ section, however.
Addendum: I removed a ‘solution’ marker on my post as it is actually not an implemented feature. A ‘like’ could work as a replacement.