[pmwiki-users] Site.AuthList Questions

Sivakatirswami katir at hindu.org
Mon Jun 25 19:50:22 CDT 2007


Tegan Dowling wrote:
> 
> 
> On 6/24/07, *Sivakatirswami* <katir at hindu.org <mailto:katir at hindu.org>> 
> wrote:
> 
>  the manual task
>     of tracking the passwords for each group and which users
>       have been given those passwords.
> 
>     I would be interested in how other admins do this or if there
>     are any "best practices" recommendations...
> 
>     A simple text file on one's own box?
>     A protected page on the wiki?
> 
> 
> Good question -- I'd be interested in hearing what others do, too.  I 
> have an Admin wikigroup, which requires an admin password to read.  One 
> of its pages  contains the following:
> 
> (:table class=tabtable padding=5px:)
> (:cell width=40%:)
> Here's a list of groups on the site
> (:pagelist fmt=group list=all group=-PmWiki,-Admin,-Site:)
> (:cell width=60%:)
> Maintain a manual list here of groups, pages and passwords
> * '''Site-wide''' admin=admin-levelpassword; 
> read/edit/upload=user-levelpassword
> * Group [[ExampleGroup1(.HomePage)]] read=firstpasswordexample;  
> read/edit/upload=secondpasswordexample
> * Page [[ExampleGroup2/ExamplePage]] read= pw1 pw2 pw3; 
> read/edit/upload=pw4 pw5
> (:tableend:)
> 
>  I highly doubt this could be considered a "best practice".
> 

Thanks, Tegan and Neil:

So, you are both using a manually maintained list.

Musings on strategies follow:

This goes back to an earlier discusson with Tegan I had off list
as to whether the overhead of Apache Basic Authentication used in 
conjunction
with AuthUser really gets us very much in terms of better security.

And our mutual feeling that sticking with PM's simple native password system
entails less admin over head in the long run. And it is no more hackable
than Basic Authentication--if a user leaks his user-pass combo
to get thru Apache or leaks a single password to get thru PM native 
authentication
it's pretty much the same vulnerability level. (correct me if I am wrong)

I was interested in your tracking methods, in part, as to see if they would
impact this strategic decision: use AuthUser or stick with PM Native 
passwords.

  Aside: Tegan I have yet to implement all your good guidance, given a 
few months
back... but pressure is building here to
allow users to see some groups, not others, edit some, not others etc.
So, I have to make a move soon, I don't want to keep proliferating fields
for every particular need... my old method.

Looking at Neils system, it's clear enough, but I don't see this as very 
scaleable.
I'm already using Apache Basic Authentication now for about 12 users and 
I don't
like it... I have one layer of web server task in PLESK (going into the 
domain,
adding users and passwords for each one) and then it appears one
then has another layer  to maintain at Site.Authuser  and you *still*
are have to set attributes for any given page or group, and then your
manually maintained list: that's 4 layers!  with PM native system
i) set group-page attributes
ii) make a note on your manually maintained list

that's only two layers.

I suppose I could read all the discussions on this issue to discover
some core concerns about why some admins want to use Apache
Basic Authentication instead of the native PM single password system.

If someone could distill those to a few sentences I would be interested
in hearing it, but not sure it would change our minds

So, I think I'll go with Tegan on this one... though Tegan's
tracking method provides no user identity... (Tegan,
how do you know who has what passwords? or is that
not an issue?) so perhaps that's the "requirement" that makes
others lean toward Apache Basic Authentication (because
it requires a clear list of users from the get go....)

If PM is lurking we would love his insights here...or from anyone else
with some years of experience in this area....

TIA

Sivakatirswami
www.himalayanacademy.com

Get Hinduism Today Digital Edition. It's Free!
http://www.hinduismtoday.com/digital/



More information about the pmwiki-users mailing list