PostNuke
Flexible Content Management System
News
Post-Nuke User System Overview and Roadmap
There are several base classes in the .../html/auth/ directory that define the structure of each component of the user system. They are well commented as to what each method does and what each class is designed to do.
Classes exist to extend these base classes to provide specific functionality. The first such system is a combination of PHP4 session management, PHPNuke compatible user information, PHPNuke compatible user authentication, and PHPNuke compatible user authorization.
After this has been tested some I write a privilege_information class, and present a starter list of privileges that we will need to define for each action or decision in Post-Nuke that could be affected by user rights.
When that is done, we alter Post-Nuke on a large scale, turning code that works with sessions, cookies, user authentication, and so forth into appropriate calls to the user system.
Thus far, this effectively upgrades and tests Post-Nuke with the new user system without disturbing existing databases on production sites that are following Post-Nuke's progress. Existing admin tools will still work too.
The next step is another wide-scale alteration:
First, the list of privileges is inserted into a privilege database. An admin interface is designed to manage this database which contains the default ACLs used for each privilege, or action that can be taken, in Post-Nuke. The default ACLs will initially mirror the existing PHPNuke style authorization scheme.
Second, the Post-Nuke code is modified in many places to check for appropriate authorization in order to perform certain tasks. When done, this will have the effect of still keeping existing PHPNuke user databases compatible, while now not only using new authentication and authorization code, but using the ACL/privilege system as well.
Time for the next generation:
Figure out all the cool stuff we want to put into the PostNuke user system. Like groups, timed subscriptions, and the like. We would also spend time making sure the database design was efficient, sound, and scalable. Some time should be spent on writing some good caching and speed optimization for the "next-generation" PostNuke user system at this point as well, to keep everything snappy.
If anyone has any comments or questions, please reply to the mailing list, message boards or article; I'm posting this at each location :-)
Note to self - I still need to add: methods to delete users in user_information, methods to add new users in user_information, new table to support arbitrary user variables within phpnuke_user_information
Classes exist to extend these base classes to provide specific functionality. The first such system is a combination of PHP4 session management, PHPNuke compatible user information, PHPNuke compatible user authentication, and PHPNuke compatible user authorization.
After this has been tested some I write a privilege_information class, and present a starter list of privileges that we will need to define for each action or decision in Post-Nuke that could be affected by user rights.
When that is done, we alter Post-Nuke on a large scale, turning code that works with sessions, cookies, user authentication, and so forth into appropriate calls to the user system.
Thus far, this effectively upgrades and tests Post-Nuke with the new user system without disturbing existing databases on production sites that are following Post-Nuke's progress. Existing admin tools will still work too.
The next step is another wide-scale alteration:
First, the list of privileges is inserted into a privilege database. An admin interface is designed to manage this database which contains the default ACLs used for each privilege, or action that can be taken, in Post-Nuke. The default ACLs will initially mirror the existing PHPNuke style authorization scheme.
Second, the Post-Nuke code is modified in many places to check for appropriate authorization in order to perform certain tasks. When done, this will have the effect of still keeping existing PHPNuke user databases compatible, while now not only using new authentication and authorization code, but using the ACL/privilege system as well.
Time for the next generation:
Figure out all the cool stuff we want to put into the PostNuke user system. Like groups, timed subscriptions, and the like. We would also spend time making sure the database design was efficient, sound, and scalable. Some time should be spent on writing some good caching and speed optimization for the "next-generation" PostNuke user system at this point as well, to keep everything snappy.
If anyone has any comments or questions, please reply to the mailing list, message boards or article; I'm posting this at each location :-)
Note to self - I still need to add: methods to delete users in user_information, methods to add new users in user_information, new table to support arbitrary user variables within phpnuke_user_information
Module Validation ...
These graphics could work similarly to w3 html / CSS validation, clicking on them would take you to a php page that displayed the database entry on postnuke.com showing the module in question was postnuke validated.
This would enable the team to promote a voluntary standard for postnuke modules, and also "move the goalposts" if necessary by publishing new standards to correspond to necessary changes in the PostNuke infrastructure (as w3 also do with HTML and CSS versions).
So "PostNuke 7.1 Valid" images with links to postnuke.com to back it up !! Any takers ?
This would enable the team to promote a voluntary standard for postnuke modules, and also "move the goalposts" if necessary by publishing new standards to correspond to necessary changes in the PostNuke infrastructure (as w3 also do with HTML and CSS versions).
So "PostNuke 7.1 Valid" images with links to postnuke.com to back it up !! Any takers ?
Page 254 / 277 (2531 - 2540 of 2763 Total)
