[pmwiki-users] Site.AuthList Questions

[Tegan Dowling]

On 6/26/07, Sivakatirswami <katir at hindu.org> 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.