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.
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 promer 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.
Resolve: Create a new hierarchy where my modules 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:
So, 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: This is both I/O so I need to make everything available.
I came up with “data residuums”. Basically, if the user-level module is interested in the inner-workings / 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 it 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 an in-memory 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.
Given all these issues, what is a pattern or a solution that I can use or rather, how should I think about things when writing my modules?
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?