I’m not sure whether I follow “per page”, what exactly do you mean.
Are you saying so some pages require you to be logged in and some don’t or some pages require specific permissions to view?
The way my framework functions is kind of like this:
index.php (entry script)
–> Include the core framework
-----> Initialize the system (fetch settings, config, initialize the template engine etc. the global stuff thats needed all the time)
-----> Establish a DB Connection
-----> Handle user authentication (sets up the user be they a member or guest, grabs their permissions (granular))
-----> Fetch the bootstrapper for a given ‘component’ or ‘module’ (i.e. articledisplay)
-----------> Include the backend classes for this ‘component’ or ‘module’ and initialize/process whatever it needs to in the pre process
-----------> Checks permissions, does the page stuff or whatever it needs to do based on the rules for that module
-----> The UI is constructed and outputted via the template engine.
So I have a granular permissions system so you have a usergroup structure thats something like this:
USERGROUP (i.e. member)
— Array of Permissions
PERMISSION
— UserID
— Array of Permissions
PERMISSION overrides USERGROUP, though they have the same perms. So the USERGROUP itself is the “default” permission set for a given user (based on the users group) but you have PERMISSIONS which is a per user override, so a particular user could be a “Member”, but certain permissions are adjusted specifically for that user.
The permissions themselves are somewhat multi-dimensional, so you not only have linear permissions (using a forum as an example) like “view forum” and “post thread” but a copy of those permissions (in both USERGROUP and PERMISSION) for each individual forum.
So if you had 8 forums, 1 of them is only visible to members, 2 are only visible to administrators you can do that, or you could specify select users (say an administrator forum for two of your admins, who are the head honcho’s or a VIP forum).
Then at the script level, each module has a set of permissions that are used, when the user is signed in, the permissions are loaded in; internally there are only one set of permissions (one array), which set depends on what exists (i.e. if a permission (custom) set exists they are used, else the usergroup default are used).
The module then checks the users permissions whenever the user attempts to commit an action. If the user doesn’t have permission to do it, in a messaging class there are a bunch of “message” methods, one of which is “printNoPerission()”, which is called. This stops the process and displays the no permission message. The exact wording of which is decided by a parameter passed to the method, along with a parameter of whether to offer login (in which case a login screen or link is available if they are a guest).
The way login authentication works is something like this (there are some nuances of my authentication system that are specific to my platform, logins are session and database backed, using a cookie for persistent logins):
- User has a cookie which contains the login credentials (in key form), this is for persistent logins
- A matching session (which is actually optional, you can bypass this and use database session and vice versa, so ignore the DB session)
- A matching database session
The authentication system checks for a session and compares the keys to authenticate, if the login session is valid and not expired then the user is logged in, otherwise their login is expired and they are a guest.
During login the permissions are set, so its not as simple as “logged in” or “not logged in” or “member” or “guest” as the usergroups are both extendable and you can create custom groups. There is more to it than that, but I think that describes it sufficiently enough to get a “model” across. Of course how you authenticate the session, how you structure keys and how you prevent full authentication on a per page load basis (if you want to prevent it at all) will be system/framework dependent.
You can go simple and just use a session to maintain the users login, but for my framework its a bit too simplistic. Also there are a few issues with just doing that, it needs to be validated somewhere and hijacking needs to be prevented somewhere.