[Pmwiki-users] Re: PmWiki development - User Authentication

[Patrick R. Michaud]

Take a look at http://www.pmwiki.org/wiki/Development/UserControls
and see if this is close to what you want.

Pm

On Mon, Jun 07, 2004 at 11:31:30PM -0700, Steven Leite wrote:
> > First, I have some questions--when someone comes to a page on the
> > site for the first time the controls will be hidden.  How should
> > an editor or other authorized person get the controls to appear...
> > is there a "login" link or something for them to follow?  Or perhaps
> > editors should be required to go to a login page of some sort
> > and after that they can see the controls?
> 
> Since MOST of the users will be regular users (as opposed to admins, or
> editors with special privliges), I'd say a special log-in page (instead
> of a link on every page).  That doesn't mean a link on every page
> couldn't be an option (see below:  --Links On Every Page--).  I think a
> special ?action=login would be sufficient.  That way the admin could
> make a link or special page with the ?action=login part of a hyperlink
> to make the job easier.
> 
> I like the cookie idea, because that way the person doesn't have to
> log-in every time - PmWiki would just remember the person.  There
> could/should be a log-out feature that delete the cookie for those
> people using public terminals.
> 
> --Links On Every Page--
> There could be a login link at the top of each page (just like the Edit
> This Page, or Recent Changes links .. part of the template, so it would
> be optional:
> 
> <!--AdminMenu--> [[admin menu/options here]]<!--/AdminMenu-->
> <!--EditorMenu-->[[admin menu/options here]]<!--/EditorMenu-->
> <!--UserMenu-->[[user menu/options here]]<!--/EditorMenu-->
> 
> > Since this scenario is really about hiding controls from unauthorized
> > users, and not about assigning rights to individual users, is it
> > necessary for each authorized user to have his own username and
> password,
> > or is it sufficient to just have a shared password for the editors?
> 
> I think the user need only identify him/her-self with a password.  There
> might be a master list of "user-types".  At the rudimentry level, I
> guess Admin, Editor, and User would be ok, but to take it a step
> further, why not let the admin define his own user-types?  From there,
> we aren't too far from user-authentication. Another approach would be to
> use numbers instead of names (see below:  --Access By Numbers--)
> 
> --Admin-Defined User-Types--
> 
> Wouldn't it be nice if an admin could declare some user types like this:
> 
> Admin1  - all access, all groups, all pages
> Admin2 - all access, all groups, not admin group, all pages
> Editor 1 - all access, group1, all pages
> Editor 2 - all access, group 2, all pages
> User1 - read/edit all pages, not Admin Group, not (array of page titles)
> User 2 - etc etc
> 
> Then, in the template, he might put something like:
> Main Menu:
> <!--AdminMenu-->Delete<!--/Admin-->
> <!--EditorMenu-->Edit This Page<!--/EditorMenu-->
> <!--UserMenu-->RecentChanges
> Printable Version<!--/UserMenu-->
> <!--AdminMenu-->PageRevisions<!--/AdminMenu-->
> 
> Some more thought would have to go in to this though, as what happens if
> user is logged in as Admin .. now will they see the Editor and User menu
> options?  Clearly, there needs to be some hierarchy so that Admin is
> level 3, Editor is level 2, and User is level 1.  Admin would see levels
> 3, 2 and 1, etc etc.
> 
> --Access By Numbers--
> 
> Why not make it 10 levels?  Or why not 100?  1000?
> 
> Maybe rather than defining user "names" (eg. Admin, Editor, User),
> define user-level (number) instead.  After defining a "level of access"
> .. how to customize it?  Can I define a level 5 to have access only to
> the Main Group, and a level 6 has access only to the PrivateGroup?  Now
> how do I keep a level 6 out of the MainGroup?
> 
> Perhaps the (existing?) per-page / per-group attributes could be used to
> store level-access.
> 
> 
> Group1 = 0,5-6, 100, 1000
> Group2 = 0, -5, 6,100, 1000
> Group3 = 1000
> Group4 = 5 -1000
> Group5 = 0 - 1000, -100
> 
> Is it possible to load a cookie with multiple user-level(s) and password
> so a user could be logged in with multiple level access?
> 
> eg.  I have the following authorizations (keys) stored in a single
> cookie:
> level 0 (password0),  level 1 (password1), level1000 (password1000)
> 
> Now my authentication is three-fold.
> 
> -Steven
> 
> 
> ----- Original Message ----- 
> From: "Patrick R. Michaud" <pmichaud at pobox.com>
> To: "Steven Leite" <steven_leite at kitimat.net>
> Cc: <pmwiki-users at pmichaud.com>
> Sent: Monday, June 07, 2004 9:08 AM
> Subject: Re: PmWiki development - User Authentication
> 
> 
> > Excellent, this is a perfect example and we can build from this.
> > First, I have some questions--when someone comes to a page on the
> > site for the first time the controls will be hidden.  How should
> > an editor or other authorized person get the controls to appear...
> > is there a "login" link or something for them to follow?  Or perhaps
> > editors should be required to go to a login page of some sort
> > and after that they can see the controls?
> >
> > Since this scenario is really about hiding controls from unauthorized
> > users, and not about assigning rights to individual users, is it
> > necessary for each authorized user to have his own username and
> password,
> > or is it sufficient to just have a shared password for the editors?
> >
> > Pm
> >
> > On Mon, Jun 07, 2004 at 09:18:10PM -0700, Steven Leite wrote:
> > > I'd be happy with a simplistic approach (for now).
> > >
> > > To help cut down on spamming, I'd like to control "certain parts" of
> my
> > > website, or rather, dis-allow certain function on pages.  Although
> this
> > > is already possible with PmWiki (by setting page attributes?), I
> would
> > > also like to "hide" the controls.
> > >
> > > The direction I personally would like to go is to have a Wiki that
> > > "looks and feels" just like a regular website (eg. nobody can edit
> it
> > > except the admin, or a select group of editors, say in a corporate
> > > environment), but also have certain places where edits (and
> > > contributions) are allowed.
> > >
> > > Again, this is already possible in PmWiki by setting page
> attributues (I
> > > think group attributes are also possible?).  But it's not elegant.
> > >
> > > Is that real-world enough?
> > >
> > > -Steven
> > >
> > > ----- Original Message ----- 
> > > From: "Patrick R. Michaud" <pmichaud at pobox.com>
> > > To: "Steven Leite" <steven_leite at kitimat.net>
> > > Cc: <pmwiki-users at pmichaud.com>
> > > Sent: Monday, June 07, 2004 7:31 AM
> > > Subject: Re: [Pmwiki-users] PmWiki development
> > >
> > >
> > > > On Mon, Jun 07, 2004 at 07:43:31PM -0700, Steven Leite wrote:
> > > > > There was a lot of talk a while ago about introducing (some
> form) of
> > > > > user authentication.  Just wondering if you'd given any thought
> to
> > > that
> > > > > in this new design.  Where does that rank on the Development
> list?
> > > (eg.
> > > > > High, Med. Low?)
> > > >
> > > > I haven't given it much thought, simply because I still haven't
> come
> > > > up with any good ideas about how to control authorization
> (determining
> > > > what actions a user is allowed to perform and where) after a user
> has
> > > > been authenticated.
> > > >
> > > > I can come up with simplistic systems such as "limit edits to
> > > > authenticated users" and "always allow authenticated users to
> > > > perform actions X,Y,Z", but once we get into things such as
> > > > access control lists with "allow users A, B, and C to edit
> > > > pages D and E; allow users A and C but not H to edit groups
> > > > F and G; etc." then I'm at a loss as to how to make a simple
> > > > interface for maintaining the access control lists.
> > > >
> > > > This is another one of those cases where it would help
> tremendously
> > > > to have a real-world example of what is needed, rather than to
> > > > try to guess based on what is possible.
> > > >
> > > > Pm
> > > >
> > > >
> > > >
> > >
> >
> >
>