Wishlist
Here is a freely editable list of the features you would like to see integrated in PEAR::LiveUser (as a side note you can just write your first name next to the entry. Generally it is however recommended to file a feature request bug report on the PEAR::LiveUser or PEAR::LiveUser_Admin official bug site.
Boy, This thing promises so much and delivers so little.USER DOCUMENTATION IS SORELY NEEDED.
LiveUser: Not Ready For Prime Time!
- lukas: have you looked at the documentation section? especially the link to http://www.gvngroup.be/doc/LiveUser/index.php?
- moya: I've spent hours there. They have the same problem: they expect that their readers already know the subject.
Jim: I'm finding it easier to study the code :-)
Wishes:
1) CLEAR definition of database fields. (you need a database named this, with tables named this, with fields named this populated with this data. I don't want to learn xml, I just want an authentication system that works.
- lukas: what does that have to do with xml? if you are talking about the install.php that generates xml schema files, then you are missing the point:
- this script means exactly that you do not need to deal with xml yourself
- instead the script takes all your config options and creates a customer SQL file or directly installs it into your database server
Jim: Straight SQL examples for other supported back ends are needed. My problem was that I'm not using MySql? and trying to port to Postgresql blindsided me where int(1) had to become boolean for the "active" field. It quietly rejected logins without throwing any errors until I tracked it down. The script is a nice option, but many are use to creating their own SQL in its several varients.
- moya: demodata.php is where I got stuck and which prompted me to write this original thread. I think that LiveUser (and other pear modules) should make MINIMAL use of other pear modules since they're all in various, unknown, stages of completion. I got a very cryptic message saying something like 'yada on a non-object'. In other words, not very helpful. From this I conclude that MDB2 is also 'not ready for prime time'.
2) CLEAR definition of ALL pear (AND OTHER) dependencies. Right now trying to autoread the xml definition makes a silent error if all the pear modules required are not there.
- lukas: do you know how to use the pear installer? an explanation of the pear installer is available on the pear website. we feel that its a sufficient standars that we can expect users to know how it works. it makes no sense to rehash this in our documentation.
- moya: Why not rehash it? Not everyone is a smart as you.
3) Make an example with the MINIMUM conf file that uses a mysql database. It's neat that you can alias field names but WHO CARES!
- lukas: yeah we need an example with a minimal config. i am not going to bother with supplying rdbms specific schema files though. but others have provided such things already. for example in the documentation section on the wiki
- moya: LiveUser, like other pear modules, is intended to be a 'black box' and as such the developer should not expect the user to ever open the module files in an editor.
I think that before design can proceed developers need a definition of what they're working on. Without this, this project is doomed to never end.
STOP CODING AND START WRITING DOCS AND (SIMPLE) EXAMPLES.
- lukas: the problem is not missing documentation. i think we have documentation on every aspect of liveuser already. the problem is just that its scatter across multiple documents. i tried to piece these together a bit in the official pear manual. someone just needs to invest the time to take all the content available and make a single consise document out of them inside the pear manual. you are invited to help.
- moya: THE PROBLEM IS MISSING DOCUMENTATION.
Ephraim F. Moya
http://moya.us/
A simple stand-alone user/group/permissions editing front end would be nice. That way we could see some UI code that allows for editing the complexities of assigning users to groups, assigning permissions to users & groups, etc. I realise that there is something like that in WebBuilder2? -- can it be extracted and put somewhere within the LiveUser wiki?
-Del
Jim: I will have a working example of this by the time I finish my current project. I would be no more than customizable example code, but where is tha best place to post it?
The "application" table and the "area" table are not well integrated into the rest of the LiveUser classes even in the Complex permissions model. So, for example, if there are multiple applications on a site it would be preferable to have per-application users rather than a set of users that can access all applications.
- lukas: this sounds like an interesting idea. for now i would suggest to get this functionality by writing a custom auth container based on one of the existing containers. inside the readUserData?() method you would simply have to join to a relationship table linking auth_user_id's to application_ids. now the key thing missing is a way to specify the current application, which could be handled by a custom config option for that auth container.
The user editing is very monolithic -- a user with "admin" access can edit all users & groups -- it would be preferable to have a permissions module where certain users could edit objects within their own area / application only, and were not able to make changes to users that were outside of that area. Building that type of functionality in requires changes to the database structure, e.g. creating link tables between areas / applications and groups.
- lukas: LiveUser intentionally leaves this out. The idea is that ownership is to be stored and retrieved independently of LiveUser. LiveUser does support right_level's in order to make it possible to allow application of certain rights based on user/group ownership of entities.
-Del
Not everyone likes or uses MDB2, so having some database schemae that work with PEAR::DB or plain old MySQL? would be useful. The XML schemae are not easy to work with if you don't have MDB2 installed.
- lukas: The installer works for PEAR::DB, PEAR::MDB and PEAR::MDB2. The problem with providing anything else is in the fact that the schema depends on your config options and the backend you choose to use in the end. However I will add a mode for the installer that will generate SQL files instead of installing the schema directly into the database.
-Del
I realize the documentation has yet to be completed for the new LiveUser classes with the Admin module split off. My request for the wishlist would be for external links, or perhaps a forum where I can post questions with the possibility of getting answers. I cannot seem to find anything 'googling' for it.
How about a way to validate a username / password without logging the user in. This would enable confirming logins for high security sections, or (as in my case) check the current password before allowing a user to change it.
-Ben
I noticed in the LiveUser.php file has constants defined at the top for user types and such that increment in values. I'm still getting familiar with the code, so this might be a dumb question, but how come they're not in a more binary format like 1,2,4,8,16,32,64,etc so rights could be combined 32+8+1=41. Then 41&2=0 (false in a check for right number 2) and 41&8=8 (true for right number 8). The way it is now, as a masteradmin you assume a master has the rights of a regular admin, but if you could combine the masteradmin rights and regular rights, a check against the combined rights for regular admin would be true if that's all you needed to access that area instead of having to check for master and working backwards. --deekayen
- lukas: This is unfortunately not possible to do efficiently within a relational database. However users are free to implement a conversion function that would accept a binary format like yours (or even a string) and convert that to an right_id (either an integer or an array of integers).
For the love of god, post some code examples! These are sometimes more important to programmers than lengthy documentation. In the meantime, I'm going to be using another package because this is lacking here.
- helgi: We have quite many examples for both LiveUser and LiveUser_Admin and they come with those packages when you download them, they reside in the docs dir
Would like to be able to support 'weak' authentication like identd for some pages and 'strong' (password) authentication for others. This should be selectable on a per module / per file basis or by Apache enviroment variables. (Tomas.Doran@nta-monitor.com
- helgi: this item is on the roadmap FYI :-)
I would like to have up to date complete documentation with examples (HR)
- helgi: Well we have examples in the releases :) And some outdated API documents and tutorial, all the developers don't have time to write a good documents so we want to ask the users to help! :)
I am thinking about using LiveUser in a project. I have to ensure using it the right way, but without documentation I see no possibility to do that. Also I am getting nervous when I hear about API changes. OK, this package is still in beta state, but do you try to held backward compatibility? Unfortunately I do not have much time at the moment otherwise I would like to contribute some documentation etc. to the project.
- arnaud: the roadmap needs to be clearly defined indeed. We are working on it
I'd like to have all the remove functions (removeUser, removeApplication,...) autodetect wether the corresponding object id, or, to be added, the definestring was supplied as parameter (without running a define generating script). So I can write $InstanceOfPermAdmin?->removeRight('DELETE'); (schnirkel)
- we will probably not support the option of autodetecting, but I can see that we optionally allow to use some other field instead of the right_id field for the keys in the internal array. this would enable you to either use right id's or the define name. in that case the define name's would need to be unique. we dont want to have too many if's in the client code inside the check methods, but I can see us putting in a few options in the reading code (especially since we are adding more sophisticated caching support)
looking at http://phpgacl.sourceforge.net/ I found one nice feature:
- User definable "Access Request Objects" (ARO). These are objects which request access from an "Access Control Object" (above) examples would be:
- Users/Accounts
- IP Addresses
- Browsers/Browser capabilities (JS/Flash/DHTML)
- If I understood things correctly you can authenticate to multiple ARO's at once. I am not sure how this is achieved in side the phpgacl code but in LiveUser maybe what makes the most sense is somehow being able to handle stuff like IP and Browser stuff as groups which are determined within the perm container before reading the group rights.
Add an XML-RPC server to allow remote authentication and access checking.
- arnaud: we are currently working on refactoring the internals to make it easier to write containers. We expect to see more containers after that.
The possibility to restrict user login to a single session could be nice. At this time it's possible to login twice from two different locations with the same login/pass , it would be cool to be able to avoid that.
- one easy solution is to handle the issue using the up coming observers in conjuntion with a custom session handler that associates session id's with a given user id
What do you guys think about integrating an OpenID? (http://openid.net/) cross-server authentication module with the LiveUser framework. My pet project http://xprofile.berlios.de/ provides an LID+OpenID? implementation - it is far away from PEAR coding styles, but if there's any interest I'd gladly help restructure it. The API is extremely simplistic and so integration with existing login forms not all too complicated, but if it was useable as native LiveUser module, it was probably magnitudes more useful. -- mario
Many production environments use some version of LDAP to store user information, including passwords and group membership. This includes OpenLDAP?, Novell eDirectory, and MS Active Directory. They differ in how they store this information.
1. We need more examples of the "perms" settings for the appropriate auth containers. I was able to deduce a working one by reading lots of code and blind experimetation. This needs documentation, and I will be able to supply some.
2. Getting the group information from LDAP is critical before LiveUser can do more than Pear::Auth. This includes at least three abilities.
2.1 The ability to retrieve these groups along with other container groups so that permission levels can be assigned.
2.2 A standard place to put the group, such as the first array in the returned LDAP 'attributes' tree. I can get that to work.
2.3 An abstraction layer so that the group permissions are processed the same as other containers. If the PEARAuth container wrapper can do this, I can not see how. The wrapped Auth instance tries to store the data in its own session where it is lost. I will have to write my own unless someone has started one.
Jim
Implemented wishes
Here you can find either finished wishes or wishes we think are finished and are waiting users feedback to see if it satifies them.
- Extension of the getProporty method to be able to retrieve the custom field values as well.
- I would like to see that the method addUser would take an extra argument (array) wich allows to add additional data to the row added to the database.(Julien)
- If you are talking about custom Fields then that has been implanted, it's in current release right now :) please let us know if that's the thing you're talking about, if not then explain it more on our Mailinglist (liveuser@lists.21st-hq.de) (Helgi)
- I'd like to have an Admin Method to remove all Users from a group (DB_Medium container)
- This item is on the roadmap for 0.14.0 release. Check the Roadmap Admin?. (Helgi)
- Currently is added in CVS version of LiveUser
- Method for retrieving $_SESSION[$this->_options['session']['varname']]['idle'] would be nice. With this, one could for example make a JavaScript? routine like many bank sites have that alerts the user when they're going to timeout.
- this is already available using $LU->getProperty('idleTime')
This site powered by YaWiki 0.22 beta.
|