phpwiki-talk

Re: [Phpwiki-talk] Wiki spam and the future of phpwiki

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

Arnaud Fontaine wrote:
> I think we must find a different dev/commit model to attract more
> developpers and ... keep us working on phpwiki ... Should we have
> several cvs/svn trees and decide on a process to merge them every ...
> week ? Or have several cvs branches ? Should Reini or Steve give write
> access to any/more contributors ?

I think opening a svn repository for phpwiki is a good thing. With https 
access everyone can access to source code (even if you are barbarian proxy).



-- 
# VACELET Manuel     manuel.vacelet-abecedaire(at)st(dot)com #
# Tel:  042 6089                          +33 (0)476 92 6089 #
# STMicroelectronics - HPC/STS                               #
# 850, rue Jean Monet - 38926 CROLLES CEDEX - FRANCE         #

Re: [Phpwiki-talk] Wiki spam and the future of phpwiki

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

> | Releasing more often is probably also important.
>
> "Release early, release often" .. That's one of the main bazaar rules.
> It's really important for the developpement to go nicely.

I don't feel comfortable with releasing bad stuff.
And I empathize with the administrators who have to update their wikis.

> | Finally, I believe this goal would be aided if there were much less
> code | to maintain. For example, support only one backend. I see so much
> work | going into different database ports, needlessly. I vote for
> MySQL, since | that is what I am using. However, I might even go with a
> CVS backend | (*shudder*) if that were the community's will, as long as
> it supported | query-able relationships between 2 things (exactly like
> backlinks, or | we've expanded also to ratings, categories, and in the
> future perhaps | list items), and multiple instances from the same code
> base (currently | with multiple MySQL DBs).
>
> About backend, I really like the "large" choice of backends. But maybe
> the persistence abstraction layer is not that good ... that means too
> much work in the backend layer ...
> Maybe we should keep only one SQL library (ADODB ? PEAR ?) ... but we
> shouldn't drop flatfile, cvs, dba, etc ... they are very important, make
> the install process very simple in most cases ...

IMHO that's not the problem.

> I think we must find a different dev/commit model to attract more
> developpers and ... keep us working on phpwiki ... Should we have
> several cvs/svn trees and decide on a process to merge them every ...
> week ? Or have several cvs branches ? Should Reini or Steve give write
> access to any/more contributors ?

We have 4 admins!
A lot of people have write access!
But almost nobody helps out.

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

Re: [Phpwiki-talk] PhpWiki process

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

Hello Charles,

Charles Corrigan wrote:
> There are lots of people discussing the current state of PhpWiki, the features, test coverage and the development process.
> 
> Unfortunately, I do not see many positive contributions.
> - I do not see many contributors sending in patches.
> - I do not see many contributors sending in test results.

I read this list since July 2004 because I integrated phpwiki in a 
"forge" (comparable to GForge).
We choose PhpWiki against MediaWiki for many reasons (modular design, 
syntax, ...) and after 4 month in production we are very happy with our 
initial choice: it works _really_ fine.
I make few patch in phpwiki code (mainly on database backend) and I 
contributed to CreateToc plugin but my patch was not integrated.

> How many people have downloaded the 1.3.11-rc/beta and tested it?

I haven't downloaded 1.3.11 beta because I don't have CVS access and I 
currently don't have many time for this job.

Again, we founded phpwiki very easy to adapt to our environnement.
Next developments planned are:
* migration to 1.3.11 (stable !!)
* clean our source code
* contribute to Gforge PhpWiki plugin

My 2 cents,
Manuel

-- 
# VACELET Manuel     manuel.vacelet-abecedaire(at)st(dot)com #
# Tel:  042 6089                          +33 (0)476 92 6089 #
# STMicroelectronics - HPC/STS                               #
# 850, rue Jean Monet - 38926 CROLLES CEDEX - FRANCE         #

RE: [Phpwiki-talk] Re: secure phpwiki: request for example

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

Hi,

In the config.ini, check the value of USER_AUTH_ORDER

It is possible that you have USER_AUTH_ORDER = "'Db'"
which is one possible cause of the error message.
Also check that the file lib/WikiUser/Db.php exists

Regards,
Charles

-----Original Message-----
From: Stan Berka [mailto:sb...@po...] 
Sent: 01 April 2005 06:14
To: php...@li...
Subject: [Phpwiki-talk] Re: secure phpwiki: request for example

Well, I have installed the 1.3.11 rc1 and here's what I've got.

First time ran phpwiki, there was a problem with '/** ... */' comment in 
stlib.php.  PHP 4.3.10 considers this as an unterminated comment.

After I've fixed the comment and ran configurator, it told me it wasn't 
able to write down the file when trying to save it.  I have placed the 
generated config.ini manually.

Then, on my first visit to HomePage, I've got the following warning:
lib/main.php:66: Warning: wikirequest(lib/WikiUser/'Db'.php): failed to 
open stream: No such file or directory (...repeated 2 times). 
I've ignored it.

After that, when I typed in a StanBerka as user and requested a sign-in, 
I've got:
Fatal error: Cannot instantiate non-existent class: _'db'passuser in 
/home/berka8f/public_html/phpwiki-1.3.11/lib/WikiUserNew.php on line 1123

I'm stuck.  Can anyone help me?

-- 
Best regards,
Stan Berka
Senior Programmer Analyst
Pope & Talbot, Inc.
Portland, OR
503 552-4315



-------------------------------------------------------
This SF.net email is sponsored by Demarc:
A global provider of Threat Management Solutions.
Download our HomeAdmin security software for free today!
http://www.demarc.com/Info/Sentarus/hamr30
_______________________________________________
Phpwiki-talk mailing list
Php...@li...
https://lists.sourceforge.net/lists/listinfo/phpwiki-talk

[Phpwiki-talk] Re: secure phpwiki: request for example

[Stan B. <sb...@po...>]

Well, I have installed the 1.3.11 rc1 and here's what I've got.

First time ran phpwiki, there was a problem with '/** ... */' comment in 
stlib.php.  PHP 4.3.10 considers this as an unterminated comment.

After I've fixed the comment and ran configurator, it told me it wasn't 
able to write down the file when trying to save it.  I have placed the 
generated config.ini manually.

Then, on my first visit to HomePage, I've got the following warning:
lib/main.php:66: Warning: wikirequest(lib/WikiUser/'Db'.php): failed to 
open stream: No such file or directory (...repeated 2 times). 
I've ignored it.

After that, when I typed in a StanBerka as user and requested a sign-in, 
I've got:
Fatal error: Cannot instantiate non-existent class: _'db'passuser in 
/home/berka8f/public_html/phpwiki-1.3.11/lib/WikiUserNew.php on line 1123

I'm stuck.  Can anyone help me?

-- 
Best regards,
Stan Berka
Senior Programmer Analyst
Pope & Talbot, Inc.
Portland, OR
503 552-4315

Re: [Phpwiki-talk] PhpWiki process

[Philip J. H. <ph...@po...>]

Charles, I have to diagree with you somewhat on this.  While I agree
that aimless complaining is generally not very productive, I think  that
in the case of phpwiki the emails are serving a useful purpose: to let
the developers know that there is a user base and we would really love
to see some things happen (like a 1.3.11 release).

The most useful result of this whole discussion (for me) has been the
discovery of the spam fighting features that are being worked on.

I for one have not downloaded and tested the 1.3.11 beta because I
freely admit I haven't had the time to do it.  However, the new spam
protection stuff makes me much more likely to do so.  Hopefully others
on the list have been encouraged by these emails as well.

So having said all that, I do generally agree with you that actions
(i.e. submitting bug reports and fixes) speak louder than words.

P.

On Fri, 1 Apr 2005 01:02:04 +0800, "Charles Corrigan"
<ch...@ru...> said:
> There are lots of people discussing the current state of PhpWiki, the
> features, test coverage and the development process.
> 
> Unfortunately, I do not see many positive contributions.
> - I do not see many contributors sending in patches.
> - I do not see many contributors sending in test results.
> 
> How many people have downloaded the 1.3.11-rc/beta and tested it?
> 
> Projects like PhpWiki do not progress by people emailing in complaints
> about process, state or features (unless they are bug
> reports). Work gets done by people working on it. Reini has done a huge
> amount and few others have done even a fraction of that.
> 
> OK, now for my positive, but minor contribution. A few days before the RC
> release I took the latest CVS, tested it locally and then
> put it live on my public website http://www.runegate.org/whitewall/wiki
> 
> I am aware of two (known) bugs that affect the site:
> 1: SetAcl does not remember the changes made on the first page (i.e.
> changes made before clicking "SetAcl") when it displays the
> second confirmation page.
> 2: After Chown, a page displays the old owner at the bottom but when
> queried through PageInfo or Chown, it shows the correct owner.
> 
> I have looked at both of these problems before but have not been able to
> work out what's happening and so have not been able to
> submit patches :-(
--  
Philip J. Hollenback
ph...@po...
www.hollenback.net

[Phpwiki-talk] PhpWiki process

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

There are lots of people discussing the current state of PhpWiki, the features, test coverage and the development process.

Unfortunately, I do not see many positive contributions.
- I do not see many contributors sending in patches.
- I do not see many contributors sending in test results.

How many people have downloaded the 1.3.11-rc/beta and tested it?

Projects like PhpWiki do not progress by people emailing in complaints about process, state or features (unless they are bug
reports). Work gets done by people working on it. Reini has done a huge amount and few others have done even a fraction of that.

OK, now for my positive, but minor contribution. A few days before the RC release I took the latest CVS, tested it locally and then
put it live on my public website http://www.runegate.org/whitewall/wiki

I am aware of two (known) bugs that affect the site:
1: SetAcl does not remember the changes made on the first page (i.e. changes made before clicking "SetAcl") when it displays the
second confirmation page.
2: After Chown, a page displays the old owner at the bottom but when queried through PageInfo or Chown, it shows the correct owner.

I have looked at both of these problems before but have not been able to work out what's happening and so have not been able to
submit patches :-(

Regards,
Charles

Re: [Phpwiki-talk] Wiki spam and the future of phpwiki

[Arnaud F. <ar...@cr...>]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Dan Frankowski wrote:
| Stability, fully functional, easy to use, well-documented features are
| very important, more important than most new features. It is a lot of
| work to take a feature from "a good first shot" to easy to use and
| obviously great.
|
| Releasing more often is probably also important.

"Release early, release often" .. That's one of the main bazaar rules.
It's really important for the developpement to go nicely.

| Finally, I believe this goal would be aided if there were much less code
| to maintain. For example, support only one backend. I see so much work
| going into different database ports, needlessly. I vote for MySQL, since
| that is what I am using. However, I might even go with a CVS backend
| (*shudder*) if that were the community's will, as long as it supported
| query-able relationships between 2 things (exactly like backlinks, or
| we've expanded also to ratings, categories, and in the future perhaps
| list items), and multiple instances from the same code base (currently
| with multiple MySQL DBs).

About backend, I really like the "large" choice of backends. But maybe
the persistence abstraction layer is not that good ... that means too
much work in the backend layer ...
Maybe we should keep only one SQL library (ADODB ? PEAR ?) ... but we
shouldn't drop flatfile, cvs, dba, etc ... they are very important, make
the install process very simple in most cases ...

I think we must find a different dev/commit model to attract more
developpers and ... keep us working on phpwiki ... Should we have
several cvs/svn trees and decide on a process to merge them every ...
week ? Or have several cvs branches ? Should Reini or Steve give write
access to any/more contributors ?

Arnaud

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.0 (GNU/Linux)
Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org

iD8DBQFCTCTryAf3wgFyy1ARAhYsAKCsjDUUg/XMz/LPjADubXumN8hHrwCgjLKQ
bmKHch10qY8HurDDHEpSNOc=
=UyPK
-----END PGP SIGNATURE-----

Re: Fwd: Re: [Phpwiki-talk] Wiki spam and the future of phpwiki

[Amilcar do C. L. <am...@id...>]

On Thursday 31 March 2005 17:49, Philip J. Hollenback wrote:
> > I've lately completed a CAPTCHA, which is extremely easy to integrate
> > even if you don't have years of PHP experience.
> > http://freshmeat.net/p/captchaphp While allowing you to keep your Wiki
> > open, it's still a bit anti-Wiki to use captchas; but as last resort I
> > would recommend it.
I agree with this one.
Registered users would not be asked for it, but anonymous edits would be asked 
for it.

You would also be asked for it during registering.

Why wouldn't this reduce wiki spam 100% ?

-- 
Amilcar Lucas
Current webmaster
The KDevelop project

Fwd: Re: [Phpwiki-talk] Wiki spam and the future of phpwiki

[Philip J. H. <ph...@po...>]

This is a resend.  Turns out you can't mention certain 'enhancement
drugs' in your messages to sourceforge, so the original of this was
bounced.


--  
Philip J. Hollenback
ph...@po...
www.hollenback.net

----- Original message -----
From: "Philip J. Hollenback" <ph...@po...>
To: "Mario Salzer" <ma...@er...>,
php...@li...
Date: Thu, 31 Mar 2005 10:43:31 -0500
Subject: Re: [Phpwiki-talk] Wiki spam and the future of phpwiki

Thanks for the well-reasoned response.

It is true I know a lot more about the phpwiki code than the pmwiki
code, so you could be entirely right there.  However, I do think the
point about phpwiki just covering way to many bases (in particular with
things like database support) is a really important one - it makes
testing phpwiki really, really difficult.

The bugs certainly can be fixed - but will they?  Or, will new features
continue to be added instead?  That is what I am unsure about with
phpwiki.  I am very curious to see the 1.3.11 release.

The big thing I like about pmwiki is it's quite a bit simpler than
phpwiki, and thus hopefully there are fewer chances for bugs.  That's my
optimistic guess, anyway.

I will say that thanks to the responses on this list about the new
features in 1.3.11 (in particular to combat spam) I am beginning to move
back towards keeping my site on phpwiki.  Plus I'm lazy and converting
to another wiki is too much work. :)

Some more comments below:

On Thu, 31 Mar 2005 17:14:18 +0200, "Mario Salzer"
<ma...@er...> said:
> I can't comment much on PhpWiki development, but I doubt that any
> eventual bugs couldn't be fixed. As for PmWiki, I think you're trading
> something robust for spaghetti code and one of the more weird Wiki
> markups around, if you'd really switch.

The markup is different, but I find it a bit more intuitive in some
ways.  In particular, the link markup of

[[ Some Text -> http://www.hollenback.net ]]

or whatever is particularly easy to remember.  That's just a personal
opinion, though.

> Link spam is a problem that escalated only this year, so it's clear
> that we all first need to find "THE solution" to it. IP blocking and
> whatnot blacklist however seem to be more hassle than they help here.
> I had best results with blocking posts that contained more than a
> fixed number of new links. AFAIK there is already such a plugin for
> PhpWiki, so you should give that a try. (it's called
> "LimitExternalLinks" elsewhere)

Yes, several people have pointed that out, and it seems a good way to
go.

> I've lately completed a CAPTCHA, which is extremely easy to integrate
> even if you don't have years of PHP experience.
> http://freshmeat.net/p/captchaphp While allowing you to keep your Wiki
> open, it's still a bit anti-Wiki to use captchas; but as last resort I
> would recommend it.

I don't particularly like captchas, but I am willing to try using them
if it means I can leave my wiki open.

> Most link spam hits the Wikis only accidentally, and was originally
> targeted at BBcode- or HTML-enabled blog/comment sections. You'll
> need something that blocks any "/^<a.+</a>$/" edit form submissions
> then (also easy to do).
>
> In your case (500 edits) it however sounds like you've been attacked
> targetedly - in such cases no anti-spam plugin will help you and
> cleaning up the mess afterwards is the only solution. If you're using
> a SQL database - that's often forgotten - then it's a snap to wipe
> hundreds of pages at once, depending on a timestamp. Else you only
> need the right tools - the funny WikiCommander and the "mass revert"
> tools in the Wiki I'm working on would do. (I'm link spamming here ;)
> http://erfurtwiki.sf.net/tools/ Our database API is extremely
> simplistic, and so writing up some glue code for PhpWikis should be
> trivial (right now we only have a PW plugin without ::DELETE support).

It was specifically targeted, but the pages were all fairly similar and
they appeared within a few minutes (maybe 30).  Thus I think they were
scripted in some way.  The attack also exhibited some knowledge of
phpwiki - the pages were added by a user called WikiGuest, so the
attacker know about BogoLogins on phpwiki.

I'm actually surprised they were done as 'minor edits' too, which would
have kept me from finding them even longer.

I was able to delete multiple pages at once by using the admin interface
to phpwiki and selecting on page names, so I could delete all 20 pages
with certain words in the title, etc.  Ideally the admin interface will
be
expanded so I can do things like 'delete all pages created within the
last hour' or similar.

If my phpwiki had rate limiting, multiple link page rejection, and
mass-delete admin tools, I could have managed this attack pretty
quickly.

> Whatever, I just wanted to comment that this is not a problem only
> PhpWiki faces, and people all around are testing and writing tools to
> combat link spam. And simple solutions surprisingly seem to work best.
> http://www.emacswiki.org/cw-de/WikiSpam

I am totally in agreement and I don't want to make it sound like the
spam problem is specific to phpwiki.  I think phpwiki-based wikis just
get targetted a lot because there are a lot of them out there.

This is a really good discussion because up until now this list has not
had a lot to say about wiki spam.

P.

Re: [Phpwiki-talk] Wiki spam and the future of phpwiki

[Mario S. <ma...@er...>]

Hey Philiph,

I can't comment much on PhpWiki development, but I doubt that any
eventual bugs couldn't be fixed. As for PmWiki, I think you're trading
something robust for spaghetti code and one of the more weird Wiki
markups around, if you'd really switch.

Link spam is a problem that escalated only this year, so it's clear
that we all first need to find "THE solution" to it. IP blocking and
whatnot blacklist however seem to be more hassle than they help
here.
I had best results with blocking posts that contained more than a fixed
number of new links. AFAIK there is already such a plugin for PhpWiki,
so you should give that a try. (it's called "LimitExternalLinks" elsewhere)

I've lately completed a CAPTCHA, which is extremely easy to integrate
even if you don't have years of PHP experience.
   http://freshmeat.net/p/captchaphp
While allowing you to keep your Wiki open, it's still a bit anti-Wiki to
use captchas; but as last resort I would recommend it.

Most link spam hits the Wikis only accidentially, and was originally
targetted at BBcode- or HTML-enabled blog/comment sections. You'll
need something that blocks any "/^<a.+</a>$/" edit form submissions
then (also easy to do).

In your case (500 edits) it however sounds like you've been attacked
targetedly - in such cases no anti-spam plugin will help you and
cleaning up the mess afterwards is the only solution. If you're using a
SQL database - that's often forgotten - then it's a snap to wipe hundreds
of pages at once, depending on a timestamp.
Else you only need the right tools - the funny WikiCommander and the
"mass revert" tools in the Wiki I'm working on would do. (I'm link spamming
here ;)
   http://erfurtwiki.sf.net/tools/
Our database API is extremely simplistic, and so writing up some glue
code for PhpWikis should be trivial (right now we only have a PW plugin
without ::DELETE support).

Whatever, I just wanted to comment that this is not a problem
only PhpWiki faces, and people all around are testing and writing
tools to combat link spam. And simple solutions surprisingly seem
to work best.
   http://www.emacswiki.org/cw-de/WikiSpam

mario


ph...@po... schrieb am 31.03.05 06:01:17:
> Unfortunately that's not really what I want.  My hope is to block spam
> while still allowing anonymous edits.  I think that's most in keeping
> with the wiki spirit, right?
> 
> Basically I'm ok with removing occasional spam pages, as long as there
> are mechanisms to prevent more extreme abuse (such as hundreds and
> hundreds of spam pages added all at once).

______________________________________________________________
Verschicken Sie romantische, coole und witzige Bilder per SMS!
Jetzt bei WEB.DE FreeMail: http://f.web.de/?mc=021193

RE: [Phpwiki-talk] phpwiki spam issues

[Philip J. H. <ph...@po...>]

One more thing I just thought of: is there a way to always retrieve the
IP address of the person who edited a page?

When an anonymous user edits a page, you see the IP address in
RecentChanges.  However, if the edit is done by a BogoUser, then you see
the username.

My last big spammer used a BogoUser, so the IP address wasn't
immediately apparent.

It would be nice if the RecentChanges looked like this:

WikiPage - edited by WikiUser - from 192.168.1.2

for example.

I realize you can retrieve the ip address from the web server logs, but
that is cumbersome.

P.

On Thu, 31 Mar 2005 09:12:06 -0500, "Philip J. Hollenback"
<ph...@po...> said:
> I guess what we're seeing is that spammers are finally really starting
> to hit wikis.  Maybe the crackdown on blog comment spam is forcing them
> to move?
> 
> The difficult part of this is that the wiki philosophy is all about the
> freedom for anyone to edit.  That has always freaked a lot of people
> out.  Unfortunately, they now have a good reason to be scared: spammers
> will mess with all your pages!
> 
> Thus, I really think that spam blocking / detection / limiting is THE
> big issue for wikis now.  We're at a critical point: mainstream users
> are starting to wake up to the wiki philosophy.  I just helped my
> non-technical friend set up a wiki for his work (www.dbrig.com).  Wil
> Wheaton just two days ago wondered on his blog if he should set up a
> wiki.  Now is the time for wikis - assuming the spam doesn't drown us
> all.
> 
> I really, really want to open my website www.hollenback.net back up for
> anyone to edit.  Thus it seems like blacklists and captchas are the way
> to go.  I don't want to force people to log in - that drives away the
> majority of potential contributors right away.  However, a unified login
> mechanism such as Typekey might not be so bad.
> 
> As an aside, some people say the majority of wiki spam is coming from
> China (see www.chongqed.com).  However, I see that the spam on wiki
> (until I locked it down) was coming from Russia.  What are other people
> seeing?
--  
Philip J. Hollenback
ph...@po...
www.hollenback.net

RE: [Phpwiki-talk] secure phpwiki: request for example

[Philip J. H. <ph...@po...>]

I guess what we're seeing is that spammers are finally really starting
to hit wikis.  Maybe the crackdown on blog comment spam is forcing them
to move?

The difficult part of this is that the wiki philosophy is all about the
freedom for anyone to edit.  That has always freaked a lot of people
out.  Unfortunately, they now have a good reason to be scared: spammers
will mess with all your pages!

Thus, I really think that spam blocking / detection / limiting is THE
big issue for wikis now.  We're at a critical point: mainstream users
are starting to wake up to the wiki philosophy.  I just helped my
non-technical friend set up a wiki for his work (www.dbrig.com).  Wil
Wheaton just two days ago wondered on his blog if he should set up a
wiki.  Now is the time for wikis - assuming the spam doesn't drown us
all.

I really, really want to open my website www.hollenback.net back up for
anyone to edit.  Thus it seems like blacklists and captchas are the way
to go.  I don't want to force people to log in - that drives away the
majority of potential contributors right away.  However, a unified login
mechanism such as Typekey might not be so bad.

As an aside, some people say the majority of wiki spam is coming from
China (see www.chongqed.com).  However, I see that the spam on wiki
(until I locked it down) was coming from Russia.  What are other people
seeing?

P.

ps - in regards to my website, I am hoping that the SpamAssassin plugin
will be effective.  Thus I wait for an actual 1.3.11 release.  I sure
hope that comes out soon!


On Thu, 31 Mar 2005 21:13:00 +0800, "Charles Corrigan"
<ch...@ru...> said:
> There have been a lot of fixes post 1.3.10 in this area. I suggest
> that you get 1.3.11-rc and try that. I wrote doc/README.security
> describing my mechanism to get exactly the configuration that you
> require.
>
> It's funny all of my recent posts mention this document :-)
>
> Regards, Charles
>
>
> -----Original Message----- From: Stan Berka [mailto:sb...@po...]
> Sent: 31 March 2005 06:42 To: php...@li...
> Subject: [Phpwiki-talk] secure phpwiki: request for example
>
> Hi, I have tried to configure PhpWiki in secure mode:  everyone can
> view, only authorized users can edit.  That simple.  But I've never
> succeeded.  My last try is here http://www.berka.name/phpwiki in case
> you want to try it out.  Try to sign-in.  It's ver. 1.3.10.
>
> Could anyone provide information leading to a working configuration
> like this?  I mean: which phpwiki version, provide a config file and
> any other info that matters?  This installation is on
> Linux/Apache/mysql.
>
> I'd really appreciate your help.  I'm using phpwiki in our office all
> the time; it's wonderfull, but here I need a secure mode and...
>
> I'm attaching below the config.ini from berka.name; lines commented
> out are removed.
--  
Philip J. Hollenback
ph...@po...
www.hollenback.net

RE: [Phpwiki-talk] secure phpwiki: request for example

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

There have been a lot of fixes post 1.3.10 in this area. I suggest that you get 1.3.11-rc and try that. I wrote doc/README.security
describing my mechanism to get exactly the configuration that you require.

It's funny all of my recent posts mention this document :-)

Regards,
Charles


-----Original Message-----
From: Stan Berka [mailto:sb...@po...] 
Sent: 31 March 2005 06:42
To: php...@li...
Subject: [Phpwiki-talk] secure phpwiki: request for example

Hi,
I have tried to configure PhpWiki in secure mode:  everyone can view, 
only authorized users can edit.  That simple.  But I've never 
succeeded.  My last try is here http://www.berka.name/phpwiki in case 
you want to try it out.  Try to sign-in.  It's ver. 1.3.10.

Could anyone provide information leading to a working configuration like 
this?  I mean: which phpwiki version, provide a config file and any 
other info that matters?  This installation is on Linux/Apache/mysql. 

I'd really appreciate your help.  I'm using phpwiki in our office all 
the time; it's wonderfull, but here I need a secure mode and...

I'm attaching below the config.ini from berka.name; lines commented out 
are removed.

Re: [Phpwiki-talk] Release Candidate 1

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

Dan Frankowski schrieb:
> I think having a release candidate is a very positive step forward!
> 
> However, I am confused. "Known problems?" It can't be a release 
> candidate unless you intend to release with all those problems (which 
> maybe you do?). It is not bad to release with some bugs if they are not 
> critical; all major software has bugs. However, the way it sounded below 
> was that there was going to be more work before actual release. Then 
> it's not an RC.

Ok, it's a beta then.
I'm not sure when the "Known problems to be done" should be fixed.
The wave was too cold so I got ill.

> Reini Urban wrote:
> 
>> I've made available a release candidate 1, which should fix most of the
>> problems.
>>
>> Known problems to be done:
>>
>> * wikiadmin plugin problems with subpages (rename, ...)
>> *   in diff #1169504
>> * accept email with + #1166336
>> * cannot embed plugins in RichTable plugin
>>
>> Fixed in last week:
>> * locale
>> * configurator
>> * pop3 auth
>> * adodb authinfo security flaw
>>
>> Hope I'll come to the remaining issues tomorrow, but our wave is that 
>> high this weekend, so I'll rather go surfing and fix the rest during 
>> the next week.
>> Sorry for the one month delay because of my new job, local permission 
>> problems and the austrian filmfestival.
-- 
Reini Urban
http://xarch.tu-graz.ac.at/home/rurban
http://phpwiki.org

[Phpwiki-talk] Re: [SECUNIA] PhpWiki

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

Thomas Kristensen schrieb:
> In the recent changelog for PhpWiki you describe two security issues.
> http://sourceforge.net/project/shownotes.php?release_id=315974
> 
> I would like some details about who and how this could be exploited,
> also I would like to know if any mitigating factors apply.

problem from 1.3.10 - 1.3.11
* security fix for create ACL: action=edit is now checked for create"

If someone edits the ACL to let someone edit but not create a page, and 
if someone creates a page by using the edit button, the create ACL was 
not ignored.

* fixed possible security problems: allowing only posixly strict 
usernames, and an actual LDAP Injection problem, detected by Steve 
Christey, MITRE.

LDAP auth could have been exploited by using wildcards as the username. 
See the MITRE report about that. (Sorry, no link)


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

Re: [Phpwiki-talk] Wiki spam and the future of phpwiki

[Philip J. H. <ph...@po...>]

Charles,

Thanks for the tip.  That is a good overview of how to set up
permissions on my wiki.

Unfortunately that's not really what I want.  My hope is to block spam
while still allowing anonymous edits.  I think that's most in keeping
with the wiki spirit, right?

Basically I'm ok with removing occasional spam pages, as long as there
are mechanisms to prevent more extreme abuse (such as hundreds and
hundreds of spam pages added all at once).

But again, thanks for the pointer.
P.

On 03/30/05, Charles Corrigan wrote:
> Hi,
> 
> Have you looked at doc/README.security for the approach that I took to
> eliminating WikiSpam?
> 
> Regards,
> Charles
> 
> -----Original Message-----
> From: Philip J. Hollenback [mailto:ph...@po...] 
> Sent: 30 March 2005 22:34
> To: php...@li...
> Subject: [Phpwiki-talk] Wiki spam and the future of phpwiki
> 
> I've been running phpwiki for several years on my site
> http://www.hollenback.net.  I started with the 1.2 phpwiki and have
> upgraded several times.  Currently I'm running a cvs version from some
> time after the 1.3.10 release.
> 
> <snip>
> 
> 2. Wiki spam is a major problem.  I finally had to turn off editing of
> my site last week.  The reason: large amounts of wiki spam.  For the
> last year, I've been getting perhaps one or two spam attacks a week on
> my site.  I managed that by removing or reverting pages manually, not a
> big deal.
> 
> <snip>
> 
> 
> 
> 

-- 
Philip J. Hollenback
www.hollenback.net

RE: [Phpwiki-talk] Wiki spam and the future of phpwiki

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

Hi,

Have you looked at doc/README.security for the approach that I took to eliminating WikiSpam?

Regards,
Charles

-----Original Message-----
From: Philip J. Hollenback [mailto:ph...@po...] 
Sent: 30 March 2005 22:34
To: php...@li...
Subject: [Phpwiki-talk] Wiki spam and the future of phpwiki

I've been running phpwiki for several years on my site
http://www.hollenback.net.  I started with the 1.2 phpwiki and have
upgraded several times.  Currently I'm running a cvs version from some
time after the 1.3.10 release.

<snip>

2. Wiki spam is a major problem.  I finally had to turn off editing of
my site last week.  The reason: large amounts of wiki spam.  For the
last year, I've been getting perhaps one or two spam attacks a week on
my site.  I managed that by removing or reverting pages manually, not a
big deal.

<snip>

[Phpwiki-talk] secure phpwiki: request for example

[Stan B. <sb...@po...>]

Hi,
I have tried to configure PhpWiki in secure mode:  everyone can view, 
only authorized users can edit.  That simple.  But I've never 
succeeded.  My last try is here http://www.berka.name/phpwiki in case 
you want to try it out.  Try to sign-in.  It's ver. 1.3.10.

Could anyone provide information leading to a working configuration like 
this?  I mean: which phpwiki version, provide a config file and any 
other info that matters?  This installation is on Linux/Apache/mysql. 

I'd really appreciate your help.  I'm using phpwiki in our office all 
the time; it's wonderfull, but here I need a secure mode and...

I'm attaching below the config.ini from berka.name; lines commented out 
are removed.

-- 
Best regards,
Stan Berka
Senior Programmer Analyst
Pope & Talbot, Inc.
Portland, OR
503 552-4315

--- config.ini

DEBUG = 1

ENABLE_USER_NEW = true


WIKI_NAME = BerkaWiki

ENABLE_REVERSE_DNS = true

ADMIN_USER = admin
ADMIN_PASSWD = <snip>

ENCRYPTED_PASSWD = true

ZIPDUMP_AUTH = false

ENABLE_RAW_HTML = false;

STRICT_MAILABLE_PAGEDUMPS = false

HTML_DUMP_SUFFIX = .html

MAX_UPLOAD_SIZE = 16777216

MINOR_EDIT_TIMEOUT = 604800

CACHE_CONTROL = LOOSE

CACHE_CONTROL_MAX_AGE = 600



DATABASE_TYPE = SQL
   

DATABASE_DSN = "mysql://berka8f_admin:<snip>@localhost/berka8f_phpwiki"

DATABASE_SESSION_TABLE = session

DATABASE_DIRECTORY = /tmp

DATABASE_DBA_HANDLER = gdbm

DATABASE_TIMEOUT = 20


MAJOR_MAX_AGE = 32
MAJOR_KEEP = 8

MINOR_MAX_AGE = 7
MINOR_KEEP = 4

AUTHOR_MAX_AGE = 365
AUTHOR_KEEP = 8
AUTHOR_MIN_AGE = 7
AUTHOR_MAX_KEEP = 20


ALLOW_ANON_USER = true
ALLOW_ANON_EDIT = false

ALLOW_BOGO_LOGIN = false

ALLOW_USER_PASSWORDS = true

USER_AUTH_ORDER = "Db"

PASSWORD_LENGTH_MINIMUM = 6
    
USER_AUTH_POLICY = first-only

LDAP_AUTH_HOST = "ldap://localhost:389"

LDAP_BASE_DN = "ou=Users,o=Development,dc=mycompany.com"

GROUP_METHOD = WIKIPAGE


DBAUTH_AUTH_DSN = "mysql://berka8f_admin:<snip>@localhost/berka8f_phpwiki"
DBAUTH_AUTH_USER_EXISTS = "SELECT userid FROM user WHERE userid='$userid'"
DBAUTH_AUTH_CHECK = "SELECT IF(passwd=PASSWORD('$password'),1,0) FROM user WHERE userid='$userid'"
DBAUTH_AUTH_CRYPT_METHOD = plain

DBAUTH_AUTH_UPDATE = "UPDATE user SET passwd=PASSWORD('$password') WHERE userid='$userid'"
DBAUTH_AUTH_CREATE = "INSERT INTO user SET passwd=PASSWORD('$password'),userid='$userid'"

DBAUTH_PREF_SELECT = SELECT prefs FROM pref WHERE userid='$userid'

DBAUTH_PREF_UPDATE = "REPLACE INTO pref SET prefs='$pref_blob',userid='$userid'"


EDITING_POLICY = EditingPolicy


THEME = Sidebar

CHARSET = iso-8859-1

DEFAULT_LANGUAGE = en

WIKI_PGSRC = pgsrc

DEFAULT_WIKI_PGSRC = pgsrc
DEFAULT_WIKI_PAGES = "ReleaseNotes:SteveWainstead:TestPage"

ALLOWED_PROTOCOLS = "http|https|mailto|ftp|news|nntp|ssh|gopher"

INLINE_IMAGES = "png|jpg|gif"

WIKI_NAME_REGEXP = "(?<![[:alnum:]])(?:[[:upper:]][[:lower:]]+){2,}(?![[:alnum:]])"

SUBPAGE_SEPARATOR = /

INTERWIKI_MAP_FILE = lib/interwiki.map

WARN_NONPUBLIC_INTERWIKIMAP = false

KEYWORDS = "Category:Topic"

COPYRIGHTPAGE_TITLE = GNU General Public License
COPYRIGHTPAGE_URL = http://www.gnu.org/copyleft/gpl.html#SEC1
AUTHORPAGE_TITLE = The PhpWiki Programming Team
AUTHORPAGE_URL = http://phpwiki.sourceforge.net/phpwiki/ThePhpWikiProgrammingTeam

TOC_FULL_SYNTAX = true
--- end

Re: [Phpwiki-talk] Wiki spam and the future of phpwiki

[Philip J. H. <ph...@po...>]

On Wed, 30 Mar 2005 08:56:02 -0600, "Dan Frankowski"
<dfr...@cs...> said:
> Finally, I believe this goal would be aided if there were much less
> code to maintain. For example, support only one backend. I see so much
> work going into different database ports, needlessly. I vote for
> MySQL, since that is what I am using. However, I might even go with a
> CVS backend (*shudder*) if that were the community's will, as long as
> it supported query-able relationships between 2 things (exactly like
> backlinks, or we've expanded also to ratings, categories, and in the
> future perhaps list items), and multiple instances from the same code
> base (currently with multiple MySQL DBs).

I heartily second that.  I suspect deciding one one backend might be
politcally extremely difficult.  It sure seems like something that needs
to be done.  One thing I really like about PmWiki is it avoids the whole
database question entirely by just storing pages as textfiles.  Have you
ever tried to configure mysql on a hosted system?  It can be extremely
annoying (or extremely easy, depending on the provider).

But there's no doubt that lots of the bug fixes have been for the
various database engines.  Perhaps the real core of the problem with
phpwiki is _too much_ choice.  All these choices result in a
combinatorial explosion of bugs.  For example, I use the Crao theme on
my website.  It turns out that there are a number of phpwiki
functionality bugs (like you can't delete pages) that happen only with
that theme.  Ugh.

> >I realize that the spam problem is not unique to phpwiki.  However,
> >I'm not seeing anything being done to address it.  For example, ip
> >address blocking is not implemented in the phpwiki version I am
> >running. Obviously that's not a particularly effective way to deal
> >with spam, but it is a start.  What about blacklists such as the ones
> >from chongqed.org or Movable Type?  Captchas?  Typekey?  I'm guessing
> >that if I'm having these problems, lots of other people are too.
> >What is being done in phpwiki to deal with the spam problem?
>
> To be fair, Reini put in two things, and I believe they are in RC1
> (aiming at 1.3.11 if all goes well):
>
> 1. Don't allow saving a page that has more than 20 external ("
>    http://") links. In our code, I modified "20" to be a configurable
>    parameter SPAM_MAX_EXTERNAL_LINKS. We've been completely spammed as
>    well, and I believe this will help us a lot. We have a wiki where
>    each legitimate page only contains a few external links, but spam
>    pages contain tons (>50 for sure) external links.

Obviously the spammers will adapt to that by creating lots of pages,
each with only a couple of links.  Then we will need a mechanism to
rate-limit the creation of pages, etc.  The never-ending spam battle.

Actually, I'd like to see rate-limiting for page creation now.  Maybe no
more than one page every 30 seconds, by default?

> 2. Hook up with babyspam, which is a hookup to Spam Assassin. In other
>    words, an evolving tool for detecting spam.
>
> Might not be a bad idea to also have IP filtering, but this can also
> be done at the .htaccess file in your dir .. IF your Apache allows
> overrides.

Those sound like very positive steps.  At the same time, they highlight
the brokenness of the phpwiki development model.  I had no idea these
features were being integrated.  If we had some more regular releases,
then these things would show up in the release notes (hopefully) instead
of being buried in cvs commit messages, etc.

Right now I kind of feel like each upgrade to phpwiki is like Christmas.
 Lots of exciting presents, but you never have any idea what you are
getting.

Thanks,
P.
--  
Philip J. Hollenback
ph...@po...
www.hollenback.net

Re: [Phpwiki-talk] Release Candidate 1

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

Reini,

I think having a release candidate is a very positive step forward!

However, I am confused. "Known problems?" It can't be a release 
candidate unless you intend to release with all those problems (which 
maybe you do?). It is not bad to release with some bugs if they are not 
critical; all major software has bugs. However, the way it sounded below 
was that there was going to be more work before actual release. Then 
it's not an RC.

Dan

Reini Urban wrote:

> I've made available a release candidate 1, which should fix most of the
> problems.
>
> Known problems to be done:
>
> * wikiadmin plugin problems with subpages (rename, ...)
> *   in diff #1169504
> * accept email with + #1166336
> * cannot embed plugins in RichTable plugin
>
> Fixed in last week:
> * locale
> * configurator
> * pop3 auth
> * adodb authinfo security flaw
>
> Hope I'll come to the remaining issues tomorrow, but our wave is that 
> high this weekend, so I'll rather go surfing and fix the rest during 
> the next week.
> Sorry for the one month delay because of my new job, local permission 
> problems and the austrian filmfestival.

Re: [Phpwiki-talk] Wiki spam and the future of phpwiki

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

Philip J. Hollenback wrote:

>I've been running phpwiki for several years on my site
>http://www.hollenback.net.  I started with the 1.2 phpwiki and have
>upgraded several times.  Currently I'm running a cvs version from some
>time after the 1.3.10 release.
>
>I've always been a big supporter of phpwiki and have always appreciated
>the work everyone has put in to it.  But now, I'm at a crossroads: I'm
>pretty seriously considering migrating my whole site (600+ pages) to
>PmWiki.  Here's why:
>
>1. The phpwiki development model is broken.  Particularly over the last
>year, I have seen a tremendous amount of new, potentially cool features
>added to phpwiki.  However, many of these features are broken in various
>ways, and some just don't work at all.  Based on my use of phpwiki, the
>buginess of the code base has increased significantly.  To phpwiki's
>credit, I've never really seen a data corruption bug.  Instead, most of
>the problems I see are things like plugins that don't work with certain
>themes, random odd error messages on pages, etc.
>
>I think new features are fantastic.  However, the lack of a stable
>phpwiki release is really, really hurting phpwiki.  I know that a 1.3.11
>release is very close and that is a good step in the right direction. 
>However, the problem of all these new, not very well tested features
>will remain.
>  
>

I agree with all of this.

Stability, fully functional, easy to use, well-documented features are 
very important, more important than most new features. It is a lot of 
work to take a feature from "a good first shot" to easy to use and 
obviously great.

Releasing more often is probably also important.

Finally, I believe this goal would be aided if there were much less code 
to maintain. For example, support only one backend. I see so much work 
going into different database ports, needlessly. I vote for MySQL, since 
that is what I am using. However, I might even go with a CVS backend 
(*shudder*) if that were the community's will, as long as it supported 
query-able relationships between 2 things (exactly like backlinks, or 
we've expanded also to ratings, categories, and in the future perhaps 
list items), and multiple instances from the same code base (currently 
with multiple MySQL DBs).

>2. Wiki spam is a major problem.  I finally had to turn off editing of
>my site last week.  The reason: large amounts of wiki spam.  For the
>last year, I've been getting perhaps one or two spam attacks a week on
>my site.  I managed that by removing or reverting pages manually, not a
>big deal.
>
>However, last week someone created 500 spam pages on my site.  I was
>able to remove them via the admin interface, but it was a very slow
>process.  Clearly manually removing pages is not an effective answer for
>that level of wiki spam.
>
>I realize that the spam problem is not unique to phpwiki.  However, I'm
>not seeing anything being done to address it.  For example, ip address
>blocking is not implemented in the phpwiki version I am running. 
>Obviously that's not a particularly effective way to deal with spam, but
>it is a start.  What about blacklists such as the ones from chongqed.org
>or Movable Type?  Captchas?  Typekey?  I'm guessing that if I'm having
>these problems, lots of other people are too.  What is being done in
>phpwiki to deal with the spam problem?
>  
>

To be fair, Reini put in two things, and I believe they are in RC1 
(aiming at 1.3.11 if all goes well):

1. Don't allow saving a page that has more than 20 external ("http://") 
links. In our code, I modified "20" to be a configurable parameter 
SPAM_MAX_EXTERNAL_LINKS. We've been completely spammed as well, and I 
believe this will help us a lot. We have a wiki where each legitimate 
page only contains a few external links, but spam pages contain tons 
(>50 for sure) external links.

2. Hook up with babyspam, which is a hookup to Spam Assassin. In other 
words, an evolving tool for detecting spam.

Might not be a bad idea to also have IP filtering, but this can also be 
done at the .htaccess file in your dir .. IF your Apache allows overrides.

>I'm not writing this to bash on phpwiki.
>

I think you do a service to state the things you really need.

Dan

[Phpwiki-talk] Wiki spam and the future of phpwiki

[Philip J. H. <ph...@po...>]

I've been running phpwiki for several years on my site
http://www.hollenback.net.  I started with the 1.2 phpwiki and have
upgraded several times.  Currently I'm running a cvs version from some
time after the 1.3.10 release.

I've always been a big supporter of phpwiki and have always appreciated
the work everyone has put in to it.  But now, I'm at a crossroads: I'm
pretty seriously considering migrating my whole site (600+ pages) to
PmWiki.  Here's why:

1. The phpwiki development model is broken.  Particularly over the last
year, I have seen a tremendous amount of new, potentially cool features
added to phpwiki.  However, many of these features are broken in various
ways, and some just don't work at all.  Based on my use of phpwiki, the
buginess of the code base has increased significantly.  To phpwiki's
credit, I've never really seen a data corruption bug.  Instead, most of
the problems I see are things like plugins that don't work with certain
themes, random odd error messages on pages, etc.

I think new features are fantastic.  However, the lack of a stable
phpwiki release is really, really hurting phpwiki.  I know that a 1.3.11
release is very close and that is a good step in the right direction. 
However, the problem of all these new, not very well tested features
will remain.

2. Wiki spam is a major problem.  I finally had to turn off editing of
my site last week.  The reason: large amounts of wiki spam.  For the
last year, I've been getting perhaps one or two spam attacks a week on
my site.  I managed that by removing or reverting pages manually, not a
big deal.

However, last week someone created 500 spam pages on my site.  I was
able to remove them via the admin interface, but it was a very slow
process.  Clearly manually removing pages is not an effective answer for
that level of wiki spam.

I realize that the spam problem is not unique to phpwiki.  However, I'm
not seeing anything being done to address it.  For example, ip address
blocking is not implemented in the phpwiki version I am running. 
Obviously that's not a particularly effective way to deal with spam, but
it is a start.  What about blacklists such as the ones from chongqed.org
or Movable Type?  Captchas?  Typekey?  I'm guessing that if I'm having
these problems, lots of other people are too.  What is being done in
phpwiki to deal with the spam problem?

These issues bring me to the point of considering changing over from
phpwiki to pmwiki.  I'm not saying that pmwiki is necessarily better
than phpwiki, but I think it is more on-track than phpwiki.  I've set up
several wikis based on pmwiki and I've found it to be reliable and
relatively bug-free.  However, it definitely does not support the range
of features that phpwiki does.

I'm not writing this to bash on phpwiki.  It's a great tool, and I
really appreciate the work people have done on it.  All I'm trying to
say here is that the problems with phpwiki are making me consider moving
to a different wiki.  This change will not be easy, as I will have to
write up a parser to convert all my existing pages and deal with lots of
little details.  At this point, I don't see a lot of other options.

Thanks,
P.



--  
Philip J. Hollenback
ph...@po...
www.hollenback.net

[Phpwiki-talk] Error: ... has no '_supplanted' timestamp ...

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

Hello,

on several pages in my wiki i get the following error after saving the page:

lib/ArchiveCleaner.php:109: Notice: Warning: Page 'SandKasten', version 
'16' has no '_supplanted' timestamp (...repeated 3 times)

mostly it tells me version 1 has this problem. i have deleteted the page 
'SandKasten' and inserted again and now it tells version 16 has this 
problem.
The pages are saved ok and the error is hidden until the page would be 
edited again.

How can i solv this?

Regards and thank you
Stefan

Re: AW: [Phpwiki-talk] phpWiki and postnuke at Daimonin

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

> Hm, i thought the postnuke phpwiki port is known?
>
> http://stuff.kling.nu/
>
> I use that module/port. I have not done any code or port for it -
> i just use it and fixed 1-2 minor issues.
>
> It seems i missed to explain the (beside security) only
> and really only important point: That i can use *one*
> permission system - the group/permission system of postnuke
> to control the wiki.
>
> Its the most important point. I would *never* install a 2nd
> permission system using module. I want and i must use the
> central permission system of postnuke to control the wiki
> user & pages. This phpwiki postnuke port allow just that.

Just to clarify:
The 2nd permission system you are talking about (phpwiki's new WikiUserNew
methods)
just allows that, either passing the wiki username/password pair to
an optional backend, like postnuke, and play nicely with the accept/deny
return value from this backend. ("ExternalAuth").
Or just passing the postnuke auth to the wiki.
You dont need seperate wiki auth and perms, since postnuke
already handles auth, perms and prefs.

Finer tuning of prefs and perms (phpwiki prefs or acl's) or using
the underlying postnuke perms is a matter of taste and tools.
We support all of that.

> In fact i would even change the cms or write a own small doc
> system when i had no choice instead of use the standalone permission of
> phpwiki.
...
> Sorry when it sounds like a rant, but its really the important point.
>
> So, as i understand the phpwiki code, the permission system itself is
> not that different as the one from postnuke. It should be possible to
> relink the permission queries to postnuke and use their loged in/logout
> system. The postnuke port does exactly that.
>
> And what i can tell is, that if that is done, both system together works
> wonderful.
>
>> -----Ursprüngliche Nachricht-----
>> Von: php...@li...
>> [mailto:php...@li...] Im Auftrag
>> von Joel Uckelman
>> Gesendet: Mittwoch, 30. März 2005 04:59
>> An: php...@li...
>> Betreff: Re: [Phpwiki-talk] phpWiki and postnuke at Daimonin
>>
>> Thus spake "Michael Toennies":
>> > Hello
>> >
>> > We are the daimonin mmorpg project:
>> > http://www.daimonin.net
>> >
>> > We use phpWiki as our main documentation & information
>> central of our
>> > postnuke site. I have to say that we are very happy with
>> that solution
>> > and its a great success.
>> > Thank you guys!
>> >
>> > The only negative point is, that we can't use the original
>> phpWiki but
>> > a modified version which used the postnuke user permission
>> interface.
>> >
>> > When you look at the site and you understand what we do you
>> will see
>> > how incredible useful the permission system is. We give access to
>> several parts of the website include site sub-admins, gallery album
>> owners, file system upload permission, forum permission, forum
>> moderator permission and at last write access to the wiki.
>> >
>> > Thats only (and really only, our old website had it not, so we know
>> where we talk about) possible with one central permission and group
>> system which gave us the Postnuke CMS.
>> >
>> > As a game (with much underage users), we need a stable & secure
>> permission system. A free wiki access is no option. In the
>> old website
>> > we had deleting and vandalism of pages every few hours.
>> >
>> > With the new webpage, we had not a single issue.
>> >
>> > When you look at the phpWiki of our site, you will notice
>> how good it
>> > fits in the CMS and how useful it is.
>> >
>> > What i fear is, that someone find a exploit in the hacked phpWiki.
>> Its not active in development anymore and it has still issues.
>> >
>> > Has the phpWiki community ever thought about to add a
>> native postnuke
>> > interface? Postnuke lakes a native wiki. It has a very easy to use
>> interface which allows it to bind in modules. Also, the
>> changes would
>> > be normally not so hard - just a redirect to the postnuke
>> permission
>> > system. Nearly all other parts from phpWiki fits in fine.
>> >
>> > It would be a win/win solution for both projects. Postnuke
>> would get a
>> > stable, tested & working wiki. phpWiki would get a
>> incredible boost in
>> > users and, i can ensure it as a open source project leader
>> for years
>> > now, alot more developer.
>> >
>> > Both project would gain ALOT for a little work.
>> >
>> > They would stay independed as projects but would gain through the
>> Synergy effect of the interface both a big boost.
>> >
>> > Michael Toennies
>> > Daimonin MMORPG
>>
>> So, what you're doing is querying postnuke for user
>> permissions? Is that the extend of your modifications?
>>
>> I haven't looked at our permissions system in a while---maybe
>> it already is this way---but it would make some sense to have
>> permissions queries work similarly to the way DB queries do.
>> That is, have an abstract permissions interface which calls
>> the appropriate permissions backend. That way, you guys could
>> write a postnuke permissions backend and there would be no
>> need for further changes to the code.
-- 
Reini Urban
http://phpwiki.org/   http://xarch.tu-graz.ac.at/home/rurban/