Revision [478]
Last edited on 2006-05-27 20:32:35 by KogAdmin [two new operations, increased explanation]Additions:
~~- ""ACLAddGroup""($token, $group)
~~- ""ACLDelGroup""($token, $group)
The last deviation, and perhaps the most trivial, from classic Unix permissions would be the lack of "execution" privileges - I see no need for this at the moment. There also should be no need for sticky bits, setUID or any of the other Unix permission set. Theoretically it's trivial enough to modify this to allow other permissions - just modify checkAgainstACL and any pretty printers of ACLs (each page will denote the ACL somewhere on it)
Perhaps a bitshift2 would come in handy for checking permissions?
~~- ""ACLDelGroup""($token, $group)
The last deviation, and perhaps the most trivial, from classic Unix permissions would be the lack of "execution" privileges - I see no need for this at the moment. There also should be no need for sticky bits, setUID or any of the other Unix permission set. Theoretically it's trivial enough to modify this to allow other permissions - just modify checkAgainstACL and any pretty printers of ACLs (each page will denote the ACL somewhere on it)
Perhaps a bitshift2 would come in handy for checking permissions?
Deletions:
Revision [474]
Edited on 2006-05-27 05:22:01 by KogAdmin [escape method names so they don't Wiki-link]Additions:
~~- ""ACLAddUser""($token, $user)
~~- ""ACLDelUser""($token, $user)
~~- ""ACLDelUser""($token, $user)
Deletions:
~~- ACLDelUser($token, $user)
Additions:
syncAccounts exists to make sure that your ACL tables (stored in Tracker) sync with your backend if it's not a source only accessed by Tracker. This solution seems a little rough, and will probably be smoothed out as time goes by. Basically it looks for names in your handler that aren't in ACLs, throws them in "all users" group and prunes usernames from ACLs no longer in your handler. It is conceivable that to settle disputes there can be a super-global timestamp somewhere in the app updated any time an auth handler needs to update something, and the newer set will be forced upon the user.
At a worst case scenario you'll have to manually delete the account, or modify the permissions within the software to prevent unauthorize access immediately.
A cronjob would be another way to solve this issue: build a cronjob with arbitrary resolution (every n minutes) that syncs the ACLS. This might be favorable, but will still not be in "realtime." Right now I know that the method should exist, but not necessarily the best way to implement it...
~- ACL Manager Methods derived from Unix
~- ACL Manager Methods unique to Tracker
~~- ACLAddUser($token, $user)
~~- ACLDelUser($token, $user)
Unlike traditional Unix, Tracker employs a multi-group and multi-user idea. Users must be unique (there'll be a constraint on it to insure integrity, but the app layer will also check), but a user may be in many groups with access. Since you can't explicitly deny a group you should never run into a cycle such that you both allow and deny a group (like other ACLs on other software). Also unlike a traditional Unix set of privs, there is no clear "owner" of the page - with the exception of personal pages, which will be treated as a special case.
Most pages will be deliniated as filtered for one person, or a global UI where the general user will only have read access (it'll act as a pure view). Administrators will be given read/write access to every page by default, managers will be given write access to the global UI pages. Non-staff users will be given view access to personal pages - another edge case to the permissions above.
The last deviation, and perhaps the most trivial, from classic Unix permissions would be the lack of "execution" privileges - I see no need for this at the moment. There also should be no need for sticky bits, setUID or any of the other Unix permission set. An upside of this is that since we only have 2^3 bits (2 choices, 3 groups) we can minimize storage. Theoretically it's trivial enough to modify this to allow other permissions - just modify checkAgainstACL and any pretty printers of ACLs (each page will denote the ACL somewhere on it)
At a worst case scenario you'll have to manually delete the account, or modify the permissions within the software to prevent unauthorize access immediately.
A cronjob would be another way to solve this issue: build a cronjob with arbitrary resolution (every n minutes) that syncs the ACLS. This might be favorable, but will still not be in "realtime." Right now I know that the method should exist, but not necessarily the best way to implement it...
~- ACL Manager Methods derived from Unix
~- ACL Manager Methods unique to Tracker
~~- ACLAddUser($token, $user)
~~- ACLDelUser($token, $user)
Unlike traditional Unix, Tracker employs a multi-group and multi-user idea. Users must be unique (there'll be a constraint on it to insure integrity, but the app layer will also check), but a user may be in many groups with access. Since you can't explicitly deny a group you should never run into a cycle such that you both allow and deny a group (like other ACLs on other software). Also unlike a traditional Unix set of privs, there is no clear "owner" of the page - with the exception of personal pages, which will be treated as a special case.
Most pages will be deliniated as filtered for one person, or a global UI where the general user will only have read access (it'll act as a pure view). Administrators will be given read/write access to every page by default, managers will be given write access to the global UI pages. Non-staff users will be given view access to personal pages - another edge case to the permissions above.
The last deviation, and perhaps the most trivial, from classic Unix permissions would be the lack of "execution" privileges - I see no need for this at the moment. There also should be no need for sticky bits, setUID or any of the other Unix permission set. An upside of this is that since we only have 2^3 bits (2 choices, 3 groups) we can minimize storage. Theoretically it's trivial enough to modify this to allow other permissions - just modify checkAgainstACL and any pretty printers of ACLs (each page will denote the ACL somewhere on it)
Deletions:
~- ACL Manager Methods
~~- chown($token, $str)
TODO: write about groups and ACL storage
Additions:
{{lastedit show="3"}}
== IAuth Interface ==
Tracker has a new auth interface: IAuth. Tracker stores the ACLs, preferences and all tracker-specific data (sans username/password) - but you can use an external source for authentication: via LDAP against AD/Radius, a flatfile, MySQL, .htpasswd files, /etc/passwd... anywhere. To take into account that some providers might have extra data that might be nice to have in Tracker there's getMetaData - this will retrieve data that isn't necessary to Tracker or authentication but your backend might have (OU data from AD for example).
syncAccounts exists to make sure that your ACL tables (stored in Tracker) sync with your backend if it's not a source only accessed by Tracker. This solution seems a little rough, and will probably be smoothed out as time goes by. Basically it looks for names in your handler that aren't in ACLs, throws them in "all users" group and prunes usernames from ACLs no longer in your handler. This could get a little interesting with succession of ownership.
~- Methods
~~- login($user, $pass) - attempts to athenticate against provider
~~- logout($user) - destroys local application data, analog within provider
~~- getMetaData($user) -
~~- providerName()
~~- providerVersion()
~~- register($user,$pass)
~~- unregister($user, $credentials)
~~- snycAccounts()
Since I'm using PHP5, this is actually an interface.
== ACLs and Credentials ==
I'm swapping out the current security system for ACLs and groups. ACLs will give you more flexibility, and groups are the natural extension of user ACLs. There will still be a dynamic linking system for building the menu that will evolve as time goes by, but it no longer has security bits and no longer needs you to put in invisible pages to do security checks - that was a quick hack.
~- ACL Manager Methods
~~- chmod($token, $str)
~~- chown($token, $str)
~~- mkgrp($name)
~~- rmgrp($name)
~~- group_add($name, $user)
~~- group_del($name, $user)
~~- getACL($token)
~~- checkAgainstACL($token, $credentials)
You'll notice that I've tried to use Unix names wherever possible (although, I've got two methods that use a different naming scheme - these are not Unix functions, so I'll keep to my normal naming convention).
TODO: write about groups and ACL storage
== IAuth Interface ==
Tracker has a new auth interface: IAuth. Tracker stores the ACLs, preferences and all tracker-specific data (sans username/password) - but you can use an external source for authentication: via LDAP against AD/Radius, a flatfile, MySQL, .htpasswd files, /etc/passwd... anywhere. To take into account that some providers might have extra data that might be nice to have in Tracker there's getMetaData - this will retrieve data that isn't necessary to Tracker or authentication but your backend might have (OU data from AD for example).
syncAccounts exists to make sure that your ACL tables (stored in Tracker) sync with your backend if it's not a source only accessed by Tracker. This solution seems a little rough, and will probably be smoothed out as time goes by. Basically it looks for names in your handler that aren't in ACLs, throws them in "all users" group and prunes usernames from ACLs no longer in your handler. This could get a little interesting with succession of ownership.
~- Methods
~~- login($user, $pass) - attempts to athenticate against provider
~~- logout($user) - destroys local application data, analog within provider
~~- getMetaData($user) -
~~- providerName()
~~- providerVersion()
~~- register($user,$pass)
~~- unregister($user, $credentials)
~~- snycAccounts()
Since I'm using PHP5, this is actually an interface.
== ACLs and Credentials ==
I'm swapping out the current security system for ACLs and groups. ACLs will give you more flexibility, and groups are the natural extension of user ACLs. There will still be a dynamic linking system for building the menu that will evolve as time goes by, but it no longer has security bits and no longer needs you to put in invisible pages to do security checks - that was a quick hack.
~- ACL Manager Methods
~~- chmod($token, $str)
~~- chown($token, $str)
~~- mkgrp($name)
~~- rmgrp($name)
~~- group_add($name, $user)
~~- group_del($name, $user)
~~- getACL($token)
~~- checkAgainstACL($token, $credentials)
You'll notice that I've tried to use Unix names wherever possible (although, I've got two methods that use a different naming scheme - these are not Unix functions, so I'll keep to my normal naming convention).
TODO: write about groups and ACL storage
Additions:
== AJAX ==
I'm attempting to integrate AJAX into Tracker - please view [[TrackerDBAJAX]] for details
I'm attempting to integrate AJAX into Tracker - please view [[TrackerDBAJAX]] for details
Additions:
== Porting to MySQL ==
For the time being, the queries are not incredibly complex, so porting should be easy:
~- Modify the table creation syntax: The types are a little different in the DBMSes
~- Modify the PHP function calls to be MySQL instead of PG: you might consider PEAR DB or writing something like what PasteBin did
That should do it for now. In the future I plan on adding things to Tracker that MySQL just can't do, and the project will probably rely heavily on databasing (this is, after all, my DB theory project) so you may not be able to actually port this code. MySQL5 and MySQL6 will see the implementation of the features that I'll be using, but I have no idea how they plan on implementing them, and if the grammar of the SQL will be anywhere near the same. Further, some of the stored procedures may, or may not be, in PLSQL - some might be in some of the other languages PGSQL allows you to use.
Porting will be tricky in later releases and may not be possible without moving logic from the DB to the application. If anyone would like to help me by working on MySQL implementations, please feel free to drop me an email (please see the project page for that). I'd be more than happy to work with someone on that.
For the time being, the queries are not incredibly complex, so porting should be easy:
~- Modify the table creation syntax: The types are a little different in the DBMSes
~- Modify the PHP function calls to be MySQL instead of PG: you might consider PEAR DB or writing something like what PasteBin did
That should do it for now. In the future I plan on adding things to Tracker that MySQL just can't do, and the project will probably rely heavily on databasing (this is, after all, my DB theory project) so you may not be able to actually port this code. MySQL5 and MySQL6 will see the implementation of the features that I'll be using, but I have no idea how they plan on implementing them, and if the grammar of the SQL will be anywhere near the same. Further, some of the stored procedures may, or may not be, in PLSQL - some might be in some of the other languages PGSQL allows you to use.
Porting will be tricky in later releases and may not be possible without moving logic from the DB to the application. If anyone would like to help me by working on MySQL implementations, please feel free to drop me an email (please see the project page for that). I'd be more than happy to work with someone on that.
Revision [102]
Edited on 2005-06-18 15:13:56 by KogAdmin [initial edit - moved content off proj page]Additions:
==== TrackerDB Developer Documentation ====
== Why PGSQL ==
At the time that I started writing this MySQL was just releasing 4.1 as alpha quality, and MySQL as we all know is missing quite a few features - triggers, real constraints, views, stored procedures and all the rest. I was writing this for a DB theory course mandating I use these features, so after writing a portion of Tracker in MySQL I ported it to PGSQL and I've been fairly happy with the results.
Many people tout MySQL as being so much faster, but in all honesty I'm writing this system for small companies to track work orders - I'm not really concerned with the handling of N connections, although I do believe that PGSQL would be more than fast enough (especially the 8.x branch). I'm writing some things that will be nice for companies and rather than doing it all in the application layer, I'd rather have it done in the DB as it should be. There's also a distinct possibility it will be rigged to do financial data, and there are some interesting reasons for using stored procs for "security" - needless to say one needs transactional support for such things.
PGSQL is harder to find a host for, it's true. All the sites love to use MySQL because it's easier (no pg_hba.conf) and supposedly better. I'm contemplating how to offset this for small hosts, and I plan on putting it up on the help section when I figure it out. The good news, for a lot of small companies, is that PGSQL is now Win32 native so they can easily run a server in their office environment.
== Why PGSQL ==
At the time that I started writing this MySQL was just releasing 4.1 as alpha quality, and MySQL as we all know is missing quite a few features - triggers, real constraints, views, stored procedures and all the rest. I was writing this for a DB theory course mandating I use these features, so after writing a portion of Tracker in MySQL I ported it to PGSQL and I've been fairly happy with the results.
Many people tout MySQL as being so much faster, but in all honesty I'm writing this system for small companies to track work orders - I'm not really concerned with the handling of N connections, although I do believe that PGSQL would be more than fast enough (especially the 8.x branch). I'm writing some things that will be nice for companies and rather than doing it all in the application layer, I'd rather have it done in the DB as it should be. There's also a distinct possibility it will be rigged to do financial data, and there are some interesting reasons for using stored procs for "security" - needless to say one needs transactional support for such things.
PGSQL is harder to find a host for, it's true. All the sites love to use MySQL because it's easier (no pg_hba.conf) and supposedly better. I'm contemplating how to offset this for small hosts, and I plan on putting it up on the help section when I figure it out. The good news, for a lot of small companies, is that PGSQL is now Win32 native so they can easily run a server in their office environment.
