Important note: This is PHP (5.3+). PHP is stateless and everything you do dies when the request is over unless saved to a persistent storage, but if the answer provided gives me pseudo-code, I'd also be happy. Also, I can't use routing. I need something that deals solely with objects and parts of them.
My system right now can register a module and set its usage permissions, e.g: who can access this module's functionality based on a pre-defined set of rules, but generally, most of the time we'll just be looking for whether the requester is an user or an administrator.
Thing is though, I realized this late that there's a potentially big problem: if I register a module as admin-level, the permissions are then set at the moment that module initializes, there's virtually no way for my user-level modules, or really anyone without proper permissions to interact with them, even if these unprivileged parties have a real reason for it, as such, a few points up until now:
Point 1: Well, maybe if an u-level module has to interact with an a-level, then that a-level really shouldn't be an a-level module. As it stands right now, when the user logs in and the modules are loaded, this is how it looks:
The user can't even find the module, because it's not there. The system decided, based on his credentials & additional checks to not even instantiate the module.
Resolve: Create a new hierarchy where my modules now are open for everyone but have sub-modules or partitions and if one of them deviates from the inherited parent-module's permissions, you have to write that by hand, it'd look like this:
Now, the big module has no permissions set, but the sub-modules do and they're being checked every single time the user accesses them.
This seems to solve the issue, but only at a surface level because it lands me back to the issue of me having to check every time I access a resource:
Point 2: I can maybe skip all of this if I just store, in my database, whatever an a-level module decides it's necessary to let others know about.
I came up with "data residuums". Basically, if the user-level module is interested in the output of the admin-level modules, that admin-level module can spit out "registries" of data that it updates whenever it has to and whoever is interested in these can just check them. This way, it's ensured that, no matter what happens, I can still access the admin-level module's data if I need, but I won't be able to interact with its inner-workings. I'll be able to see (some) of them, but this way, I can ensure that low-privileged users can't suddenly make admin-level changes on my site:
So, the a-level module does its things and at the end of it all, it saves that output to storage that anyone interested in can access.
But this means that I can't really call everything that I'd want because once the a-level module is done running its internals, it's over.
This also means that I'd need my a-level modules to run first, just to ensure that the u-level modules actually have data to work with. This is incompatible with what I currently have.
I was thinking that, even if I believe PHP doesn't allow it, maybe "attach credentials" to every important call that's made:
But then again, this still requires me to do a check on every call.
I guess, really, I'm looking for a way to establish identity and it being handled automatically when making calls.
I know this is already extremely long, but an example would be an a-level module that deals with generating suggestions based on the application's ever-changing state with possibly sensitive data, let's call this
SuggestionsModule. Now, if I allow everyone to have access to
SuggestionsModule\Register\addSuggestion, I give everyone the possibility to add suggestions, **unless I add a check for this exactly
addSuggestion and here the problem becomes even worse: at times, these sub-module's functions will have checks on their own. What if a sub-module is fine to load for user-level, then I hit a function that's very sensitive? I have to write a check and this is what I'm trying to avoid - pollution.