phpwiki-talk

[Phpwiki-talk] Userauth against external db and how to change homepage

[Stefan <son...@ba...>]

Hello,

there should be a config switch to tell function isValidName to return 
true in WikiUserNew.php. when users are inserted only in an external 
programm like userregistration in smf (forum software). Smf uses 
different validation of names, the table can't be used to authenticate 
users in phpwiki when isValidUsers tries to validate correct names.

Example: user "Thomas Braun" is valid in SMF but phpwiki tells invalid 
user. After changing function isValidName to return true, the user can 
authenticate against the user from the external database table.

Can someone tell me where to change the homedirectory of authentificated 
users. they should have page "users/userid" not only "userid". 
Background: else users may get a homepage which exists in the wiki as 
normal page.

Regards and thaks
Stefan

Re: [Phpwiki-talk] AppendTextPlugin revision 1.3

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

Pascal Giard (QC/EMC) schrieb:
i also added the "redirect" parameter.
> at the moment, it's boolean, but maybe it'd be smarter to make it 
> support the destination page as a value ?
> 
> That might be interesting if you modify a page from another one and want 
> to come back to the modificator.

What I really want is the following as default:

If the current page and the target page (the page argument) are the 
same, display after the successful AppendText action the changed page 
directly, and an AppendText notification at the top of the page. As on 
SearchHighlight and

No link to the changed page, the page directly.

Only if the basepage is different, display the link to the changed page.

> a comment on the copyrights, i don't necessarly want to be the copyright 
> holder. I don't mind if the phpwiki team is the copyright holder and 
> that i'm cited as a contributor.

Ok.

> PS: do you plan to add the snippets you pasted me in the standard edit 
> page ?

Something like this, just better. The AddCategory button is already 
there, the plugin part not yet.
What is missing is that the popup window on the AddCategory button 
should generate an extra request to get those pages. A category "popup 
on demand".
Currently the traversal is done on each edit request, which I want to 
avoid, cause edit already is slow enough. The user can wait a bit to get 
the matching categories and plugins to insert into, after pressing the icon.

And the plugin part needs some prefix and suffix.

<?plugin WikiFormRich action=AppendText buttontext="AddPlugin"
    pulldown[] name=text value="<?plugin <!plugin-list BackLinks 
page=WikiPlugin !> ?">
    ?>
would be cool, but probably too hard.

<?plugin WikiFormRich action=AppendText buttontext="AddCategory"
   pulldown[] name=text value=<!plugin-list TitleSearch s=Category !>
   ?>

Of course you can change the editpage.tmpl to add these pulldowns on 
every edit request, but I prefer a js generated button. Just don't know 
if MacOSX Safari has still a problem with those generated js buttons and 
how to overcome.
-- 
Reini Urban
http://xarch.tu-graz.ac.at/home/rurban/

[Phpwiki-talk] Multiple instances - One DB

[Manuel V. <man...@st...>]

Hi all,

In order to be able to run multiple instances of PhpWiki based on the 
same sources and the same DB, I want to modify WikiDB and corresponding 
backends (at beginning PearDB) to add an unique id for each PhpWiki 
instances.

My idea is:
- to add a field in the Db.
- modify all access to Db in backend/PearDb to include the good id.

Do you think that's it would be suffisant or not?

Regards,
Manuel

Re: [Phpwiki-talk] AppendTextPlugin revision 1.2

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

I have an API problem with text:

The "text" argument should be renamed to "s".

A <input type=radio name=text ...> row fails on mozilla (latest 1.8 
version). It wil only display the first radio. I haven't checked the 
mozilla bugzilla yet, but I will file a report soon.

If I want to paste a text piece from a radio button row and not from a 
pulldown it will not work.

This works ok:
   <?plugin WikiFormRich action=AppendText buttontext="AddPlugin"
   	   radio[] name=s value=<!plugin-list BackLinks page=WikiPlugin 
limit=5 !>
   	   ?>

This displays only the first radio button on gecko, MSIE is ok.

   <?plugin WikiFormRich action=AppendText buttontext="AddPlugin"
   	   radio[] name=s value=<!plugin-list BackLinks page=WikiPlugin 
limit=5 !>
   	   ?>


So I will change text to s.
-- 
Reini Urban
http://xarch.tu-graz.ac.at/home/rurban/

RE: [Phpwiki-talk] AppendTextPlugin revision 1.2

[Pascal G. (QC/EMC) <Pas...@er...>]

>  > hey, you're cheating! there's no support for pulldowns in the CVS's
>  > version! ;)
> 
> It is, it is, just added it. :)

i still can't have it... the anoncvs server of sf.net is slow at synching...
 
>  > btw, i noticed that the "break;" is still missing for hidden[].
> 
> That's the last so it doesn't need a break.

in the version i have (current anonCVS), pulldown[] is the last item so
hidden[] won't work w/o the break.


about AppendText:

> The only "major" problem we have now is the
> "Go to ", HTML::em(WikiLink($pagename)), "." part, which should be 
> translatable.
> sprintf("Go to %s.", HTML::em(WikiLink($pagename)) is forbidden.
> Only
> $link = HTML::em(WikiLink($pagename));
> HTML::Raw(sprintf("Go to %s.", $link->asXml()); would work.

i guess you meant:
HTML::Raw(sprintf(_("Go to %s."), $link->asXml());

anyway, i leave that part up to you, you know what would suit best more than
i do.

>  >> if you have the patience to help me with some of my 
> frustrations...
>  >> here they are:
>    - how do i cleanly redirect, with:
> "$request->redirect(WikiURL($pagename);"
> 
> solved?

yes

> CSS is a horror.
> try theme=sidebar (from CVS, not from 1.3.10)
> This is quite ok.
> The MonoBook sidebar is not yet stable enough. (MSIE issues)
> Wordpress is limited.

thank you for the informations!

-Pascal

Re: [Phpwiki-talk] AppendTextPlugin revision 1.2

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

Pascal Giard (QC/EMC) schrieb:
 >  > I like it.
 >  > Sample buttons to insert a plugin or category. (Current CVS only)
 >
 > glad you like it :)
 >
 >  > <?plugin WikiFormRich action=AppendText buttontext="AddPlugin"
 >  >     pulldown[] name=text value=<!plugin-list BackLinks
 >  > page=WikiPlugin !>
 >  >     ?>
 >  >
 >  > <?plugin WikiFormRich action=AppendText buttontext="AddCategory"
 >  >    pulldown[] name=text value=<!plugin-list TitleSearch s=Category !>
 >  >    ?>
 >
 > hey, you're cheating! there's no support for pulldowns in the CVS's
 > version! ;)

It is, it is, just added it. :)

 > btw, i noticed that the "break;" is still missing for hidden[].

That's the last so it doesn't need a break.

> PS: this one includes fixes of sprintf usage...
> i also noticed that you're add AppendText to the CVS after diong some 
> modif, i synch'd both, so here it is.

The only "major" problem we have now is the
"Go to ", HTML::em(WikiLink($pagename)), "." part, which should be 
translatable.
sprintf("Go to %s.", HTML::em(WikiLink($pagename)) is forbidden.
Only
$link = HTML::em(WikiLink($pagename));
HTML::Raw(sprintf("Go to %s.", $link->asXml()); would work.


 >> if you have the patience to help me with some of my frustrations...
 >> here they are:
   - how do i cleanly redirect, with:
"$request->redirect(WikiURL($pagename);"

solved?

 >> - how to i render raw content the phpwiki way ? (e.g. transforming 
%%% into <br>, etc.)

pass the HTML object into the tree. HTML::br().
or if must be a string pass it is HTML::Raw().

 >> - how do i get a menu on the left without pulling my hair modifying 
the CSS for hours (i already wasted to much time on it, i now have a 
menu on the left using a modified Wordpress, but there are margin 
problems when there are <div> in <div> [e.g. plugins]).

CSS is a horror.
try theme=sidebar (from CVS, not from 1.3.10)
This is quite ok.
The MonoBook sidebar is not yet stable enough. (MSIE issues)
Wordpress is limited.
-- 
Reini Urban
http://xarch.tu-graz.ac.at/home/rurban/

Re: [Phpwiki-talk] [RFC] AppendTextPlugin

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

Pascal Giard (QC/EMC) schrieb:
> Here's a first working version.
> Comments are very welcome.

I like it.
Sample buttons to insert a plugin or category. (Current CVS only)

<?plugin WikiFormRich action=AppendText buttontext="AddPlugin"
    pulldown[] name=text value=<!plugin-list BackLinks page=WikiPlugin !>
    ?>

<?plugin WikiFormRich action=AppendText buttontext="AddCategory"
   pulldown[] name=text value=<!plugin-list TitleSearch s=Category !>
   ?>

-- 
Reini Urban
http://xarch.tu-graz.ac.at/home/rurban/

Re: [Phpwiki-talk] Redirecting some preferences to other fields

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

Elliot Lee schrieb:
> I have a wiki set up to store the prefs in an SQL db (same table as is
> used for authentication). Right now, all the prefs are stored in a blob
> that goes into the 'wiki_prefs' field of the user record in my user db.
> However, the user record has separate fields for password and e-mail
> address, so I would like phpwiki to use those fields only, instead of
> storing/retrieving the password & e-mail address in the 'wiki_prefs' blob.
> 
> Ideas/comments?
> -- Elliot

We don't want to support arbitrary prefs fields (yet), but you can try 
to add this by yourself. Shouldn't be that hard.

-- 
Reini Urban
http://xarch.tu-graz.ac.at/home/rurban/

Re: [Phpwiki-talk] [RFC] AppendTextPlugin

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

Pascal Giard (QC/EMC) schrieb:
> Here's a first working version.
> Comments are very welcome.

Great. Was it easy?

Some comments: A pagehandle is really a handle (ptr to a WikiDB_Page 
object). You should name it pagename.
"lbound" and "hbound" are strange argument names, but they are yours, 
and we don't have similar args yet.
I personally would rather name those "before" and "after". A bound is 
normally numeric.
Shouldn't there be some fallback in case of hbound/lbound replace will 
not succeed? Either an error message or add to end. It also should be 
preg_quote'd, since it's a user arg.

Question is: Do we want that included into the PhpWiki distro?
I think so.
We initially thought that AddComment should be enough, and easier to 
seperate from the existing content. But this argument is bogus.

> -Pascal
> PS: rename .zipped to .zip ... sorry, had to do that because of 
> Ericsson's mail scanner.

I'll add this at the sf.net site under RFE, after some cosmetic changes.
   http://sourceforge.net/projects/phpwiki/
People tend to prefer webbrowsing than email archive scanning.
-- 
Reini Urban
http://xarch.tu-graz.ac.at/home/rurban/

[Phpwiki-talk] Redirecting some preferences to other fields

[Elliot L. <so...@re...>]

I have a wiki set up to store the prefs in an SQL db (same table as is
used for authentication). Right now, all the prefs are stored in a blob
that goes into the 'wiki_prefs' field of the user record in my user db.
However, the user record has separate fields for password and e-mail
address, so I would like phpwiki to use those fields only, instead of
storing/retrieving the password & e-mail address in the 'wiki_prefs' blob.

Ideas/comments?
-- Elliot

[Phpwiki-talk] [BUG] WikiFormRich

[Pascal G. (QC/EMC) <Pas...@er...>]

Please add "break;" after line 157.
That fixes hidden[] .

-Pascal

[Phpwiki-talk] Re: Phpwiki - Multiple instance

[Manuel V. <man...@st...>]

Dan Frankowski wrote:
> Manuel,
> 
> We ended up using multiple DBs.

Thanks for your quick answer

Manuel

Re: [Phpwiki-talk] Custom forms -- Appending to existing page

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

Pascal Giard (QC/EMC) schrieb:
> 
> 
>  > Pascal Giard (QC/EMC) schrieb:
>  > >   i was looking thru main.php and WikiFormRich.php and
>  > noticed that it's
>  > > possible to edit OR create a page via forms, but not to append text
>  > > (well not directly).
>  >
>  > you need a action to do that.
>  > actions are best handled by actionpages calling a custom plugin.
> 
> can you point me to examples ?

all our actions which are not handled directly by main.php are handled 
by action pages. all actions which are wikiwords.

an matching example would be e.g. AddComment. This creates a new page. 
You just want to add to the current page.

pgsrc/AppendText:

<?plugin AppendText ?>

lib/plugin/AppendText.php:

class WikiPlugin_AppendText
extends WikiPlugin {
     function getDefaultArguments() {
         return array('page'   => '[pagename]',// append to current page
                      'text'  => '');
     }
     function run($dbi, $argstr, &$request, $basepage) {
         extract($this->getArgs($argstr, $request));
         if (empty($page) or empty($text))
             return '';
         ...
      }
}


>  
>  > > I simply want a form that will append Text to a Page.
>  > > Should i modify main.php to support a new kind of action, namely
>  > > "append" or something like it ?
>  >
>  > no, better write a plugin like AppendText.
> 
> alrite, i'll write one!
>  
> -Pascal
> 


-- 
Reini Urban
http://xarch.tu-graz.ac.at/home/rurban/

[Phpwiki-talk] Re: Phpwiki - Multiple instance

[Dan F. <dfr...@cs...>]

Manuel,

We ended up using multiple DBs.

Dan

Manuel VACELET wrote:

> Hello,
>
> I just read your post on phpwiki-talk mailing list about multiple 
> phpwiki instances.
>
> You said (06/2004) you wanted to have one phpwiki install, on DB to 
> manage an multiple wikis around this.
>
> You got responses for phpwiki sources but it didn't see anything about 
> the DB. How did you solve the problem ?
>
> My problem is to avoid tables multiplications: I don't want to have 
> nb_wikis * nb_tables to maintain.
>
> Regards,
> Manuel

RE: [Phpwiki-talk] Custom forms -- Appending to existing page

[Pascal G. (QC/EMC) <Pas...@er...>]

> Pascal Giard (QC/EMC) schrieb:
> >   i was looking thru main.php and WikiFormRich.php and 
> noticed that it's 
> > possible to edit OR create a page via forms, but not to append text 
> > (well not directly).
> 
> you need a action to do that.
> actions are best handled by actionpages calling a custom plugin.

can you point me to examples ?
 
> > I simply want a form that will append Text to a Page.
> > Should i modify main.php to support a new kind of action, namely 
> > "append" or something like it ?
> 
> no, better write a plugin like AppendText.

alrite, i'll write one!
 
-Pascal

Re: [Phpwiki-talk] Multiple PhpWiki instances

[Manuel V. <man...@st...>]

Reini Urban wrote:
> Manuel VACELET schrieb:
> 
>> Is there any way to provide easily multiple instance of phpwiki form 
>> one phpwiki installation?
> 
> 
> yes, something like:
>   http://phpwiki.sourceforge.net/phpwiki/WikiFarm
> 
> I posted several of my starter scripts some time ago. See the -talk 
> archive.

Thanks a lot.
I will browse archives.


--
Manuel

Re: [Phpwiki-talk] Re: groups and perm patches

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

Reini Urban schrieb:
> Charles Corrigan schrieb:
> 
>> Hi,
>>
>> I have been working on getting ACLs working to my liking when using 
>> WikiPage
>> permissions (i.e. I am not certain that what I have done is OK yet). My
>> changes are incomplete but here's an interim drop - please let me know 
>> if I
>> am on the wrong track. Similar changes may be required for the differing
>> types of permissioning (DB, FILE etc).
>>
>> In particular, the changes to PagePerm.php are not very well tested. One
>> issue delaying testing is that the display of the page owner does not 
>> appear
>> to work correctly all the time, particularly that generated in
>> lib/plugin/WikiAdminSetACL.php and lib/plugin/WikiAdminChown.php plugins
>> (probably the issue is in the lib/plugin/WikiAdminSelect.php plugin). 
>> Or it
>> may be that I am bending things too far out of shape

I tested this now:
chown HomePage to Administators, and it immediatly showed up the correct 
change:
   Owner: "Administrators" Last edited on November 19, 2004 8:26 pm by 
"The PhpWiki programming team"

>> lib/WikiGroup.php:
>> The changes are
>> 1 - the check in case GROUP_BOGO_USER seems to be bogus (!), fix
>> 2 - allow group pages to have the link to the user page in [ ] brackets
>> 3 - fix up the implementation of GroupWikiPage::getMembersOf and allow 
>> the
>> user page to be linked in [ ] brackets
> 
> 
> I'll check those fixes in.
> 
>> the output of diff -u follows
>> --- /home/charles/extract/phpwiki/lib/WikiGroup.php     2004-11-20
>> 03:22:03.000000000 +0800
>> +++ ./WikiGroup.php     2004-11-23 11:08:56.546875000 +0800
>> @@ -321,7 +321,7 @@
>>              return $users;
>>          case GROUP_BOGOUSER:
>>              foreach ($all as $u) {
>> -                if (isWikiWord($user)) $users[] = $u;
>> +                if (isWikiWord($u)) $users[] = $u;
> 
> 
> good catch!
> 
>>              }
>>              return $users;
>>          case GROUP_SIGNED:
>> @@ -508,7 +508,7 @@
>>              return false;
>>          }
>>          $contents = $group_revision->getContent();
>> -        $match = '/^\s*[\*\#]+\s*' . $this->username . '\s*$/';
>> +        $match = '/^\s*[\*\#]+\s*\[?' . $this->username . '\]?\s*$/';
> 
> 
> ok, makes sense.
> 
> whitespace issues left out:
> * [ ReiniUrban ]
> is disallowed, just:
> * [ReiniUrban]
> 
>>          foreach ($contents as $line){
>>              if (preg_match($match, $line)) {
>>                  return true;
>> @@ -559,21 +559,16 @@
>>         if ($this->specialGroup($group))
>>              return $this->getSpecialMembersOf($group);
>>
>> -        trigger_error("GroupWikiPage::getMembersOf is not yet 
>> implimented",
>> -                      E_USER_WARNING);
>> -        return array();
>> -        /*
>> -        * Waiting for a reliable way to check if a string is a username.
>> -        $request = $this->request;
>> +        global $request;
>>          $user = $this->user;
>>          $group_page = $request->getPage($group);
>>          $group_revision = $group_page->getCurrentRevision();
>>          if ($group_revision->hasDefaultContents()) {
>>              trigger_error("Group $group does not exist", 
>> E_USER_WARNING);
>> -            return false;
>> +            return array();
>>          }
>>          $contents = $group_revision->getContent();
>> -        $match = '/^(\s*[\*\#]+\s*)(\w+)(\s*)$/';
>> +        $match = '/^(\s*[\*\#]+\s*\[?)(\w+)(\]?\s*)$/';
>>          $members = array();
>>          foreach($contents as $line){
>>              $matches = array();
>> @@ -582,7 +577,6 @@
>>              }
>>          }
>>          return $members;
>> -        */
>>      }
>>  }
> 
> 
> Good to have the explicit link syntax also.
> kinda hairy, maybe check the linkextractor instead, but I defer that to 
> later.
> I added something like this now. Better than nothing indeed.
> 
>> lib/PagePerm.php:
>> The changes are
>> 1 - allow ACL_OWNER to check a group owner, not just a user owner - not
>> fully tested
>> 2 - allow ACL_CREATOR to check a group owner, not just a user owner - not
>> fully tested
> 
> 
> just a note: owner and creators cannot be groups, just users, because 
> authenticated is just a user, which might optionally belong to a group.

wrong: you can of course chown a page to a group.
The default is just the user, but later on, when you chwon the owner 
gets stored as page metadata, so it can be a group also, which makes sense.

> but the perm check against group membership is ok.
> I forgot that, when I added it.
> 
>> 3 - add the Owner and Creator items into the drop-down list for ACLs
>>
>> the output of diff -u follows
>> --- /home/charles/extract/phpwiki/lib/PagePerm.php      2004-11-15
>> 23:56:40.000000000 +0800
>> +++ ./PagePerm.php      2004-11-23 09:54:56.671875000 +0800
>> @@ -398,12 +398,14 @@
>>          if ($group === ACL_OWNER) {
>>              $page = $request->getPage();
>>              return ($user->isAuthenticated() and
>> -                    $page->getOwner() === $user->UserName());
>> +                    ( $page->getOwner() === $user->UserName() or
>> +                      $member->isMember($page->getOwner()) ));
>>          }
>>          if ($group === ACL_CREATOR) {
>>              $page = $request->getPage();
>>              return ($user->isAuthenticated() and
>> -                    $page->getCreator() === $user->UserName());
>> +                    ( $page->getCreator() === $user->UserName() or
>> +                      $member->isMember($page->getCreator()) ));
> 
> 
> Thanks. I'll add something like this. Just cached to avoid the double call.
> 
>         if ($group === ACL_OWNER) {
>             if (!$user->isAuthenticated()) return false;
>             $page = $request->getPage();
>             $owner = $page->getOwner();
>             return ($owner === $user->UserName()
>                     or $member->isMember($owner));
>         }
>         if ($group === ACL_CREATOR) {
>             if (!$user->isAuthenticated()) return false;
>             $page = $request->getPage();
>             $creator = $page->getCreator();
>             return ($creator === $user->UserName()
>                     or $member->isMember($creator));
>         }
> 
> 
>>          }
>>          /* Or named groups or usernames.
>>             Note: We don't seperate groups and users here.
>> @@ -557,6 +559,9 @@
>>                                       HTML::th(_("Description"))));
>>
>>          $allGroups = $this->_group->_specialGroups();
>> +        $allGroups[] = ACL_OWNER;
>> +        $allGroups[] = ACL_CREATOR;
> 
> 
> We should really add these to the _specialGroups().
> I forgot that when I implemented those groups in the WikiDB.
> 
>> +
>>          foreach ($this->_group->getAllGroupsIn() as $group) {
>>              if (!in_array($group,$this->_group->specialGroups()))
>>                  $allGroups[] = $group;
> 
> 
> Anyway, many thanks for the debugging. I'll check it.
> 


-- 
Reini Urban
http://xarch.tu-graz.ac.at/home/rurban/

Re: [Phpwiki-talk] Multiple PhpWiki instances

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

Manuel VACELET schrieb:
> Is there any way to provide easily multiple instance of phpwiki form one 
> phpwiki installation?

yes, something like:
   http://phpwiki.sourceforge.net/phpwiki/WikiFarm

I posted several of my starter scripts some time ago. See the -talk archive.

-- 
Reini Urban
http://xarch.tu-graz.ac.at/home/rurban/

[Phpwiki-talk] Re: groups and perm patches

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

Charles Corrigan schrieb:
> Hi,
> 
> I have been working on getting ACLs working to my liking when using WikiPage
> permissions (i.e. I am not certain that what I have done is OK yet). My
> changes are incomplete but here's an interim drop - please let me know if I
> am on the wrong track. Similar changes may be required for the differing
> types of permissioning (DB, FILE etc).
> 
> In particular, the changes to PagePerm.php are not very well tested. One
> issue delaying testing is that the display of the page owner does not appear
> to work correctly all the time, particularly that generated in
> lib/plugin/WikiAdminSetACL.php and lib/plugin/WikiAdminChown.php plugins
> (probably the issue is in the lib/plugin/WikiAdminSelect.php plugin). Or it
> may be that I am bending things too far out of shape
> 
> Regards,
> Charles
> 
> lib/WikiGroup.php:
> The changes are
> 1 - the check in case GROUP_BOGO_USER seems to be bogus (!), fix
> 2 - allow group pages to have the link to the user page in [ ] brackets
> 3 - fix up the implementation of GroupWikiPage::getMembersOf and allow the
> user page to be linked in [ ] brackets

I'll check those fixes in.

> the output of diff -u follows
> --- /home/charles/extract/phpwiki/lib/WikiGroup.php     2004-11-20
> 03:22:03.000000000 +0800
> +++ ./WikiGroup.php     2004-11-23 11:08:56.546875000 +0800
> @@ -321,7 +321,7 @@
>              return $users;
>          case GROUP_BOGOUSER:
>              foreach ($all as $u) {
> -                if (isWikiWord($user)) $users[] = $u;
> +                if (isWikiWord($u)) $users[] = $u;

good catch!

>              }
>              return $users;
>          case GROUP_SIGNED:
> @@ -508,7 +508,7 @@
>              return false;
>          }
>          $contents = $group_revision->getContent();
> -        $match = '/^\s*[\*\#]+\s*' . $this->username . '\s*$/';
> +        $match = '/^\s*[\*\#]+\s*\[?' . $this->username . '\]?\s*$/';

ok, makes sense.

whitespace issues left out:
* [ ReiniUrban ]
is disallowed, just:
* [ReiniUrban]

>          foreach ($contents as $line){
>              if (preg_match($match, $line)) {
>                  return true;
> @@ -559,21 +559,16 @@
>         if ($this->specialGroup($group))
>              return $this->getSpecialMembersOf($group);
> 
> -        trigger_error("GroupWikiPage::getMembersOf is not yet implimented",
> -                      E_USER_WARNING);
> -        return array();
> -        /*
> -        * Waiting for a reliable way to check if a string is a username.
> -        $request = $this->request;
> +        global $request;
>          $user = $this->user;
>          $group_page = $request->getPage($group);
>          $group_revision = $group_page->getCurrentRevision();
>          if ($group_revision->hasDefaultContents()) {
>              trigger_error("Group $group does not exist", E_USER_WARNING);
> -            return false;
> +            return array();
>          }
>          $contents = $group_revision->getContent();
> -        $match = '/^(\s*[\*\#]+\s*)(\w+)(\s*)$/';
> +        $match = '/^(\s*[\*\#]+\s*\[?)(\w+)(\]?\s*)$/';
>          $members = array();
>          foreach($contents as $line){
>              $matches = array();
> @@ -582,7 +577,6 @@
>              }
>          }
>          return $members;
> -        */
>      }
>  }

Good to have the explicit link syntax also.
kinda hairy, maybe check the linkextractor instead, but I defer that to 
later.
I added something like this now. Better than nothing indeed.

> lib/PagePerm.php:
> The changes are
> 1 - allow ACL_OWNER to check a group owner, not just a user owner - not
> fully tested
> 2 - allow ACL_CREATOR to check a group owner, not just a user owner - not
> fully tested

just a note: owner and creators cannot be groups, just users, because 
authenticated is just a user, which might optionally belong to a group.

but the perm check against group membership is ok.
I forgot that, when I added it.

> 3 - add the Owner and Creator items into the drop-down list for ACLs
> 
> the output of diff -u follows
> --- /home/charles/extract/phpwiki/lib/PagePerm.php      2004-11-15
> 23:56:40.000000000 +0800
> +++ ./PagePerm.php      2004-11-23 09:54:56.671875000 +0800
> @@ -398,12 +398,14 @@
>          if ($group === ACL_OWNER) {
>              $page = $request->getPage();
>              return ($user->isAuthenticated() and
> -                    $page->getOwner() === $user->UserName());
> +                    ( $page->getOwner() === $user->UserName() or
> +                      $member->isMember($page->getOwner()) ));
>          }
>          if ($group === ACL_CREATOR) {
>              $page = $request->getPage();
>              return ($user->isAuthenticated() and
> -                    $page->getCreator() === $user->UserName());
> +                    ( $page->getCreator() === $user->UserName() or
> +                      $member->isMember($page->getCreator()) ));

Thanks. I'll add something like this. Just cached to avoid the double call.

         if ($group === ACL_OWNER) {
             if (!$user->isAuthenticated()) return false;
             $page = $request->getPage();
             $owner = $page->getOwner();
             return ($owner === $user->UserName()
                     or $member->isMember($owner));
         }
         if ($group === ACL_CREATOR) {
             if (!$user->isAuthenticated()) return false;
             $page = $request->getPage();
             $creator = $page->getCreator();
             return ($creator === $user->UserName()
                     or $member->isMember($creator));
         }


>          }
>          /* Or named groups or usernames.
>             Note: We don't seperate groups and users here.
> @@ -557,6 +559,9 @@
>                                       HTML::th(_("Description"))));
> 
>          $allGroups = $this->_group->_specialGroups();
> +        $allGroups[] = ACL_OWNER;
> +        $allGroups[] = ACL_CREATOR;

We should really add these to the _specialGroups().
I forgot that when I implemented those groups in the WikiDB.

> +
>          foreach ($this->_group->getAllGroupsIn() as $group) {
>              if (!in_array($group,$this->_group->specialGroups()))
>                  $allGroups[] = $group;

Anyway, many thanks for the debugging. I'll check it.

-- 
Reini Urban
http://xarch.tu-graz.ac.at/home/rurban/

[Phpwiki-talk] Multiple PhpWiki instances

[Manuel V. <man...@st...>]

Hi all,

Is there any way to provide easily multiple instance of phpwiki form one 
phpwiki installation?

Regards,
Manuel

[Phpwiki-talk] (no subject)

[Charles C. <ch...@ru...>]

Hi,

I have been working on getting ACLs working to my liking when using WikiPage
permissions (i.e. I am not certain that what I have done is OK yet). My
changes are incomplete but here's an interim drop - please let me know if I
am on the wrong track. Similar changes may be required for the differing
types of permissioning (DB, FILE etc).

In particular, the changes to PagePerm.php are not very well tested. One
issue delaying testing is that the display of the page owner does not appear
to work correctly all the time, particularly that generated in
lib/plugin/WikiAdminSetACL.php and lib/plugin/WikiAdminChown.php plugins
(probably the issue is in the lib/plugin/WikiAdminSelect.php plugin). Or it
may be that I am bending things too far out of shape

Regards,
Charles

lib/WikiGroup.php:
The changes are
1 - the check in case GROUP_BOGO_USER seems to be bogus (!), fix
2 - allow group pages to have the link to the user page in [ ] brackets
3 - fix up the implementation of GroupWikiPage::getMembersOf and allow the
user page to be linked in [ ] brackets

the output of diff -u follows
--- /home/charles/extract/phpwiki/lib/WikiGroup.php     2004-11-20
03:22:03.000000000 +0800
+++ ./WikiGroup.php     2004-11-23 11:08:56.546875000 +0800
@@ -321,7 +321,7 @@
             return $users;
         case GROUP_BOGOUSER:
             foreach ($all as $u) {
-                if (isWikiWord($user)) $users[] = $u;
+                if (isWikiWord($u)) $users[] = $u;
             }
             return $users;
         case GROUP_SIGNED:
@@ -508,7 +508,7 @@
             return false;
         }
         $contents = $group_revision->getContent();
-        $match = '/^\s*[\*\#]+\s*' . $this->username . '\s*$/';
+        $match = '/^\s*[\*\#]+\s*\[?' . $this->username . '\]?\s*$/';
         foreach ($contents as $line){
             if (preg_match($match, $line)) {
                 return true;
@@ -559,21 +559,16 @@
        if ($this->specialGroup($group))
             return $this->getSpecialMembersOf($group);

-        trigger_error("GroupWikiPage::getMembersOf is not yet implimented",
-                      E_USER_WARNING);
-        return array();
-        /*
-        * Waiting for a reliable way to check if a string is a username.
-        $request = $this->request;
+        global $request;
         $user = $this->user;
         $group_page = $request->getPage($group);
         $group_revision = $group_page->getCurrentRevision();
         if ($group_revision->hasDefaultContents()) {
             trigger_error("Group $group does not exist", E_USER_WARNING);
-            return false;
+            return array();
         }
         $contents = $group_revision->getContent();
-        $match = '/^(\s*[\*\#]+\s*)(\w+)(\s*)$/';
+        $match = '/^(\s*[\*\#]+\s*\[?)(\w+)(\]?\s*)$/';
         $members = array();
         foreach($contents as $line){
             $matches = array();
@@ -582,7 +577,6 @@
             }
         }
         return $members;
-        */
     }
 }


lib/PagePerm.php:
The changes are
1 - allow ACL_OWNER to check a group owner, not just a user owner - not
fully tested
2 - allow ACL_CREATOR to check a group owner, not just a user owner - not
fully tested
3 - add the Owner and Creator items into the drop-down list for ACLs

the output of diff -u follows
--- /home/charles/extract/phpwiki/lib/PagePerm.php      2004-11-15
23:56:40.000000000 +0800
+++ ./PagePerm.php      2004-11-23 09:54:56.671875000 +0800
@@ -398,12 +398,14 @@
         if ($group === ACL_OWNER) {
             $page = $request->getPage();
             return ($user->isAuthenticated() and
-                    $page->getOwner() === $user->UserName());
+                    ( $page->getOwner() === $user->UserName() or
+                      $member->isMember($page->getOwner()) ));
         }
         if ($group === ACL_CREATOR) {
             $page = $request->getPage();
             return ($user->isAuthenticated() and
-                    $page->getCreator() === $user->UserName());
+                    ( $page->getCreator() === $user->UserName() or
+                      $member->isMember($page->getCreator()) ));
         }
         /* Or named groups or usernames.
            Note: We don't seperate groups and users here.
@@ -557,6 +559,9 @@
                                      HTML::th(_("Description"))));

         $allGroups = $this->_group->_specialGroups();
+        $allGroups[] = ACL_OWNER;
+        $allGroups[] = ACL_CREATOR;
+
         foreach ($this->_group->getAllGroupsIn() as $group) {
             if (!in_array($group,$this->_group->specialGroups()))
                 $allGroups[] = $group;

Re: [Phpwiki-talk] Security problem in PHPWiki sessions

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

Matthew Palmer schrieb:
> I've just had a bug reported against the Debian version of PHPWiki, whereby
> multiple wikis on the same site share a common session, and so logging into
> one site can possibly give you elevated privileges on another wiki on the
> same website.  The original bug report is available at
> http://bugs.debian.org/282565.

Imho we don't need a new SESSION_PREFIX constant.
Normally you would change the session.name and session.save_path on the 
php side.
Since phpwiki just uses php sessions I wouldn't try to fix it at our 
side, when it's simplier done on the php level.
This problem is common for all shared hosts environments, with common 
SID and save_path.

We already support the user specific COOKIE_DOMAIN and SESSION_SAVE_PATH 
vars, which would seperate between different wiki's on the same host.
The shared WIKI_ID on mult. wiki's on the same host is on purpose.
This is just the username, not the authlevel.

But when it comes to our DbSession storage, it is true that better we 
should fix it. I'll investigate for this case.
How to seperate?
Both vhost and WIKI_NAME seems easiest and appropriate to me.

> While the report was against 1.3.7, and I've not had a chance to verify
> whether the problem still exists against 1.3.10, I've looked through
> the CVS logs for lib/Request.php, and can't find any commits which appear to
> fix the problem.

There's a new cookie policy in effect since 2004/04/02:
WIKI_ID is explictly shared, old-style cookies are converted.
Possibly shared cookies with empty "/" path are deleted also on logout.
prefs are not carried in cookies anymore, only the sid and username.

> I intend to work up some test cases for this problem to verify the problem,
> and try and get a solid fix for the problem, but it's a trickier problem
> than it appear at first.  The bug reporter suggested including the WikiName
> in the Cookie/SID variable name, but that won't work if you've got multiple
> wikis with the same name.  Similarly, restricting the cookie to a particular
> path won't necessarily help, as I've got several wikis running in the same
> directory with different filenames.

php folks added a better session hash method lately because of similar 
reports, but I doubt that a clash will ever happen, that a random md5 
will ever be same. I'd like to see the maths.
The evil scenario is more likely that someone steals the hash somehow, 
and then a better hash wouldn't help.

> The safest fix I've come up with is to store a hash of the main script file
> (or config file, perhaps) in the session, check it on startup, and
> invalidate the session if the hash doesn't match.  It's a wank, though,
> because it'll be slow as shit, and not cover various corner cases.  I
> welcome the suggestions of people with more knowledge of these things than
> me, though.
-- 
I believe that if it were left to artists to choose their own labels, 
most would choose none. (Ben Shahn)

[Phpwiki-talk] Security problem in PHPWiki sessions

[Matthew P. <mp...@he...>]

I've just had a bug reported against the Debian version of PHPWiki, whereby
multiple wikis on the same site share a common session, and so logging into
one site can possibly give you elevated privileges on another wiki on the
same website.  The original bug report is available at
http://bugs.debian.org/282565.

While the report was against 1.3.7, and I've not had a chance to verify
whether the problem still exists against 1.3.10, I've looked through
the CVS logs for lib/Request.php, and can't find any commits which appear to
fix the problem.

I intend to work up some test cases for this problem to verify the problem,
and try and get a solid fix for the problem, but it's a trickier problem
than it appear at first.  The bug reporter suggested including the WikiName
in the Cookie/SID variable name, but that won't work if you've got multiple
wikis with the same name.  Similarly, restricting the cookie to a particular
path won't necessarily help, as I've got several wikis running in the same
directory with different filenames.

The safest fix I've come up with is to store a hash of the main script file
(or config file, perhaps) in the session, check it on startup, and
invalidate the session if the hash doesn't match.  It's a wank, though,
because it'll be slow as shit, and not cover various corner cases.  I
welcome the suggestions of people with more knowledge of these things than
me, though.

- Matt

[Phpwiki-talk] Install trouble

[Phil T. <pth...@sf...>]

Hi all,


Sorry if this is a common question, but I couldn't really find the answer on
the website or other places I looked.



I just installed phpwiki on my Mac OS X box with php 4.3.2, but index.php is
blank. I changed lib/config.php to put the dbm files in a dir called tmp in
the phpwiki dir (which I created), but the dbm files don't exist anywhere;
how do I cause them to be created? Which DBM filetype should I be using?



Sorry, I'm a newbie to php and such, so if there is a place other than here
where I should be looking for this info (other than the INSTALL and README
files in the tarball, which I've looked through without much luck), please
let me know. 



Thanks!



Phil







++++++++++++++++++++++++++++++

+ Phil Thomson

+ http://www.sfu.ca/~pthomson/

+ http://www.centibel.org/

++++++++++++++++++++++++++++++

Re: [Phpwiki-talk] Custom forms -- Appending to existing page

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

Pascal Giard (QC/EMC) schrieb:
>   i was looking thru main.php and WikiFormRich.php and noticed that it's 
> possible to edit OR create a page via forms, but not to append text 
> (well not directly).

you need a action to do that.
actions are best handled by actionpages calling a custom plugin.

> I simply want a form that will append Text to a Page.
> Should i modify main.php to support a new kind of action, namely 
> "append" or something like it ?

no, better write a plugin like AppendText.

> I'd simlpy make it do something like:
>         $current = $pagehandle->getCurrentRevision();
>         $version = $current->getVersion();
>         $text = $current->getPackedContent();
>         $newtext = $text . "\n A processed version of the stuff 
> contained in my form.";
>         $meta = $current->_data;
>         $meta['summary'] = sprintf(_("Updated %s"),$page);
>         $pagehandle->save($newtext, $version + 1, $meta);
> 
> Or should i be calling another plugin ?
> 
> Where can i find more Documentation on the tips and [magic] tricks with 
> WikiForm[Rich] ?

not yet. sorry.

-- 
Reini Urban
http://xarch.tu-graz.ac.at/home/rurban/