Tegan Dowling wrote: > > > On 6/24/07, *Sivakatirswami* <[EMAIL PROTECTED] <mailto:[EMAIL PROTECTED]>> > 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/ _______________________________________________ pmwiki-users mailing list pmwiki-users@pmichaud.com http://www.pmichaud.com/mailman/listinfo/pmwiki-users