[pmwiki-users] Fwd: Default group with authentication

[Sivakatirswami]

Aloha, Tegan:

OK.. I've been swamped... just getting back this last evening and
getting it all digested.. question:

your page list display model: only show groups users are auth to read..

requires

$EnablePageListProtect # to be on "1"
     When set to 1 (which is the default), causes (:pagelist:) and 
(:searchresults:) to exclude listing any pages for which the browser 
does not currently have read authorization. Setting this to zero means 
that read-protected pages can appear in a listing, but can also speed up 
searches considerably (because page permissions do not need to be checked).

But I am seeing that there are indeed  major speed gains by keeping that 
set to 0.

Is there a way to set

$EnablePageListProtect  for just one page?

hmm. PM... maybe no longer and issue? how's the page list caching thing
coming along? I'm still on2.2.0-beta17

Sivakatirswami



  Tegan Dowling wrote:
> This is the one I'm thinking you might have missed.
> 
> ---------- Forwarded message ----------
> From: Tegan Dowling <tmdowling at gmail.com>
> Date: Mar 1, 2007 2:24 PM
> Subject: Re: [pmwiki-users] Default group with authentication
> To: Sivakatirswami <katir at hindu.org>
> 
> 
> You can look at http://www.gladprofusion.com/Main/HomePage?action=source
> and you'll see that the page Main/HomePage (:include:)s the page 
> Site/Entry.
> 
> You can look at http://www.gladprofusion.com/Site/Entry?action=source
> to see how I use the pagelist, but in its essence (part of what
> follows is pseudo-code), I have
> 
> (:if ! enabled AuthPw:)(:comment - meaning if not logged in with any 
> password:)
> login stuff
> (:if enabled AuthPw:)
> Your password provides access to:
> (:pagelist fmt=#group:)
> (:ifend:)
> 
> and this works ok because in my config.php, I have
> 
>                $SearchPatterns['default'][] = '!^Site\\.!';
>                $SearchPatterns['default'][] = '!^PmWiki\\.!';
>                $SearchPatterns['default'][] = '!^Templates\\.!';
>                $SearchPatterns['default'][] = '!^Profiles\\.!';
>                $SearchPatterns['default'][] = '!^Contributions\\.!';
> 
> 
> On 3/1/07, Tegan Dowling <tmdowling at gmail.com> wrote:
>> Hi:  This is a terrific discussion - I hope to see more ideas for
>> running without any user-based authentication, as so far I've been
>> able to keep all my small-business and small-nonprofit clients
>> (including several who have hidden wikigroups for their boards and
>> other committee work) happy that way.
>>
>> Here's a link to my multi-purpose site:
>>
>> http://www.gladprofusion.com
>> The site is running 2.1.26
>>
>> Log in with password test to access the Test wikigroup without edit
>> authorization.  Log in again with password tester to access the same
>> wikigroup with edit permission.
>>
>> I'd welcome your questions, observations and suggestions.
>>
>> Tegan
>>
>> On 3/1/07, Sivakatirswami <katir at hindu.org> wrote:
>> > Tegan Dowling wrote:
>> > >
>> > > There is something really close to this that you can do without the
>> > > AuthUser or any other user-authentication scheme - i.e., just using
>> > > the native password authentication.
>> > >
>> > > On a couple if my sites, I provide each user with a wikigroup of
>> > > his/her own, which wikigroup is only visible to someone who knows 
>> (one
>> > > of) its read-password(s).  I use a pagelist on a login page, which
>> > > lists all the wikigroups on the site (minus a select, manually
>> > > excluded few), but takes advantage of the default rule for pagelists
>> > > which rules that pagelist results will only display links to
>> > > pages/groups for which the user has read-rights.
>> > >
>> > > Email me off-list if you'd like a demo.
>> > >
>> >
>> > > Tegan
>> >
>> > Tegan: this might be helpful for  me.. I am about to merge several
>> > fields on a farm to a single field, to reduce the admin.
>> >
>> > My set up is like this:  I want a little tighter security on initial
>> > entry: anyone who has access to the wikis gets a .htaccess 
>> user-password
>> > which I enter into the web server set up  for apache...
>> >
>> > Presently, after they are in, they can see *all* the groups. I will 
>> need
>> > to change that.
>> > But I'm new to this auth business  and I want  to also keep it simple.
>> >
>> > What I need is: for the user who logged in with his .htaccess 
>> user-password
>> > to then only see those groups that belong to his "classification" 
>> level.
>> >
>> > i.e.  my requirement is  just a tad broader:
>> > Default *set* of  groups with authentication
>> >
>> > Right now I would keep it simple: three classification levels
>> >
>> > Level 1: Volunteers: Sally, Rajan, Dora
>> >                 --  only read and edit a set of groups where content 
>> is not confidential
>> > Level 2: Staff: Sadhu, Andre, Ganga, Sarasvati, Dasan
>> >                 -- get to read and edit  an more  content sensitive  
>> "level 2" of
>> > groups + Level 1 groups
>> > Level 3: Admin: Natha, Katir
>> >                 -- Gets  to read and edit "Site.*" and a few other 
>> highly sensitive groups
>> >                 -- or put another way. "Admin" gets to read and edit 
>> *all* groups in
>> > wiki.d
>> >
>> > I am a bit up in the air about whether I really need to use authUser...
>> > which would then
>> > require more complex management of users and user groups.
>> >
>> > where as, at the risk of asking our  users to enter yet a second
>> > password once they are in..
>> > I was thinking that one could  us the default  pmwiki single password
>> > system
>> >   if I just had  one password for each of the three classifications
>> > and set the group attributes for all groups in Level One to one 
>> password
>> > Level two to another and Level three  to another.
>> >
>> > So what this means would be: If someone with Level Two clearance 
>> logs in
>> > to the  wiki.
>> >
>> > PMwiki will ask for a second password: "Level2"  after which, if he
>> > enters that, then
>> > the page list that appears on the log in page displays a list of  all
>> > groups in Level 1 and
>> > Level 2.. this second level of password would be very "soft" passwords,
>> > easy to remember...
>> > Like once they enter their .htaccess user name and password, then I 
>> tell
>> > them
>> > "Next you will see another password request.. enter "seva"  which I 
>> hope
>> >   wil ease the
>> > "tedious" factor of forcing users to authenticate twice...
>> >
>> > I've studied out the various recipes, but still remain a bit befuddled
>> > on the best strategy
>> > that results in the least admin overhead.
>> >
>> > Any advice will be appreciated. Since I'm already using .htaccess
>> > passwords. perhaps  if there is
>> > a simple way to accomplish my goal without forcing users to enter a
>> > second password.
>> > That may be actually better in the long run... I guess the way to do
>> > that would be to
>> > set up three auth user groups: volunteers, staff, admin and then enter
>> > the names
>> > of users into each of these... Admin users get entered into all three,
>> > staff get entered into
>> > Volunteers and Staff and volunteers only appear in "volunteers" 
>> group...
>> >
>> > If I do that... will PM wiki follow the  rule and only display 
>> groups in
>> > that they have access
>> > to in the main log in window (and various pull down lists in other 
>> pages?)
>> >
>> > I am really looking  forward to the centralized permissions control
>> > system that is on the
>> > future roadmap for PMwiki dev.
>> >
>> > Sivakatirswami
>> > www.himalayanacademy.com
>> >
>> >
>>
> 

-- 
Om shanti
(In  Peace)

Sivakatirswami
www.himalayanacademy.com

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