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/