On 6/26/07, Sivakatirswami <[EMAIL PROTECTED]> wrote: > Do you also keep some kind of record of "who" is given the passwords? > does your framework not require this oversight? Or perhaps you issue > passwords > as a site admin, but someone else is responsible for who gets them? > > then if there is a problem, that someone simply tell you "can you please > change > the password "bravo" to "tango" and then you need to go thru all groups > manualy change that in Group Attributes for each one.
Hi, Siva: It would be a mere record-keeping matter to add the "who got it" information to the table, but I haven't found that I needed it. Typically, when I have a need to track passwords this way, the passworded areas 'belong' to people or groups, so that the identity of the wikigroup or page itself basically tells me who has the password. The real issue with the table is remembering to update it. It's not a technically necessary step, so it's easy to postpone and then forget to add a new password to the list. If you do have to add "who got it" to the data you track, you may find that AuthUser actually requires less effort to maintain, once it's set up -- as Sandy said: Quote -------------------- Back to AuthUser. On the attrib pages, it shows either **** for an classic-style password, or id:George or @GroupOne , which is much more informative. It will also allow you to add / remove individuals without affecting others, and track authors more accurately. Downside is that each person must be given a name and password, and you'll have to update SiteAdmin/AuthUser for each person. And then you'll have to stick people into user groups. (Each person can be in an unlimited number of user groups.) But you'd have to do much of this with any of the other methods. ---------------------- /Quote Since with AuthUser, the "who got it" is displayed right on the attr screen, and removes the need to track passwords themselves there, this might actually be simpler and more efficient than the tracking table for the native password-authentication, and the added simplicity might trump the 'wait for a business case' argument against AuthUser. If only AuthUser didn't have that ?action=login bug. _______________________________________________ pmwiki-users mailing list pmwiki-users@pmichaud.com http://www.pmichaud.com/mailman/listinfo/pmwiki-users