phpwiki-talk

Re: [Phpwiki-talk] 1.3.10 and Apache 2, small projects, wiki spam

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

Charles Corrigan wrote:
> I had a play with apache2.0, php4.3.11 and mysql4.0.23 on windows. What I
> found was that attempting to create a virgin wiki reliably crashed the
> apache process with no info in the logs.

I run phpwiki 1.3.10 tweaked (embedded in another soft) with
* httpd-2.0.48 (apache)
* php-4.3.2
* mysql-4.3.2
on RHAS 3.0

And I never crash anything (~ months of use, ~15 users).

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

RE: [Phpwiki-talk] 1.3.10 and Apache 2, small projects, wiki spam

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

I had a play with apache2.0, php4.3.11 and mysql4.0.23 on windows. What I
found was that attempting to create a virgin wiki reliably crashed the
apache process with no info in the logs.

I "downgraded" to apache1.3 and created the wiki. Since then my dev/test
wiki has worked with both apache1.3 and apache2.0 (most of the time I use
2.0). I have not made the time to trace and find out exactly why apache2.0
crashes

Regards,
Charles

-----Original Message-----
From: Joel Uckelman [mailto:uck...@no...] 
Sent: 12 January 2005 10:55
To: php...@li...
Subject: [Phpwiki-talk] 1.3.10 and Apache 2, small projects, wiki spam

1. Is there something special I need to to do get 1.3.10 working with Apache
2
and PHP 4.3? I haven't been able to get the wiki to create a new page
db, even.

[Phpwiki-talk] RFC: HOW TO alternate security setups in PhpWiki

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

Here is a draft security HOW-TO.  Please comment. There are some
outstanding questions (particularly about whether it is necessary to lock
group pages) and there is a bug in SetAcl (regarding removing groups from
an Acl) that I want to look into before completing this document.

Eventually, with cleanup, it could become a WikiPage in it's own right.

regards,
Charles

I hate WikiSpam!

Being technically minded and based in the Asia timezone while my
co-authors are mainly in Europe and some in the US, it became my
unofficial role to clean up the WikiSpam each day in a 1.2 based PhpWiki.
The WikiSpam that I see is mostly created during the evening in the US
timezone - which is the morning for me.

I started working on PhpWiki 1.3/1.4 with a view to upgrade our wiki
implementing security to:
* let anyone view our work,
* let anyone register themselves as users,
* but require new users to be authorised before editing or creating pages.

While testing and fixing bugs, I discovered some interesting and useful
things about security in PhpWiki that I hope will help others. This is the
recipie that I used. There are many variations that will work just as well
or even better for you.

1 - Generic secuity setup. For the configuration that I describe above,
the following parameters should be set in config/config.ini (and are
further documented there).

; require the new login code - the default
;ENABLE_USER_NEW = true

; allow ACL based permissions on pages - the default
;ENABLE_PAGEPERM = true

; allow unknown/anonymous users to by default read the content
ALLOW_ANON_USER = true

; prevent unknown/anonymous users from editing/creating pages
ALLOW_ANON_EDIT = false

; prevent users just creating a temporary user
; (I am skating over the complexities of this setting)
ALLOW_BOGO_LOGIN = false

; to require users to have passwords
; (this is not independent of the other settings above)
ALLOW_USER_PASSWORDS = true

; require passwords to have a minimum length
; I am not trying to protect national security,
; just encourage the vandals to go elsewhere
PASSWORD_LENGTH_MINIMUM = 6

; use a database to check user-ids and passwords.
; Note that there many other settings database settings that
; need careful attention but that is out of scope for this HOW-TO
USER_AUTH_ORDER = "Db"
USER_AUTH_POLICY = first-only

; Store group information in wiki pages
; there's no need to develop a complex front end for a database.
GROUP_METHOD = WIKIPAGE

; the master page listing the groups - I just used the default
; CATEGORY_GROUP_PAGE = CategoryGroup

; The following SQL queries/statements are stored in
; config/config.ini so that they can easily be changed
; if there an existing user database. Several of these have
; alternatives documented in config/config.ini
DBAUTH_AUTH_USER_EXISTS = "SELECT userid FROM user WHERE userid='$userid'"
DBAUTH_AUTH_CHECK = "SELECT IF(passwd=PASSWORD('$password'),1,0) AS ok
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'"

; I am paranoid about undiscovered cross-site scripting
; vulnerabilities so I prevent users injecting HTML directly into
; pages. It may be safe to allow the latter 2 options
ENABLE_RAW_HTML = false
ENABLE_RAW_HTML_LOCKEDONLY = false
ENABLE_RAW_HTML_SAFE = false


2 - User Group management
Create group pages in the wiki. First, in page CategoryGroup, add the name
of the group in the bulleted list.  This may either be a WikiWord or
enclosed in "[" and "]" and ther must be nothing else on the line. For
example, while editing CategoryGroup, add
* [Writers]
* UserManagement
and save (? does CategoryGroup have to be a locked page?). I will use
these two groups as examples.

Then create the group pages by clicking on the links in the CategoryGroup
page and add the list of users as a bulleted list (as above). (? do the
group pages have to be locked?). In the Writers group, list the users that
are allowed to edit and create pages. In the UserManagement group, list
the users that may authorise new users (or remove existing users).

New users may be added as required.


3 - change the default page permissions. This is the not so well
documented piece (as far as I can tell). Create a page named . to hold
these default permissions. Yes, named "." - this cannot be done directly
from normal web interface. (Note that these permissions may be over-ridden
at the individual page level.)

What I did was to
* export a Zip Dump via the PhpWikiAdministration page
* extract one of the files from this zip - initially, it might look like
==== start ==============================================
Subject: AppendText
From: foo@bar (PhpWiki)
To: foo@bar (PhpWiki)
Date: Wed, 5 Jan 2005 17:09:46 +0800
Mime-Version: 1.0 (Produced by PhpWiki 1.3.11pre-20050108)
Content-Type: application/x-phpwiki;
  pagename=AppendText;
  flags="";
  author=The%20PhpWiki%20programming%20team;
  version=1;
  lastmodified=1104916186;
  created=1104916186;
  author_id=The%20PhpWiki%20programming%20team;
  markup=2;
  charset=iso-8859-1
Content-Transfer-Encoding: quoted-printable

<?plugin AppendText ?>

==== end ================================================
* rename and edit this file (I called it dot but this does not matter) and
the contents should look something like
==== start ==============================================
Subject: .
From: foo@bar (PhpWiki)
To: foo@bar (PhpWiki)
Date: Mon, 17 Jan 2005 15:54:59 +0800
Mime-Version: 1.0 (Produced by PhpWiki 1.3.11pre-20050108)
Content-Type: application/x-phpwiki;
  pagename=.;
  flags="";
  author=Admin;
  version=1;
  lastmodified=1105949000;
  created=1105949000;
  author_id=Admin;
  markup=2;
  acl="view:_EVERY; edit:_ADMIN,_OWNER,Writers,-_BOGOUSER,-_AUTHENTICATED;
create:_ADMIN,_OWNER,Writers,-_BOGOUSER,-_AUTHENTICATED; list:_EVERY;
remove:_ADMIN,_OWNER; change:_ADMIN,_OWNER; dump:_EVERY";
  charset=iso-8859-1
Content-Transfer-Encoding: quoted-printable

This page holds the default permissions for all pages

==== end ================================================
The author should be the name of the administrator account.  The important
line is the one starting "  acl=".

This lists the groups/login types allowed to perform various actions on a
page. Names starting with an _ and all in capitals are built
("_ADMIN","_OWNER" etc.). A - in front of the name means that that group
is not allowed perform an action,
so "edit:-_AUTHENTICATED" means that a user that has logged in is not
allowed edit a page (unless they are also a member of another group that
is allowed).

The example line acl above implements the policy that I described near the
start of this message.

* load the file back into the database through the PhpWikiAdministration
page.
* check the permissions are what you need in PhpWikiAdministration/SetAcl
* test the permissions work as expected.
* if you have to alter the acl, I suggest that you bump the values for
version, lastmodified and created before reloading.

* set any additional restrictions on an individual page by page basis. For
example, to have a limited list of users that can manage adding and
removing users from the Writers group, you could
- on pages Writers, UserManagement, CategoryGroup and CategoryCategory
- remove Writers from edit and create permissions
- add UserManagement to edit and create permissions
(Note, there seems to be a problem removing groups in the UI, so use the
dump page, manual edit and reload page mechanism documented above).

Re: [Phpwiki-talk] headers in email sent by a wiki

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

Reini Urban schrieb:
> As soon as the annoying bugs are fixed.
> I still got repeatable crashes (session related?) on certain cfg's.
> Looks like I'm the only one so far, but I have to find it.
> php-4.3.10 behaves strangely with full zend optimizations.

Ok, the php-4.3.10 issue is resolved.
I had to update to ZendOptimizer 2.5.7

Desc:
my 4.3.10 creates numerical arrays as hash [0] => 'entry', ...
so that foreach (array('entry0','entry1','entry2','entry3') as $n) ...
will print "Illegal offset type". Only without zend debugger.
with while (list(,$n) = each($array)) ... it works okay.

Pear not working after update to 4.3.10
   http://bugs.php.net/bug.php?id=31116
foreach returns the wrong value
   http://bugs.php.net/bug.php?id=30914

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

[Phpwiki-talk] Fixes to caching

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

These changes do not completely fix caching but do make an improvement.

1 - Change the owner of page RichTablePlugin to the administrator
2 - Open PhpWikiAdministration/Chown for *. Result: I still see page
RichTablePlugin with owner ReiniUrban.
3 - Open PhpWikiAdministration/Chown for RichTablePlugin only. Result: I see
the correct owner.

Please review and let me know if there are any further related areas that I
can look into to help resolve my issues?

Regards,
Charles

lib/WikiDB/backend/PearDB.php: WikiDB_backend_PearDB ->
_extract_version_data() - line: 354
change 'pagename' to 'pagedata'
	NOTE: I did not check whether this applied to ADODB or any of the
other formats


lib/WikiDB.php: WikiDB_cache -> get_versiondata 
1 - I found that there was weirdness when trying to store an element with
key '0' into the cache structure, so change from ('0', '1') to ('1', '2').
This probably requires more testing on whether it has side effects on
ArchiveCleaner.php (see comments).
2 - Only update the _pagedata_cache from the _versiondata_cache if the
underlying data is actually queried.
Open questions
* Should $cache[$pagename][$version][$nc]['%pagedata'] be unset?
* Should $vdata['%pagedata'] be unset before return to the caller?
* Would this require a change to do an assignment without a reference into
_pagedata_cache[$pagename]?

Anyway, my replacement versions of the functions are below

    function get_versiondata($pagename, $version, $need_content = false) {
        //  FIXME: Seriously ugly hackage
	$readdata = false;   
	if (USECACHE) {   //temporary - for debugging
            assert(is_string($pagename) && $pagename != '');
            // there is a bug here somewhere which results in an assertion
failure at line 105
            // of ArchiveCleaner.php  It goes away if we use the next line.
            //$need_content = true;
            $nc = $need_content ? '2':'1';
            $cache = &$this->_versiondata_cache;
            if (!isset($cache[$pagename][$version][$nc])||
                !(is_array ($cache[$pagename])) || !(is_array
($cache[$pagename][$version]))) {
                $cache[$pagename][$version][$nc] = 
                    $this->_backend->get_versiondata($pagename, $version,
$need_content);
                $readdata = true;
                // If we have retrieved all data, we may as well set the
cache for $need_content = false
                if ($need_content){
                    $cache[$pagename][$version]['1'] =&
$cache[$pagename][$version]['2'];
                }
            }
            $vdata = $cache[$pagename][$version][$nc];
	} else {
            $vdata = $this->_backend->get_versiondata($pagename, $version,
$need_content);
            $readdata = true;
	}
        if ($readdata && $vdata && !empty($vdata['%pagedata'])) {
            $this->_pagedata_cache[$pagename] =& $vdata['%pagedata'];
        }
        return $vdata;
    }

    function set_versiondata($pagename, $version, $data) {
        //unset($this->_versiondata_cache[$pagename][$version]);
        
        $new = $this->_backend->set_versiondata($pagename, $version, $data);
        // Update the cache
        $this->_versiondata_cache[$pagename][$version]['2'] = $data;
        $this->_versiondata_cache[$pagename][$version]['1'] = $data;
        // Is this necessary?
        unset($this->_glv_cache[$pagename]);
    }

    function update_versiondata($pagename, $version, $data) {
        $new = $this->_backend->update_versiondata($pagename, $version,
$data);
        // Update the cache
        $this->_versiondata_cache[$pagename][$version]['2'] = $data;
        // FIXME: hack
        $this->_versiondata_cache[$pagename][$version]['1'] = $data;
        // Is this necessary?
        unset($this->_glv_cache[$pagename]);
    }

    function delete_versiondata($pagename, $version) {
        $new = $this->_backend->delete_versiondata($pagename, $version);
        if (isset($this->_versiondata_cache[$pagename][$version]['2']))
            unset ($this->_versiondata_cache[$pagename][$version]['2']);
        if (isset($this->_versiondata_cache[$pagename][$version]['1']))
            unset ($this->_versiondata_cache[$pagename][$version]['1']);
        if (isset($this->_glv_cache[$pagename]))
            unset ($this->_glv_cache[$pagename]);
    }

Re: [Phpwiki-talk] headers in email sent by a wiki

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

Joel Uckelman schrieb:
> Thus spake Reini Urban:
>>Joel Uckelman schrieb:
>>>Would anyone else besides me find it useful to be able to set certain 
>>>headers (e.g., From, Reply-to) in mail sent by a wiki in that wiki's config
>>>file?
>>>
>>>Say, in the config file you could have:
>>>EMAIL_HEADER_FROM = MyWiki <my...@ex...>
>>>EMAIL_HEADER_REPLY_TO = MyWikiAdmin <wik...@ex...>
>>>EMAIL_HEADER_X_ARBITRARY_JUNK = foo, bar!
>>>
>>>and those would be used in all outgoing mail from the wiki.
>>
>>Sure.
>>And we really need a Mailer class, which should produce
>>all outgoing mails.
>>But I wanted to defer that to the next release.
> 
> How soon were you expecting to do another release? Maybe I could write a 
> basic Mailer class before then?

As soon as the annoying bugs are fixed.
I still got repeatable crashes (session related?) on certain cfg's.
Looks like I'm the only one so far, but I have to find it.
php-4.3.10 behaves strangely with full zend optimizations.

Almost all older problems have been fixed.

I don't care that much for finalizing the new features. I'll just 
disable the not-yet-working ones.
-- 
Reini Urban
http://xarch.tu-graz.ac.at/home/rurban/

Re: [Phpwiki-talk] headers in email sent by a wiki

[Joel U. <uck...@no...>]

Thus spake Reini Urban:
> Joel Uckelman schrieb:
> > Would anyone else besides me find it useful to be able to set certain 
> > headers (e.g., From, Reply-to) in mail sent by a wiki in that wiki's config
>  
> > file?
> > 
> > Say, in the config file you could have:
> > 
> > EMAIL_HEADER_FROM = MyWiki <my...@ex...>
> > EMAIL_HEADER_REPLY_TO = MyWikiAdmin <wik...@ex...>
> > EMAIL_HEADER_X_ARBITRARY_JUNK = foo, bar!
> > 
> > and those would be used in all outgoing mail from the wiki.
> 
> Sure.
> And we really need a Mailer class, which should produce
> all outgoing mails.
> But I wanted to defer that to the next release.

How soon were you expecting to do another release? Maybe I could write a 
basic Mailer class before then?


-- 
J.

Re: [Phpwiki-talk] headers in email sent by a wiki

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

Joel Uckelman schrieb:
> Would anyone else besides me find it useful to be able to set certain 
> headers (e.g., From, Reply-to) in mail sent by a wiki in that wiki's config 
> file?
> 
> Say, in the config file you could have:
> 
> EMAIL_HEADER_FROM = MyWiki <my...@ex...>
> EMAIL_HEADER_REPLY_TO = MyWikiAdmin <wik...@ex...>
> EMAIL_HEADER_X_ARBITRARY_JUNK = foo, bar!
> 
> and those would be used in all outgoing mail from the wiki.

Sure.
And we really need a Mailer class, which should produce
all outgoing mails.
But I wanted to defer that to the next release.
-- 
Reini Urban
http://xarch.tu-graz.ac.at/home/rurban/

[Phpwiki-talk] headers in email sent by a wiki

[Joel U. <uck...@no...>]

Would anyone else besides me find it useful to be able to set certain 
headers (e.g., From, Reply-to) in mail sent by a wiki in that wiki's config 
file?

Say, in the config file you could have:

EMAIL_HEADER_FROM = MyWiki <my...@ex...>
EMAIL_HEADER_REPLY_TO = MyWikiAdmin <wik...@ex...>
EMAIL_HEADER_X_ARBITRARY_JUNK = foo, bar!

and those would be used in all outgoing mail from the wiki.

-- 
J.

Re: [Phpwiki-talk] problems with installing flatfile and mysql

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

wolf schrieb:
> I tried installing wiki on a mysql database but this dont work.
> So now i try to install it in flatfile mode.
> But this dont work too.
>  
> What went wrong.
> i dont know why.
>  
> http://www.htwm.de/~vannacke/wiki/index.php

But PHP tells you exactly what went wrong.

You have to either try a current CVS snapshot, which is call-time 
pass-by-reference safe, or turn this warning off in your php.ini.
As PHP tells you.

"Warning: Call-time pass-by-reference has been deprecated - argument 
passed by value; If you would like to pass it by reference, modify the 
declaration of [runtime function name](). If you would like to enable 
call-time pass-by-reference, you can set allow_call_time_pass_reference 
to true in your INI file. However, future versions may not support this 
any longer. in 
/home/www38/mx3-8/vannacke/public_html/wiki/lib/CachedMarkup.php on line 
466"...

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

[Phpwiki-talk] problems with installing flatfile and mysql

[wolf <wo...@ch...>]

Hi

I tried installing wiki on a mysql database but this dont work.
So now i try to install it in flatfile mode.
But this dont work too.

What went wrong.
i dont know why.

http://www.htwm.de/~vannacke/wiki/index.php

greets=20

Re: [Phpwiki-talk] double underscores munged in URLs

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

Joel Uckelman schrieb:
> Thus spake Reini Urban:
>>Joel Uckelman schrieb:
>>>I think I have a solution for bug 1090579, https://sourceforge.net/tracker/
>>>index.php?func=detail&aid=1090579&group_id=6121&atid=106121. I'd appreciate 
>>>it if someone more familiar with the markup parsing code than I am would 
>>>take a look at my suggested fix and tell me if it seems sane before I 
>>>commit it and close the bug.
>>
>>Your "__" patch to prevent from bold detection. This is indeed hairy code.
>>Shouldn't this also be done for italic?
> 
> The reason I decided not to do this for italics is that single quotes 
> shouldn't be in the URL to begin with, so trying to make a link containing 
> them *should* fail, right?

Right.

>>Better would be to urlencode/decode those magic tags in pagenames/urls:
>>   "__", "''"
> 
> urlencode() won't encode underscores, because they're legal characters in 
> URLs.
> Also, if you do it that way when you have a link with no accompanying text 
> it doesn't render properly. The link is displayed containing '%5F%5F' 
> instead of '__'.

Good.

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

Re: [Phpwiki-talk] Multiple instances - One DB

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

Christian BAYLE schrieb:
> Le vendredi 07 janvier 2005 à 20:30 +0100, Reini Urban a écrit :
>>Manuel VACELET schrieb:
>>>Reini Urban wrote:
>>>
>>>>I'll have a look after 1.3.11 but I still see no technical reason, why 
>>>>this should be better than tablename prefixes. Merging all the 
>>>>seperate table sets into one big mess...
>>>
>>>I agree, it's not technical reasons.
>>>I just "fell" it not very elegant (tables multiplications).
> 
> I see finally some important technical reasons after some discussion: 
> -Upgrading 4000 set of tables can be some kind of tricky.

A simple perl or php script?

> The main question is to have isolated group spaces in the wiki, that is
> not as far as i understand in phpwiki philosophy.
> -Having group of pages associated with a project, where you can make
> some kind of access control possibly at page level: public or private.
> -Each project gathering a group of users.
> 
> How would you implement this, if you had to do it, is the way followed
> by Manuel the best one, according to the fact we don't want database or
> table multiplication

Ok. I see your point now.
auth and perm control, across groups:

access control by group level (public or private) would be easy by 
defining this constant in the starter script, dependent on the group_id. 
(some pgsql query from the gforge cfg).
if (

user auth (userid+passwd) is already easy via external db.

also via session:
// If the user is logged in, let the Wiki know
if (session_loggedin()) {
     // let php do it's session stuff too!
     session_start();
     $_SESSION['user_id'] = user_getname(); // phpwiki will pick it up.
}
or via the undocumented Session auth:
         define('AUTH_SESS_USER', 'user_id');
         define('AUTH_SESS_LEVEL', 2);
         $USER_AUTH_ORDER = "Session : PersonalPage";
         $USER_AUTH_POLICY = "stacked";

db upgrade:
table schema multiplication might be problematic, but could be done by 
some simple helper script. It's technically not the best solution, but 
at least the tables are fully independent. ISP's usually prefer 
independence over technical superiority.
A seperate database per group is technically and in administrative terms 
the worst solution.

Your required wikidb patch for the queries (WHERE group_id=) is  quite 
simple. That would fit best to the gforge philosophy.

>>>Current way of phpwiki integration under gforge is to have only one wiki 
>>>and each project create pages into this big wiki. My way is to provide 
>>>one independent wiki for each project.
>>
>>Well, my way for gforge intergration would use a project-specific 
>>DATABASE_PREFIX, set by the plugin.
>>
>>DB: phpwiki
>>   tables: project1_page, project1_version, project1_recent, ...
>>           project2_page, project2_version, project2_recent, ...
>>needs project_name
>>you can even use different wiki engines per project.
>>
>>Your id scheme is simplier on the database level.
>>DB: phpwiki
>>   tables: page (with group_id), version, recent, ...
>>needs group_id
>>just one engine and one database schema.
>>
>>Pro:  * You only have to do structure updates once,
>>         and use a new primary index: pagename+id
>>       * easier to upgrade to a new phpwiki schema and version.
>>Cons: * Seperation into different wiki's is hard.
>>       * you cannot do project specific phpwiki updates.
>>       * will not by supported by phpwiki OOTB.
>>         So gforge sites must patch the WikiDB backends.
>>
>>I cannot accept your page.group_id patch into phpwiki.
>>It is way to abusive.
>>
>>
>>>Current state seems to work (around 1 month of tests without any 
>>>problems) but I prefer waiting for phpwiki 1.3.11 release before release 
>>>the plugin.
>>
>>The sql schema will not change anymore for sure.
>>Maybe some minor issues with exotic backends have to fixed.
>>
>>Major goals are only the request enhancements in main and Request
>>(GET => POST for ModeratedPage, maybe edit), check remaining request 
>>problems (session, edit + redirect)
>>wikiparser fixes for php5 (or output?),
>>some remaining theme updates
>>configurator for lists
-- 
Reini Urban
http://xarch.tu-graz.ac.at/home/rurban/

Re: [Phpwiki-talk] Multiple instances - One DB

[Christian B. <chr...@fr...>]

Le vendredi 07 janvier 2005 =E0 20:30 +0100, Reini Urban a =E9crit :
> Manuel VACELET schrieb:
> > Reini Urban wrote:
> >=20
> >> I'll have a look after 1.3.11 but I still see no technical reason, why=
=20
> >> this should be better than tablename prefixes. Merging all the=20
> >> seperate table sets into one big mess...
> >=20
> > I agree, it's not technical reasons.
> > I just "fell" it not very elegant (tables multiplications).
> >=20
I see finally some important technical reasons after some discussion:=20
-Upgrading 4000 set of tables can be some kind of tricky.

The main question is to have isolated group spaces in the wiki, that is
not as far as i understand in phpwiki philosophy.
-Having group of pages associated with a project, where you can make
some kind of access control possibly at page level: public or private.
-Each project gathering a group of users.

How would you implement this, if you had to do it, is the way followed
by Manuel the best one, according to the fact we don't want database or
table multiplication

Thanks for your help

Cheers

Christian.=20
> >=20
> > Current way of phpwiki integration under gforge is to have only one wik=
i=20
> > and each project create pages into this big wiki. My way is to provide=20
> > one independent wiki for each project.
>=20
> Well, my way for gforge intergration would use a project-specific=20
> DATABASE_PREFIX, set by the plugin.
>=20
> DB: phpwiki
>    tables: project1_page, project1_version, project1_recent, ...
>            project2_page, project2_version, project2_recent, ...
> needs project_name
> you can even use different wiki engines per project.
>=20
> Your id scheme is simplier on the database level.
> DB: phpwiki
>    tables: page (with group_id), version, recent, ...
> needs group_id
> just one engine and one database schema.
>=20
> Pro:  * You only have to do structure updates once,
>          and use a new primary index: pagename+id
>        * easier to upgrade to a new phpwiki schema and version.
> Cons: * Seperation into different wiki's is hard.
>        * you cannot do project specific phpwiki updates.
>        * will not by supported by phpwiki OOTB.
>          So gforge sites must patch the WikiDB backends.
>=20
> I cannot accept your page.group_id patch into phpwiki.
> It is way to abusive.
>=20
> > Current state seems to work (around 1 month of tests without any=20
> > problems) but I prefer waiting for phpwiki 1.3.11 release before releas=
e=20
> > the plugin.
>=20
> The sql schema will not change anymore for sure.
> Maybe some minor issues with exotic backends have to fixed.
>=20
> Major goals are only the request enhancements in main and Request
> (GET =3D> POST for ModeratedPage, maybe edit), check remaining request=20
> problems (session, edit + redirect)
> wikiparser fixes for php5 (or output?),
> some remaining theme updates
> configurator for lists

Re: [Phpwiki-talk] double underscores munged in URLs

[Joel U. <uck...@no...>]

Thus spake Reini Urban:
> Joel Uckelman schrieb:
> > I think I have a solution for bug 1090579, https://sourceforge.net/tracker/
> i
> > ndex.php?func=detail&aid=1090579&group_id=6121&atid=106121. I'd appreciate 
> > it if someone more familiar with the markup parsing code than I am would 
> > take a look at my suggested fix and tell me if it seems sane before I 
> > commit it and close the bug.
> 
> Your "__" patch to prevent from bold detection. This is indeed hairy code.
> Shouldn't this also be done for italic?

The reason I decided not to do this for italics is that single quotes 
shouldn't be in the URL to begin with, so trying to make a link containing 
them *should* fail, right?

> Better would be to urlencode/decode those magic tags in pagenames/urls:
>    "__", "''"

urlencode() won't encode underscores, because they're legal characters in 
URLs.
Also, if you do it that way when you have a link with no accompanying text 
it doesn't render properly. The link is displayed containing '%5F%5F' 
instead of '__'.

-- 
J.

Re: [Phpwiki-talk] double underscores munged in URLs

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

Joel Uckelman schrieb:
> I think I have a solution for bug 1090579, https://sourceforge.net/tracker/i
> ndex.php?func=detail&aid=1090579&group_id=6121&atid=106121. I'd appreciate 
> it if someone more familiar with the markup parsing code than I am would 
> take a look at my suggested fix and tell me if it seems sane before I 
> commit it and close the bug.

Your "__" patch to prevent from bold detection. This is indeed hairy code.
Shouldn't this also be done for italic?
Better would be to urlencode/decode those magic tags in pagenames/urls:
   "__", "''"

*PageName is this a list or link to "*PageName"
   I would say a list entry.
#PageName is this a list or link to "#PageName"
   I would say a list entry.


Legal pagenames:
   This is unfortunately database backend dependent.

Flatfile and cvs have some filesystem and security related restrictions.
All other should have no restrictions at all.

Currently problems exists with (out of my head)
"0": related to php vbasic-like empty() and ! checks.
      already fixed in some cases, but there still some holes.
"[" and "]" cause problems with the p[] arg in WikiAdmin plugins.
    I think I fixed this but I'm not sure)
"<" ">" : forgot why. parser related probably.  (i.e. [Page<em>Name])
utf-8 special chars are detected and fixed upfront.
   IE sends urls in utf8, fixTitleEncoding()
-- 
Reini Urban
http://xarch.tu-graz.ac.at/home/rurban/

Re: [Phpwiki-talk] 1.3.10 and Apache 2, small projects, wiki spam

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

ms...@sp... schrieb:
>> Yep, that's it!
>> Try to fix the Signature alias in your themeinfo.php, so that it will 
>> be found.

> $Theme->addImageAlias('signature', WIKI_NAME . "Signature.png");
> 
> And there's a signature.png file in the images directory.

WIKI_NAME . "Signature.png" => "PhpWikiSignature.png" if your WIKI_NAME 
is "PhpWiki". You only have "signature.png", but not WIKI_NAME . 
"Signature.png"

Or change the line in themeinfo.php to
$Theme->addImageAlias('signature', "signature.png");
-- 
Reini Urban
http://xarch.tu-graz.ac.at/home/rurban/

[Phpwiki-talk] Re: possible cache corruption in lib/WikiDB.php

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

On Thu, January 13, 2005 20:29, Charles Corrigan said:

> It appears that during the population of the cache with all of the pages
> for the PageList, the cache or the intermediate data that is put into the
> cache is corrupted, somewhere between
>     WikiDB_cache->get_versiondata() - line 2051
> and the return from this into
>     WikiDB_page->getRevision() - line 1123

OK, found something. But I do not understand it.

in lib/WikiDB.php, line 2056, WikiDB_cache->get_versiondata()
==============================
if ($vdata && !empty($vdata['%pagedata'])) {
    $this->_pagedata_cache[$pagename] =& $vdata['%pagedata']; // BUG HERE
}
return $vdata;
==============================
To my understanding, this looks like completely legitimate PHP code. 
However, it _appears_ that the php dictionary goes haywire/gets corrupted
at this line (I am a php newbie so I am hesitant to state that it is a bug
in php unless an expert can back me up).

It is possible that my output is messed up by the the DBG tool but it
appears to be consistent and would explain the problems that I am seeing.
For example, when opening /PhpWikiAdministration/Chown, the cache is
filled with all of the pages in the database.  It goes wrong in exactly
the same place each time.

I have not yet managed to get everyting setup correctly to debug under
xdebug which might give better understanding of the problem. Until I get
that sorted out, I am stuck.

regards,
Charles

[Phpwiki-talk] double underscores munged in URLs

[Joel U. <uck...@no...>]

I think I have a solution for bug 1090579, https://sourceforge.net/tracker/i
ndex.php?func=detail&aid=1090579&group_id=6121&atid=106121. I'd appreciate 
it if someone more familiar with the markup parsing code than I am would 
take a look at my suggested fix and tell me if it seems sane before I 
commit it and close the bug.


-- 
J.

[Phpwiki-talk] upgrading from 1.1.9 (!)

[Joel U. <uck...@no...>]

I just discovered that the wiki I'm trying to upgrade was using 1.1.9,
which is postively ancient. Can anyone suggest the easiest way to
migrate this to the current version? The old wiki was using dbm, but
I seem to recall a format change for the database at some point; I've
already tried dumping the old databases directly into the new wiki, and
that doesn't work. I can't make a dump of the old wiki becuase I can't
get anything beyond the front page to load.

Re: [Phpwiki-talk] 1.3.10 and Apache 2, small projects, wiki spam

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

ms...@sp... schrieb:

> 
> On Jan 13, 2005, at 12:13 PM, Reini Urban wrote:
> 
>> ms...@sp... schrieb:
>>
>>> On Jan 12, 2005, at 6:39 AM, Reini Urban wrote:
>>>
>>>> Joel Uckelman schrieb:
>>>>
>>>>> 1. Is there something special I need to to do get 1.3.10 working 
>>>>> with Apache 2
>>>>> and PHP 4.3? I haven't been able to get the wiki to create a new page
>>>>> db, even.
>>>>
>>>>
>>>> The internal redirect-after-edit is broken.
>>>> Make sure that your theme has a valid signature ImageAlias,
>>>> and not false.
>>>> $WikiTheme->addImageAlias('signature', "Signature.png");
>>>>
>>>> This seems to be a special problem with apache2, but I got nearer in 
>>>> the last week.
>>>>
>>> I'm running apache2, phpwiki 1.3.7, using a provided theme (MacOSX), 
>>> and can't change the contents of a page. What's going on?
>>
>>
>> Exact error description please. I cannot guess into the blue.
>>
>> Most likely the signature is missing. If so, you can edit, but get an 
>> empty page after pressing "Save".
>>
>> Other failures should print something.
> 
> No error message. If there were one, I'd still be debugging ;)
> 
> I haven't changed the the MacOSX theme, so as far as I know it's there. 
> The logo shows up properly, so I assume the signature it there too. 
> (signature.png is in the images folder.) I'm just trying to do something 
> simple, like edit the Sandbox. If I press preview or save, the page 
> refreshes with the original contents.

Yep, that's it!
Try to fix the Signature alias in your themeinfo.php, so that it will be 
found.

> One bit of oddity that I suppose might be related: the theme actually 
> varies between the default one and the MacOSX one, depending on the 
> page. The Home Page is default, as is the Sandbox page, Release Notes, 
> and Doc page, but none of the others that are linked to from the front 
> page. Edit always shows up as MacOSX. In both cases there is a logo.
> 
> I'm running a Debian box, in case that's relevant.

Not relevant. Same on windows. Same on apache1 and apache2.
I thought it might be HTTP 1.0 / 1.1 related. Status code quirks. Lots 
of docs in the src.
But I don't have enough time to verify and debug that now.
I did a debug build of my apache and tried to step through, but didn't 
finish yet.
-- 
Reini Urban
http://xarch.tu-graz.ac.at/home/rurban/

Re: [Phpwiki-talk] PhpWiki Security

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

Dan Frankowski schrieb:
> The machine that runs wikilens.org was hacked through an old unpatched 
> instance of PhpBB2.

I had that and a squirelmail end of last year. formmail and perl cgi's 
are also very often.
Use a kernel without modules.
Which rootkit? Modified t0rn are quite often, which are very easy to 
remove, even without a fresh reinstall.

> This delayed our release of MoonBadger, which by the way Reini, has a 
> few primitive auto-complete textboxes, though not through the cool 
> server-side XML-RPC. We'd love that, although it would require PhpWiki 
> responding quickly. I don't know performance now, but our pages are 
> around 1s, pretty slow for autocomplete, although page render is 
> probably more work than returning a few autocomplete results.

We can do xmlrpc very fast if no auth is needed.
The hyperwiki is quite fast, say: fast enough for me. This does a lot of 
xml-rpc requests, not just one as in autocompletion.
And dba is fastest of course, the first sql connection overhead is gigantic.

> Aside from that, it made me wonder about the security of PhpWiki. If I 
> get hacked again, our systems support will frown at me even more, and we 
> have several PhpWikis running, some externally visible (like wikilens). 
> Are there known exploits in 1.3.7 or 1.3.9? Has somebody thought about 
> security? Is there a writeup somewhere I can read?

So far only one problem occured, which was fixed immediately.
A possible LDAP injection, using * as username.
Sorry, no writeup. There was some discussion 2002 in this mailinglist.

I doubt that we are are cross-side scripting vulnerable,
but some external auth stuff, and the xml-rpc and soap extension might 
be vulnerable. External images maybe also.
Be sure to keep your php up to date. Almost every two months is another 
php vulnerability. Apache stabilized a bit now.
-- 
Reini Urban
http://xarch.tu-graz.ac.at/home/rurban/

Re: [Phpwiki-talk] 1.3.10 and Apache 2, small projects, wiki spam

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

ms...@sp... schrieb:
> On Jan 12, 2005, at 6:39 AM, Reini Urban wrote:
>> Joel Uckelman schrieb:
>>> 1. Is there something special I need to to do get 1.3.10 working with 
>>> Apache 2
>>> and PHP 4.3? I haven't been able to get the wiki to create a new page
>>> db, even.
>>
>> The internal redirect-after-edit is broken.
>> Make sure that your theme has a valid signature ImageAlias,
>> and not false.
>> $WikiTheme->addImageAlias('signature', "Signature.png");
>>
>> This seems to be a special problem with apache2, but I got nearer in 
>> the last week.
>>
> 
> I'm running apache2, phpwiki 1.3.7, using a provided theme (MacOSX), and 
> can't change the contents of a page. What's going on?

Exact error description please. I cannot guess into the blue.

Most likely the signature is missing. If so, you can edit, but get an 
empty page after pressing "Save".

Other failures should print something.
-- 
Reini Urban

[Phpwiki-talk] Re: upgrade problems...

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

John Cole schrieb:
> Reini,
>   I'm having a few problems upgrading to the latest cvs version.  They seem
> to be related to stricter database schemas.
> 
>   My first problem is the new unique index on page.pagename.  It seems that
> I have several pages that differ only in case.
> 
>   The second is the page.id auto-increment flag.  I'm having trouble with a
> duplicate ID (even though it's a primary key) and I can't seem to find the
> duplicate :-)
> 
>   I don't think you can do anything about the second problem, but others may
> run into the first one and you might be able to address that in the upgrade
> action.

I'll look into it. But it might need some days.

>   How stable and complete is the CVS head now-a-days?  Do you have any major
> areas that you know don't work?

http://phpwiki.org/DevelopmentBranch is up-to-date

empty signature => immediate redirect after edit is broken. esp on 
apache2. (just a few installations use this feature)

php5: parser or printer. very hairy!

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

Re: [Phpwiki-talk] RFE - form autocompletion

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

Reini Urban wrote:

> just detected this, using google suggest:
>     http://www.google.com/webhp?complete=1&hl=en
>
> "RFE - Form Autocompletion"
> http://serversideguy.blogspot.com/2004/12/google-suggest-dissected.html
>
> We'd need a new xml-rpc function to return simple queries in
> javascript src: titlesearch, username, plugins, categories, and such.


This would be awesome.

We have started to use auto-complete textboxes in a couple places in the 
as-yet-unreleased MoonBadger version of WikiLens. (The code is done, but 
our machine is hacked and down until next week or later.) One spot is to 
add buddies (auto-complete username); another spot is to add pages to a 
list (auto-complete lists you own, auto-complete any pagename to add to 
a list). These boxes currently work by generating the complete list 
server-side and embedding it in the page for the Javascript to use (!!). 
Obviously, this does not scale as the number of users or pages grows 
very large.

By the way, I looked around for auto-complete textboxes, and found 2 I like:

1. http://codeproject.com/jscript/jsactb.asp
Pros:
  + I know it and like it
  + Friendly author ("Use it however you like!")
Cons:
  + Inappropriate license for a GPL project. (It uses creative commons 
license, which isn't even for software.)
  + Only uses a local list in Javascript, not server-side.
  + Some quirks, like when you click away from it, it doesn't go away.

2. http://momche.net/publish/article.php?page=acdropdown
Pros:
  + Looks fully featured
    - has both local and remote modes
    - drops down with a scrollbox, which acts more the way people would 
expect-- scrollbar, vanishes when you click away
  + Friendly author ("Use it however you like!")
Cons:
  + I've never actually used it
  + No license at present. I'm trying to convince the author to release 
it under a GPL-compatible license (see 
http://www.gnu.org/philosophy/license-list.html#GPLCompatibleLicenses). 
Check it out, email the author to choose a GPL-compatible license, so 
PhpWiki can use it!

Also, I guess there's a 3. I wrote my own that's in MoonBadger. The 
advantage is that I got to skip all the confusing licensing issues. The 
disadvantage is that it is not nearly as fully-featured. I really see it 
as a placeholder until a better GPL solution comes along.

Dan