phpwiki-talk

[Phpwiki-talk] GroupWikiPage

[Joby W. <joby@u.washington.edu>]

I am working on the GroupWikiPage class and I have a question on 
implementation.  GroupWikiPage is an class that in an implementation of 
Groups for phpwiki, in which the list of group members is in a WikiPage:

GroupAnnoying:
* BobTheBuilder
* TinkyWinky
* BarnyTheDinosaur

I have a method to search for all groups that a particular user is in 
(for use with searches, etc), and I have been coding it so that it 
searches for all '/^Group/' pages.  But do we want to do this?  Or 
should we require that for a Group page to be a recognized group page it 
must be listed on a GroupGroups page?

Advantages of GroupGroups:
1) Better top down management of groups.
2) Quicker/easier generation of grouplists.

Disadvantages:
1) Just searching would involve less management -- which is the halmark 
of the GroupWikiPage method of defining Groups.

Viewpoints?  Should I do both (GroupWikiPageOpen and GroupWikiPageClosed)?

thanks,

jbw

Re: [Phpwiki-talk] GroupWikiPage

[Jeff D. <da...@da...>]

> I have a method to search for all groups that a particular user is in 
> (for use with searches, etc), and I have been coding it so that it 
> searches for all '/^Group/' pages.  But do we want to do this?  Or 
> should we require that for a Group page to be a recognized group page it
> 
> must be listed on a GroupGroups page?

Not having thought about it much, my inclination is towards the latter.
Mostly because the implementation only introduces one magic page name
instead of a whole class of magic page names.  As I've said before,
I think magic page names are evil.

Maybe instead of being listed in GroupGroups, Group pages could just
link to CategoryGroup.  That maintains most of the advantages of both
of your suggestions.

> Should I do both (GroupWikiPageOpen and GroupWikiPageClosed)?

Not sure.  What is the difference, exactly?  Can a "closed group"
be accomplished just by adjusting page edit/viewing permissions
(once one can do that, of course...)

Jeff

Re: [Phpwiki-talk] GroupWikiPage

[Joby W. <joby@u.washington.edu>]

Jeff Dairiki wrote:
>>Should I do both (GroupWikiPageOpen and GroupWikiPageClosed)?
> 
> 
> Not sure.  What is the difference, exactly?  Can a "closed group"
> be accomplished just by adjusting page edit/viewing permissions
> (once one can do that, of course...)
> 

Sorry, I was unclear.  By "closed" and "open" I ment to distingish 
between the "GroupGroups page" or "search for /^Group/" methods.

jbw

Re: [Phpwiki-talk] GroupWikiPage

[Jeff D. <da...@da...>]

> By "closed" and "open" I ment to distingish 
> between the "GroupGroups page" or "search for /^Group/" methods.

Aha!  I would vote strongly against supporting both.  We already have
a bad enough case of "creeping featuritis".  Pick one a go with it.


Having thought about the issue a bit more while sleeping last night,
I like the CategoryGroups idea even more...  It's fairly "wiki"ish
and avoids introducing new paradigms while minimizing the introduction
of new "magic" page names.  (Note that since all current backends
have a decent link table (if you ignore bugs in the link extraction
code :-/), I don't think there is any performance hit involved in
going this way.)


Maybe even we don't need to impose the

  FooGroup:
  * MemberOne

syntax?  Perhaps saying that any user-pages linked to by a
group page are members of the group is enough.

Still absorbing the days first cup of coffee...
Jeff

Re: [Phpwiki-talk] GroupWikiPage

[Jeff D. <da...@da...>]

On Wed, 16 Oct 2002 11:57:28 -0700
Joby Walker <joby@u.washington.edu> wrote:

> Jeff Dairiki wrote:
> >>By "closed" and "open" I ment to distingish 
> >>between the "GroupGroups page" or "search for /^Group/" methods.
> > Aha!  I would vote strongly against supporting both.  We already have
> > a bad enough case of "creeping featuritis".  Pick one a go with it.
> 
> It actually isn't bad and would have no overhead to implement things in 
> multiple ways. 

My complaints about "creeping featuritis" don't really have much to do
with performance overhead issues.   The two big issues I see are
maintainance/debugging, and general simplicity or lack thereof....

Maintainance: the more ways to do things (code paths) there are
the more likely it is that someone (e.g. me) will break one of those
code paths without noticing it.  If we had a (better) test suite,
this would be less of an issue.  Currently we seem to have constant
problems (and support requests) with bugs that show up e.g. only
when USE_PATH_INFO is off, or when a certain theme is selected, etc...

Remote diagnosis of problems is generally made more difficult, too, when
there are lots of ways to do

Simplicity:  Currently any user documentation we have is lagging way
behind
our feature-set, so users already have to learn how to do things either
via code inspection, guessing, or word-of-mouth (word-of-email,
word-of-wiki)...  Introducing a new feature that can work in a variety
of ways, I think, just adds to the confusion unnecessarily.


Of course this doesn't mean that all new features are bad.
But, in this case, introducing multiple group page paradigms doesn't
really seem to me to add much functionality or usability.


 
> Once, I fix a couple things I'll post my lib/WikiGroup.php (which will 
> not be linked to by anything), so you all can get a look...

Cool!

> So with no "Group" magic name should 
> groups be allowed to have anyname?

Other than the issue you bring up (below) I don't see why not.
(User pages aren't named UserJeff...)  (And there's always the
i18n issue: GrupoCampagnolo?)

> This is frought with problems,

Yes, you're right, it is.  Still I don't really like the
magic list syntax --- I can't really think  of better
alternatives though...

> 1) If a WikiWord is used and that page does not exist.  The group could 
> be compromised by the creation of a user with that WikiWord for a name.

Oof. Yes.  Don't do that.

This problem may show up in other cases, too: what if an administrator
deletes a user (and user page)?  Then (if automatic account creation
is enabled) anyone can usurp that name...   Not sure it's a major
problem, but worth noting...

> 2) It looks like a non-homepage can be compromised and turned into a 
> homepage by adding a CategoryHomepage and then trying to login with that
> 
> name.

Okay.  Maybe the CategoryHomepage idea is a bad one...  Let's fallback
(for the sake of discussion) to detecting user pages by the presence
of user meta-data.

> 3) Every link needs to be investigated to determine if it leads to a 
> homepage -- this determination currently requires parsing the page, so 
> instead of parsing one page to determine a group's members it will 
> require N pages be parsed (where N = number of links on a group page).

A) I don't see why a page parse is needed to detect a home page.
   It should only require looking at the page meta-data.

B) In most cases, it is only of interest if the current (viewing)
   user is a member of a particular group (the group of the requested
   page).  In that case, we already know that the username if interest
   is a valid user (and therefore a valid userpage).

> 4) Without the "Group" magic word a homepage can be a grouppage as well,
> 
> which means that user A could not link to user B's homepage without 
> adding B to A's group.  Which seems overlimiting...

True.  One solution is "don't do that".  ("Doctor, doctor...")
(Another solution would be not to allow that: ignore any groups which
have the same name as a user.)

Jeff

Re: [Phpwiki-talk] GroupWikiPage

[Joby W. <joby@u.washington.edu>]

Jeff Dairiki wrote:
>>2) It looks like a non-homepage can be compromised and turned into a 
>>homepage by adding a CategoryHomepage and then trying to login with that
>>name.
> 
> Okay.  Maybe the CategoryHomepage idea is a bad one...  Let's fallback
> (for the sake of discussion) to detecting user pages by the presence
> of user meta-data.
> 
>>4) Without the "Group" magic word a homepage can be a grouppage as well,
>>which means that user A could not link to user B's homepage without 
>>adding B to A's group.  Which seems overlimiting...
> 
> True.  One solution is "don't do that".  ("Doctor, doctor...")
> (Another solution would be not to allow that: ignore any groups which
> have the same name as a user.)

A solution to both is "pagetype" in its own field in $page_tbl (or if it 
is the consensus a meta-data entry).  A single small int would resolve 
the issue:

0 - WIKI_PAGE    # Standard Wiki Page
1 - GROUP_PAGE   # Group page with list of members
2 - USER_PAGE    # User Homepage with Meta-data containing password
3 - ADMIN_PAGE   # ? not sure just brainstorming for potential

This would enable quick identification (field would be faster than 
meta-data), provide better security, and well...make things clearer.

jbw

Re: [Phpwiki-talk] GroupWikiPage

[Jeff D. <da...@da...>]

> A solution to both is "pagetype" in its own field in $page_tbl (or if it
> 
> is the consensus a meta-data entry).  A single small int would resolve 
> the issue:
> 
> 0 - WIKI_PAGE    # Standard Wiki Page
> 1 - GROUP_PAGE   # Group page with list of members
> 2 - USER_PAGE    # User Homepage with Meta-data containing password
> 3 - ADMIN_PAGE   # ? not sure just brainstorming for potential
> 
> This would enable quick identification (field would be faster than 
> meta-data), provide better security, and well...make things clearer.

That, of course, would require back-end changes as well as requiring
some new UI to allow editing of the page type.  (I.e. you can't change
a page type just by editing the page in the normal way --- or at least
you'd have to fix things so that you can....)

If you're willing to go that far, then it's probably better to just
stick with separate group dbs, as originally suggested.  (I.e. the
main point of cramming the group information into wiki pages was to
avoid backend changes, and to avoid having to implement a group
management UI...)


As you point out: so long as the GroupDatabase (and UserDatabase(s))
are implemented as standalone objects, all of the implementation
details can be cleanly changed later should someone feel the
need....

>>2) It looks like a non-homepage can be compromised and turned into a 
>>homepage by adding a CategoryHomepage and then trying to login with that
>>name.

I think in Reini's current design, user password verification can from
from a number of sources (LDAP, IMAP, seperate SQL db, or data stored
in UserPage).  Still, there is a single user namespace.   So the problem
is a little more complicated (and insidious) since users can be created
by processes completely unrelated to WikiPage creation/modification...
I.e. it's not clear to me that all valid users necessarily even have
a UserPage.  The only unique user identifier we have is the username.
(Iff two users have the same username, they are the same user.)
There may or may not be a wikipage with that name, and, even if there
is, it may or may not be that users UserPage.

Is that right Reini?

Re: [Phpwiki-talk] GroupWikiPage

[Reini U. <ru...@x-...>]

Jeff Dairiki schrieb:
>>A solution to both is "pagetype" in its own field in $page_tbl (or if it
>>
>>is the consensus a meta-data entry).  A single small int would resolve 
>>the issue:
>>
>>0 - WIKI_PAGE    # Standard Wiki Page
>>1 - GROUP_PAGE   # Group page with list of members
>>2 - USER_PAGE    # User Homepage with Meta-data containing password
>>3 - ADMIN_PAGE   # ? not sure just brainstorming for potential
>>
>>This would enable quick identification (field would be faster than 
>>meta-data), provide better security, and well...make things clearer.


> That, of course, would require back-end changes as well as requiring
> some new UI to allow editing of the page type.  (I.e. you can't change
> a page type just by editing the page in the normal way --- or at least
> you'd have to fix things so that you can....)
> 
> If you're willing to go that far, then it's probably better to just
> stick with separate group dbs, as originally suggested.  (I.e. the
> main point of cramming the group information into wiki pages was to
> avoid backend changes, and to avoid having to implement a group
> management UI...)
> 
> As you point out: so long as the GroupDatabase (and UserDatabase(s))
> are implemented as standalone objects, all of the implementation
> details can be cleanly changed later should someone feel the
> need....

I'm also against this new pagetype field. We can solve this more
easily and with less efforts in the administration.


>>>2) It looks like a non-homepage can be compromised and turned into a 
>>>homepage by adding a CategoryHomepage and then trying to login with that

In my design I store the prefs meta-data field to denote it as UserPage, 
not CategoryHomepage. "This page holds the UserPrefs".

CategoryHomepage is also fine, but a seperate IndexingMechanism.
The AllUsers plugin looks for stored UserPreferences, not for a 
CategoryHomepage link.


> I think in Reini's current design, user password verification can from
> from a number of sources (LDAP, IMAP, seperate SQL db, or data stored
> in UserPage).  Still, there is a single user namespace.   So the problem
> is a little more complicated (and insidious) since users can be created
> by processes completely unrelated to WikiPage creation/modification...
> I.e. it's not clear to me that all valid users necessarily even have
> a UserPage.  The only unique user identifier we have is the username.
> (Iff two users have the same username, they are the same user.)
> There may or may not be a wikipage with that name, and, even if there
> is, it may or may not be that users UserPage.
> 
> Is that right Reini?

exactly.
the UserPage if it exists is the best place to store the preferences. if 
it not exists it has to be stored in the cookie as before.

alternatively the admin can setup a database (also external) to store 
userprefs (and passwords).
then you need no UserPage and no cookies.
-- 
Reini Urban
http://xarch.tu-graz.ac.at/home/rurban/