If I understand correctly, the idea is to include "_restrict.php" in all pages you want restricted, then just *NOT* include it in pages you want viewable by anyone.
But is it possible to configure specific pages in the PSA database as "unrestricted" and viewable by users who are not even logged in?
This would allow the use of a generic template that includes "_restrict.php" on every page on a site, but still allow some of those pages to be viewed by users who are not logged on.
My aplogies if I simply don't understand the intended implementation very well. I am totally new to this ... it looks great, but I'm just now experimenting my first implementation.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
As the PSA project is right now, you only include the _restrict.php file in those page you want to force a login for.
To do what you are suggestiong, you'd have to create your own scripts. The key thing to realize is that this project is actually just the class, not the UI pages. Those are simply provided as "examples" (which actually work quite well).
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Thanks for the reply! I created a simple hack to simulate this functionality ... I created a "nobody" user and profile, then modified "_restrict.php" to force a login with that username when no other user is logged in. I can now use "_restrict.php" in a general template, then use the profile to control what pages "nobody" sees.
But now that someone is *ALWAYS* logged in ... I can't simply check for "!$PSA_SYS->isLoggedIn()", I must also make sure that "$_SESSION['PSA_psaun']!='nobody'".
The reason I am going to this trouble is that I don't want to accidentally "expose" a page by simply forgetting to include "_restrict.php". I can bury content in .htaccess-protected subdirectories to force access through a template wrapper. Some pages should be viewable by anyone, but this lets me explicitly specify which ones.
Support for a "nobody" profile could be built into the class directly. Would you be interested in seeing some sample changes to accomplish this for some future release? Or, is this a bad idea? (No offense will be taken <smile>.)
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
I'm not sure that I like someone always being logged in or not. However, I would be interested in seeing what you came up with.
My last idea about this was to implement some kind of per-url permissions where when entering pages into the system you'd also have a couple sets of checkboxes that defined access privileges based on a group or user level check of some sort. Maybe the first implementation should just be based on a logged in/out basis and expanded from there.
Anyway, send the code and I will take a look at it. Right now, I am keeping PSA for php 4.x, but will eventually make a php 5 version as well (which may use SQLite instead of a database abstraction layer).
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
I had to create a "nobody" user that is always logged in to accomplish what I wanted the way PSA works now. But, if PSA were to include support for "anonymous" access, that wouldn't be necessary.
Basically, you would just need to support the concept of a special profile ("Everybody"? "Anonymous"? "Nobody"?), and any pages included in that profile would be shared even if the user was not logged in.
This would allow the use of a generic "_restrict.php" wrapper for all pages on a site, but would allow anonymous access to the main page, login page, etc.
It's the same concept, but you could use the permissions checks you mentioned to implement this by defining a "Protected?" toggle in the page database. Just turn off "protection" for a page, and "hasRights" would return TRUE for any user, even those not even logged in.
By the way, I should say ... PHA is really nice! Once you get it implemented, being able to check a user's group or build dynamic menus based on "hasRights" checks on each item is very simple.
Great job.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Interestingly, I may actually have a use for that for a project that is coming up. ;)
If I do the implementation, I will be sure to upload it in a new beta release. I've been impressed at how few bugs I've found in the new versions of PSA since the switch to MDB. I figured that I'd have a log of cleanup to do.
It looks that my servers will be hitting PHP5 soon, so once this version leaves beta, it will likely be the last one that'll run on PHP4 as I will do a complete audit of the source (again) for version 5.
This project has taken a lot of work, but I am pleased at how well it was received (especially by those that have helped out!).
Thanks.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
If I understand correctly, the idea is to include "_restrict.php" in all pages you want restricted, then just *NOT* include it in pages you want viewable by anyone.
But is it possible to configure specific pages in the PSA database as "unrestricted" and viewable by users who are not even logged in?
This would allow the use of a generic template that includes "_restrict.php" on every page on a site, but still allow some of those pages to be viewed by users who are not logged on.
My aplogies if I simply don't understand the intended implementation very well. I am totally new to this ... it looks great, but I'm just now experimenting my first implementation.
As the PSA project is right now, you only include the _restrict.php file in those page you want to force a login for.
To do what you are suggestiong, you'd have to create your own scripts. The key thing to realize is that this project is actually just the class, not the UI pages. Those are simply provided as "examples" (which actually work quite well).
Thanks for the reply! I created a simple hack to simulate this functionality ... I created a "nobody" user and profile, then modified "_restrict.php" to force a login with that username when no other user is logged in. I can now use "_restrict.php" in a general template, then use the profile to control what pages "nobody" sees.
But now that someone is *ALWAYS* logged in ... I can't simply check for "!$PSA_SYS->isLoggedIn()", I must also make sure that "$_SESSION['PSA_psaun']!='nobody'".
The reason I am going to this trouble is that I don't want to accidentally "expose" a page by simply forgetting to include "_restrict.php". I can bury content in .htaccess-protected subdirectories to force access through a template wrapper. Some pages should be viewable by anyone, but this lets me explicitly specify which ones.
Support for a "nobody" profile could be built into the class directly. Would you be interested in seeing some sample changes to accomplish this for some future release? Or, is this a bad idea? (No offense will be taken <smile>.)
I'm not sure that I like someone always being logged in or not. However, I would be interested in seeing what you came up with.
My last idea about this was to implement some kind of per-url permissions where when entering pages into the system you'd also have a couple sets of checkboxes that defined access privileges based on a group or user level check of some sort. Maybe the first implementation should just be based on a logged in/out basis and expanded from there.
Anyway, send the code and I will take a look at it. Right now, I am keeping PSA for php 4.x, but will eventually make a php 5 version as well (which may use SQLite instead of a database abstraction layer).
I had to create a "nobody" user that is always logged in to accomplish what I wanted the way PSA works now. But, if PSA were to include support for "anonymous" access, that wouldn't be necessary.
Basically, you would just need to support the concept of a special profile ("Everybody"? "Anonymous"? "Nobody"?), and any pages included in that profile would be shared even if the user was not logged in.
This would allow the use of a generic "_restrict.php" wrapper for all pages on a site, but would allow anonymous access to the main page, login page, etc.
It's the same concept, but you could use the permissions checks you mentioned to implement this by defining a "Protected?" toggle in the page database. Just turn off "protection" for a page, and "hasRights" would return TRUE for any user, even those not even logged in.
By the way, I should say ... PHA is really nice! Once you get it implemented, being able to check a user's group or build dynamic menus based on "hasRights" checks on each item is very simple.
Great job.
Interestingly, I may actually have a use for that for a project that is coming up. ;)
If I do the implementation, I will be sure to upload it in a new beta release. I've been impressed at how few bugs I've found in the new versions of PSA since the switch to MDB. I figured that I'd have a log of cleanup to do.
It looks that my servers will be hitting PHP5 soon, so once this version leaves beta, it will likely be the last one that'll run on PHP4 as I will do a complete audit of the source (again) for version 5.
This project has taken a lot of work, but I am pleased at how well it was received (especially by those that have helped out!).
Thanks.