modular, yet standalone user system
- Synopsis: A system capable of tracking pages, regardless of their implementation.
Being that osc is (AND I USE THIS TERM LOOSELY) modular, this will permit root admins to assign base permissions to new and/or existing pages on the fly.
To define any number of exceptions to these permissions or user specific rules per page, applied/implied or imposed upon any group, individual or combination of the two.
Further, restrict [single] functions, buttons or links, anything that would submit data to be updated, stored or changed. This, is intended to prevent
or restrict site settings being altered, or people playing with things they shouldn't.
This includes the same abilities for child pages defined by ?action=this, etc. to be regulated specifically, if desired. Pages that consist of possibly
multiple files being included by any number of scripts, in very much the same manner. With or without individual restriction.
- User Access levels
Any number of named [base] access levels can be defined, on the fly by top level (root) admins. These levels will define an abstract
group, and the access staff assigned to this group will be permitted or denied as a result. This is a starting point, defining optional denial of
access or permission of access to individual pages (..or their children defined in the url itself, should that be the case) by default.
These groups can be assigned further specific restrictions or exceptions, as part of their base access class. These specific rules, as
defined on the staff access levels page, will be explicitly imposed upon staff members categorized as subject to them.
* User specific exceptions and restrictions - A staff access level can be further extended on a per user basis, indiscriminately.
No restrictions imposed upon, or exceptions granted to a single person will have any bearing on, nor inspire any consideration for other staff
members sharing that same access level distinction. In these cases, the root user defined access level, or group itself will serve truely as
a base. In a case where an exception or restriction, defined as part of a users assigned access level/group, as well as another specific to
the user exclusively are both relevent to the request simultaneously, the user specific definition will not only take precendence over, but will
completely override all related base access level distinctions. This is done as a further security precaution, to contain any potential abiguity
between them. So the desired result can be achieved.
User permission, a unique global flag used to categorize this user defined level. This, in the absence of further staff member/group specific
exceptions or restrictions, will be compared with page permissions and permit or deny access accordingly.
(User [base] permission respective to the pages in question are applicable to all staff implicitly, and those carrying relevent root user
defined exceptions explicitly.)
- Page Permissions
Individual pages and their children, can be assigned a numeric value to signify their base user permissions, or level of importance/security.
This is a relative comparison to another defined in the above 'user access level', which takes precedence. This only applies, should no user/group
specific exception or restriction be defined or relevent to the staffs request from this page. In which case, this will decide a
course of action based on this default permission.
- Default user access levels 'root', 'admin'
'root' provides implicit access to all of the site, it differing from a secondary 'Admin' level only by permitting access of root users
to the user access/restriction/etc controls pages that will be created, where rules applied to varying staff restrictions and
such can be defined, altered, added & removed. Also, access to controls for the staff accounts themselves, where they are categorized, managed,
added or removed.
- Greater security & flexibility
The Administration section of the site will be far better protected, if nothing else. Web session tracking filtered through a series of checks, to help
insure legitimacy of the session itself, and how it was aquired by the client with each new page they request. Account authenication failures, dead session requests
monitored and controlled, and this interaction ignored explicitly should it continue past an established threshold.
---
.htaccess based administration user management will be done away with. Replaced, by a system much more suited to the task, one with some intuitive understanding
of the admins and staff themselves, but sensitive to the data its intended to protect. Implemented in such a way that works to oversee actions taken by its users
and site itself, then react accordingly. As opposed, to tightly interweaving the existing site and the system itself. Inflicting upon us all, the inherent problems that are the
inevitable result of such a simpleminded approach. Such dependancies would only grow in number over time, and due to the nature of the internal systems
currently in place, or the very lack of any defined 'nature' to them. Such a sporadic methodology is impossible to compliment, or to even account for considering
the potential for future contribs, upgrades & other alterations. To avoid creating more problems, and more bulk, bulk that will inevitably need be rewritten, reimplemented or
manually adapted any number of times, along the way to compliment and regulate future additions.
This endless line of issues, that further serves only to create traps for still more problems, can only be at all avoided by a largely standalone approach.
One that provides root users full control over staff accounts, management of these accounts themselves, and intricate control over individual access permitted or denied their
respective owners. Allowing for action to be taken immediately,
as issues or conflict arises, through revoking or further limiting staffs access to data and/or forms by root users, on an infinitely variable scale.
One that maintains its own, comfortably along side the ever changing entity it is delegated to protect.
One never inhibiting the others potential, but complimenting it. Truely uniting all that is or will be, by imposing control and regulation upon it as a single entity.
As well as providing a series of classes containing the applicable tools & neatly packaged data necessary to get a quick and easy result, when/if special permissions or unique implementation is requested.
Continuing to allow the site to grow, to undergo any number of changes, additions or even upgrades while under this softwares reign.
This system itself, retaining the data it needs to do its job, and a further failsafe, to account for the potentially unaccounted for.
Should areas be moved, changed or be completely reformatted.. To still further adjust, by being at all capable of learning to adapt, expand and respond
under the slight instruction of its administration.
Yeilding a packaged, reliable, immediate, and largely self-maintained result.
- API