phpwiki-talk

[Phpwiki-talk] =?GB2312?B?s8/Qxbf+zvGjrMirufrK17zSzcaz9r/J0tTD4rfRz8jX9s341b6joQ==?=

[<xm...@to...>]

尊敬的新老客户：

　　您好，很高兴能为您服务！
   
　　如果您或您的企业想做网站，给我们个机会，绝对让您满意！！！

我司服务项目：网页制作、域名注册、虚拟主机、网站推广、通用网址等；

服务优势：域名注册只收取手续费，虚拟主机租用特惠价；
　　　　　企业及个人均可申请成为我们的代理，获取更大优惠；
          专业网站优惠价制作，精诚打造实力网站，为您节省每一分钱；

特别说明：对于信誉好的企业需要做网站的我司可以不收一分钱先给予做好，
　　　　　满意后再收费。

"高速、稳定、安全、24小时专业服务"是全体恒速达人的服务宗旨，我们郑重承诺：
     1、恒速达主机全部采用最新原装Dell PowerApp互联网应用服务器；
     2、光纤直接接入，主机独享 100M 带宽，同时托管于网通与电信；
     3、恒速达主机全部安装正版Turbolinux或Microsoft操作系统；
     4、采用世界标准的SNMP进行24x7x365 系统监测；
     5、恒速达主机客户一个月内可无条件全额退款；其它按实际余额退款。

虚拟主机我司所推出的套餐组合有以下几种优惠：
  
 1、100M（纯HTML空间）+ 送一国际域名，仅售150元/年
 2、50M空间+50M企业邮局 + 功能全面支持并送一国际域名，仅售248元/年
 3、100MP空间+100M企业邮局 + 功能全面支持并送一国际域名，仅售280元/年 
 4、200MP空间+200M企业邮局 + 功能全面支持并送一国际域名，仅售330元/年

我们承诺24小时为您服务！
  咨询电话:　0592-6026652　/　8667174 / 8345012 / 8919334　/　8375020
      传真:  0592-6026652
  　QQ专线:　40327558 /　13531412　/　33925614
　咨询邮箱:　zz...@to...　
  　
祝: 好运天天有、幸运常伴随!!!
                         
　　　　　　　　　　　　　　　　　　　　　　　　　　　
　　　　　　　　　　　　　　　　　　　　　　　　　　　　恒速达网络

[Phpwiki-talk] how to do mysql user authentication with phpwiki 1.3.6?

[Doncho N. G. <mr...@gl...>]

  Hello, I just installed (this morning, now it's 22:00) phpwiki 1.3.6 and am
trying to figure out how to use mysql authentication.
I used the AllUsers (?pagename=AllUsers) plugin to check if it sees my users.
The 'root' user got visible after creating a page named 'root' and changing
root's preferences. I see no change to wiki 'user' and 'member' tables so I
added some users by hand, created their 'home pages', tryed diferent
'auth_crypt_method's and so on with no luck - users can not login with or
without separate DB User Authentication.

my config:
--- cut ---
$DBParams = array(
   'dbtype' => 'SQL',
   'dsn' => 'mysql://<phpwikiuser>:<phpwikipass>@unix(/var/lib/mysql/mysql.sock)/<phpwikitable>',
   'db_session_table'   => 'session',
   'timeout'   => 20
);
define('USE_DB_SESSION',true);
......
if (!defined('ALLOW_HTTP_AUTH_LOGIN')) define('ALLOW_HTTP_AUTH_LOGIN', false);
if (!defined('ALLOW_USER_LOGIN')) define('ALLOW_USER_LOGIN', true);
if (!defined('ALLOW_BOGO_LOGIN')) define('ALLOW_BOGO_LOGIN', true);
if (!defined('REQUIRE_SIGNIN_BEFORE_EDIT')) define('REQUIRE_SIGNIN_BEFORE_EDIT', true);
@ini_set('session.use_trans_sid', 0);
if (!defined('ALLOW_LDAP_LOGIN')) define('ALLOW_LDAP_LOGIN', false);
if (!defined('ALLOW_IMAP_LOGIN')) define('ALLOW_IMAP_LOGIN', false);
$DBAuthParams = array(
   'auth_dsn' 'mysql://<phpwikiuser>:<phpwikipass>@unix(/var/lib/mysql/mysql.sock)/<phpwikitable>',
   'auth_check'  => 'SELECT password FROM wiki_user WHERE userid="$userid"',
   'auth_crypt_method'  => 'plain',
   'auth_update'  => 'UPDATE wiki_user SET password="$password" WHERE userid="$userid"',
   'pref_select' => 'SELECT preferences from wiki_user WHERE userid="$userid"',
   'pref_update' => 'UPDATE wiki_user SET preferences="$pref_blob" WHERE userid="$userid"',
   'group_members' => 'SELECT userid FROM wiki_group WHERE user_group="$group"',
   'user_groups' => 'SELECT user_group FROM wiki_group WHERE userid="$userid"',
   'dummy' => false
);
--- cut ---
* I don't have <phpwikiuser> as username, I replaced the real values this way.

MySQL tables wiki_user and wiki_grop are:
--- cut ---
CREATE TABLE `wiki_user` (
  `userid` varchar(48) binary NOT NULL default '',
  `preferences` text,
  `password` varchar(48) binary default '*',
  PRIMARY KEY  (`userid`),
  UNIQUE KEY `userid` (`userid`)
) TYPE=MyISAM;
CREATE TABLE `wiki_group` (
  `userid` char(48) NOT NULL default '',
  `user_group` char(48) NOT NULL default 'users',
  PRIMARY KEY  (`userid`),
  KEY `user_group` (`user_group`)
) TYPE=MyISAM;
--- cut ---

  So far no user except the admin user defined in index.php can login. All pages
are stored in my mysql server. The 'auth_dsn' for 'DBAuthParams' is just the
same as 'dsn' for 'DBParams'.
  Can someone tell me how to do MySQL user authentication? Is it supported?
(I would prefer not to have any user 'home pages' at all if possible)

-- 
Regards,
  Doncho N. Gunchev

[Phpwiki-talk] php wiki error ??

[Dan S. <dan...@ea...>]

All,

Php wiki on a provider site is giving fits!! I believe it may be a site 
problem of some kind. After attempting an update I got a file permission 
error. After that the file shows the following error:

Detailed view of a page, which is probably more useful for debugging 
than anything else.

lib/plugin/_BackendInfo.php(In template 'browse'?)(In template 
'body'?)(In template 'html'?):93: Warning[2]: Invalid argument supplied 
for foreach()

lib/plugin/_BackendInfo.php(In template 'browse'?)(In template 
'body'?)(In template 'html'?):140: Warning[2]: Wrong datatype in ksort() 
call

lib/plugin/_BackendInfo.php(In template 'browse'?)(In template 
'body'?)(In template 'html'?):141: Warning[2]: Invalid argument supplied 
for foreach()

How can this be cleaned up??

Dan

[Phpwiki-talk] hosting phpwiki on a 'public' site ??

[Dan S. <dan...@ea...>]

All,

I am trying to host a phpwiki on a public, comercial web site. They 
support php and phpwiki runs. However uploads assume a fixed user group 
and fixed permissions. There also seem to be syncronazation problems.

As part of a phpwiki howto are there captured notes on how to do this?

Is there a list of dependencies? (i.e. directroy limitations, etc.)

Is there a phpwiki 'test' to determine if the site can support phpwiki??

Much of this may be common knowledge, but to a newbe it is a uphill climb.

Dan

[Phpwiki-talk] Hosted wiki gets frequent write permission errors ??

[Dan S. <dan...@ea...>]

All,

I am trying to host a phpwiki on a public site. It is getting frequent 
write permission errors. If I wait or retry it seems to work. There are 
inconsistencies in the file owner - group settings. The wiki was created 
with owner-mysite; group my-site. Phpwiki creates files with owner 
apache; group apache. Could this be the cause of this??

It seems if I wait and retry that the wiki works. Is this a data caching 
issue caused by the site??

Dan

[Phpwiki-talk] How do I "re-initialize" a wiki ??

[Dan S. <dan...@ea...>]

All,

My wiki is hoplessly out of sync. I would like to re-initialize it. How 
can that be done??

Dan

[Phpwiki-talk] Configuration of this list: Reply-To:, acceptance

[Oliver B. <ob...@de...>]

Hello All,

wouldn't it be nice if this list would set the Reply-To: to the list 
address? Many times I forget to correct the address when answering to 
the list, and the reply goes to the poster instead of the list.

And I would also set the list to accept mail only from subscribers 
due to two reasons: spammers send mail to this list *), and I don't 
want to send (successfully) by accident with the mail address of my 
employer.

Oliver

*) the "Remote Control Boats" guy is a very nasty spammer - he used 
also mail addresses from our domain so I get bounces now... Sadly he 
is too far away from Europe to LART him.

Re: [Phpwiki-talk] Restore 'has edit conflicts - skipped' - how to avoid

[Oliver B. <ob...@de...>]

Carsten Klapp <car...@us...> wrote:

 > Admittedly the loadsave functions do need some more work. In the mean 
> time, here's a quick hack I whipped up to do exactly what you need.
> 
> Add this line to PhpWikiAdministration:

[...]

Without touching the sources, one could still add an "overwrite=1" 
query argument (thanks to Jeff Dairiki for this hint!).

Oliver

[Phpwiki-talk] non breaking spaces added at the top of the pages ...

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

Hi all,

On a wiki running PhpWiki 1.3.6, I've a nice little bug :

On some nodes (not all) the diff action adds some nbsp at the very
beginning of the generated html page.

I first thought it was a problem with the theme I write but it's the
same with "default".

More : the number of nbsp is not always the same depending of the page.

Have a look at http://innovation.crao.net/index.php/Accueil?action=diff


Any clue ?

-- 
Arnaud Fontaine
Jabber: sh...@ra...
ICQ: 3504789

Re: [Phpwiki-talk] new phpwiki execution error ??

[Carsten K. <car...@us...>]

On Sunday, December 7, 2003, at 08:33  pm, Dan Sawyer wrote:

> All,
>
> This error is common between the local test system and the uploaded 
> 'web' system; it occus on both systems.
>
> lib/WikiDB.php:787: Fatal[0]: <br 
> />/mnt/extended/downloads/phpbrkclb/lib/WikiDB.php:787: : Assertion 
> failed <br />
>
> Thanks,
> Dan

Hi Dan,
* Which version of PhpWiki, the nightly build or one of the releases?
* What actions before the error occurred?
* Which database is being used, MySQL or another one?
* If one of the SQL databases, are you using PEAR or ADODB as the 
backend? (If you didn't change this in index.php, the default is PEAR).

Email me the info so I check whether there a bug in the code. It could 
also be a record is corrupted in your database. Best to make a zipdump 
backup of all pages right away.

If you can't get a backup pagedump of all pages due to this assertion 
error, try temporarily deleting or commenting out that line 787 in 
lib/WikiDB.php:

     function getRevisionBefore($version) {
         $backend = &$this->_wikidb->_backend;
         $pagename = &$this->_pagename;

         $version = $this->_coerce_to_version($version);

         if ($version == 0)
             return false;
         $backend->lock();
         $previous = $backend->get_previous_version($pagename, $version);
         $revision = $this->getRevision($previous);
         $backend->unlock();
-       assert($revision);
+       //assert($revision);
         return $revision;
     }

Then delete the database and start a new one (or drop all the tables 
and recreate them with the appropriate schema file supplied in Phpwiki, 
same effect).

Let us know what happens.

Carsten

[Phpwiki-talk] new phpwiki execution error ??

[Dan S. <dan...@ea...>]

All,

This error is common between the local test system and the uploaded 
'web' system; it occus on both systems.

lib/WikiDB.php:787: Fatal[0]: <br 
/>/mnt/extended/downloads/phpbrkclb/lib/WikiDB.php:787: : Assertion 
failed <br />

Thanks,
Dan

Re: [Phpwiki-talk] Restore 'has edit conflicts - skipped' - how to avoid

[Carsten K. <car...@us...>]

On Sunday, December 7, 2003, at 05:39  pm, Sergio Trejo wrote:

> Hi Carsten,
>
> Out of curiosity, I'm wondering if I should use this patch for the 
> following situation I find myself in:
>
> I created a Wiki a few months ago and then some colleagues of mine 
> entered some content into the Wiki. However, the group has recently 
> collaboratively agreed to change the name of the Wiki. So my idea is 
> to back up the entire Wiki content of the existing Wiki, and then I 
> will create a new Wiki (with the new name that our group has agreed to 
> use), and then restore the content from the old Wiki to the new one. 
> Does this sound like a good approach, perhaps using your patch, or 
> maybe there's a simpler way to move content around from one named Wiki 
> to another (or a better way to rename a Wiki)?
>
> Thanks for any suggestions!
>
> -Serg
>
> Serj

Yes this patch should work fine for your situation.

(I'm going to work on a better patch eventually.)

Cheers,
Carsten

Re: [Phpwiki-talk] Restore 'has edit conflicts - skipped' - how to avoid

[Sergio T. <ser...@ho...>]

>From: Carsten Klapp <car...@us...>
>To: Micki Kaufman <mic...@co...>
>CC: php...@li...
>Subject: Re: [Phpwiki-talk] Restore 'has edit conflicts - skipped' - how to 
>avoid
>Date: Sun, 7 Dec 2003 12:14:00 -0500
>
>
>On Saturday, December 6, 2003, at 07:34  pm, Micki Kaufman wrote:
>
>>Hi there.
>>
>>Here's a simple, but very very annoying new experience I'm having - I hope 
>>someone can give me the key.
>>
>>I'm splitting one of our sites, and after clicking 'upload' to restore the 
>>new phpwiki with the prior .zipdump (not a snapshot, because I want to 
>>retain the edit history as much as possible), I get the following error in 
>>PhpWikiAdministration for every revision of every page after the first:
>>
>>"PageName
>>from MIME file [name] has edit conflicts - skipped "
>>
>>and for each, I have the option to 'Merge Edit' or 'Restore Anyway'
>>
>>I know I want to 'Restore Anyway', but we have hundreds of pages here, 
>>many with up to ten revisions.
>>
>>How can I return the behavior to the desired pattern, where all the 
>>revisions are loaded in automatically, and I can avoid the hundreds of 
>>mouseclicks?
>>
>>Thanks amazingly much,
>>Micki
>>
>
>Hi Micki,
>
>Admittedly the loadsave functions do need some more work. In the mean time, 
>here's a quick hack I whipped up to do exactly what you need.
>
>Add this line to PhpWikiAdministration:
>
>   <?plugin WikiForm action=upload buttontext="Upload & OVERWRITE" 
>overwrite=1 ?>
>
>Patch lib/plugin/WikiForm.php with the enclosed patch.
>
>It should go without saying, but here it is anyway: BE CAREFUL you don't do 
>something silly like upload the wrong file! :)
>
>Carsten
>
>Index: WikiForm.php
>===================================================================
>RCS file: /cvsroot/phpwiki/phpwiki/lib/plugin/WikiForm.php,v
>retrieving revision 1.9
>diff -U2 -r1.9 WikiForm.php
>--- WikiForm.php	26 Feb 2003 01:56:52 -0000	1.9
>+++ WikiForm.php	7 Dec 2003 17:08:54 -0000
>@@ -43,4 +43,5 @@
>                       'default' => false,
>                       'buttontext' => false,
>+                     'overwrite' => false, // HACK ALERT
>                       'size' => 50);
>      }
>@@ -107,4 +108,8 @@
>
>          $input = HTML::input($input);
>+        if ($overwrite)
>+            $input->pushContent(HTML::input(array('name' => 'overwrite',
>+                                                  'value' =>  1,
>+                                                  'type'  => 'hidden')));
>          $input->addTooltip($buttontext);
>          $button = Button('submit:', $buttontext, $class);
>

Hi Carsten,

Out of curiosity, I'm wondering if I should use this patch for the following 
situation I find myself in:

I created a Wiki a few months ago and then some colleagues of mine entered 
some content into the Wiki. However, the group has recently collaboratively 
agreed to change the name of the Wiki. So my idea is to back up the entire 
Wiki content of the existing Wiki, and then I will create a new Wiki (with 
the new name that our group has agreed to use), and then restore the content 
from the old Wiki to the new one. Does this sound like a good approach, 
perhaps using your patch, or maybe there's a simpler way to move content 
around from one named Wiki to another (or a better way to rename a Wiki)?

Thanks for any suggestions!

-Serg

Serj

_________________________________________________________________
Help STOP SPAM with the new MSN 8 and get 2 months FREE*  
http://join.msn.com/?page=features/junkmail

[Phpwiki-talk] Re: Edit Page Desc in PHPWiki 1.3.6?

[Carsten K. <car...@us...>]

On Saturday, December 6, 2003, at 05:43  pm, Michael Wexler wrote:

> Ok, I understand that the gleandescription function looks at
>
> the first 2 lines of a page, and makes that the description.
>
>  But this shows up in meta tags forever more, even after you
>
> edit the page and delete those lines... and it never gets
>
> updated.  Do you have a suggestion on an easy way to edit
>
> the description field for a page?
>
>
>
> I don't understand how its stored in the DB (its like part
>
> of a nested array stored in a field in mysql), and I don't
>
> understand how to change the "edit" functionality to make
>
> this available to the user.
>
>
>
> Suggestions are appreciated,
>
>
>
> Michael
>
> we...@ya...


Hi Michael,

I'm not really familiar with that part of code myself, so this may be a 
longshot.

Does purging the markup cache of the page bring the description up to 
date? (add &nocache=purge to the page url you are viewing)

If so, try this patch and see if it works. Let me know if this does it, 
I'll check it into CVS.

Carsten

Proposed experimental patch:
Index: CachedMarkup.php
===================================================================
RCS file: /cvsroot/phpwiki/phpwiki/lib/CachedMarkup.php,v
retrieving revision 1.7
diff -U2 -r1.7 CachedMarkup.php
--- CachedMarkup.php	25 Mar 2003 21:04:41 -0000	1.7
+++ CachedMarkup.php	7 Dec 2003 18:39:05 -0000
@@ -126,5 +126,5 @@
  		$this->_buf .= "</$item->_tag>";

-                if (!isset($this->_description) and $item->getTag() == 
'p')
+                if ($item->getTag() == 'p')
                      $this->_glean_description($item->asString());
  	    }

Re: [Phpwiki-talk] installing phpwiki on a remote server is a nightmare !!

[Dan S. <dan...@ea...>]

Thanks for the reply.

I found a package called "ftpcube" which also does a nice job.

I am now facing the problem that phpwiki wants to create new files; it 
assumes 664 or 666 permissions. The remote site default is 644 and the 
result is lots of "fatal error". I have contacted the provider to see if 
they can change the default.

Is there a phpwiki config I have missed??

Thanks,
Dan

Re: [Phpwiki-talk] Restore 'has edit conflicts - skipped' - how to avoid

[Micki K. <mic...@co...>]

Hi Carsten!

Thanks for the patch. It restores the wiki, and restores the 
iterations of the page history for each of the pages.

Thanks again!

(by the way, anyone interested in the output of professional docs 
from phpwiki, check out my contribution at 
http://phpwiki.sourceforge.net/phpwiki/PhpWikiToDocBookAndPDF

Thanks!
Micki

At 12:14 PM -0500 12/7/03, Carsten Klapp wrote:
>On Saturday, December 6, 2003, at 07:34  pm, Micki Kaufman wrote:
>
>>Hi there.
>>
>>Here's a simple, but very very annoying new experience I'm having - 
>>I hope someone can give me the key.
>>
>>I'm splitting one of our sites, and after clicking 'upload' to 
>>restore the new phpwiki with the prior .zipdump (not a snapshot, 
>>because I want to retain the edit history as much as possible), I 
>>get the following error in PhpWikiAdministration for every revision 
>>of every page after the first:
>>
>>"PageName
>>from MIME file [name] has edit conflicts - skipped "
>>
>>and for each, I have the option to 'Merge Edit' or 'Restore Anyway'
>>
>>I know I want to 'Restore Anyway', but we have hundreds of pages 
>>here, many with up to ten revisions.
>>
>>How can I return the behavior to the desired pattern, where all the 
>>revisions are loaded in automatically, and I can avoid the hundreds 
>>of mouseclicks?
>>
>>Thanks amazingly much,
>>Micki
>>
>
>Hi Micki,
>
>Admittedly the loadsave functions do need some more work. In the 
>mean time, here's a quick hack I whipped up to do exactly what you 
>need.
>
>Add this line to PhpWikiAdministration:
>
>   <?plugin WikiForm action=upload buttontext="Upload & OVERWRITE" 
>overwrite=1 ?>
>
>Patch lib/plugin/WikiForm.php with the enclosed patch.
>
>It should go without saying, but here it is anyway: BE CAREFUL you 
>don't do something silly like upload the wrong file! :)
>
>Carsten
>
>Index: WikiForm.php
>===================================================================
>RCS file: /cvsroot/phpwiki/phpwiki/lib/plugin/WikiForm.php,v
>retrieving revision 1.9
>diff -U2 -r1.9 WikiForm.php
>--- WikiForm.php	26 Feb 2003 01:56:52 -0000	1.9
>+++ WikiForm.php	7 Dec 2003 17:08:54 -0000
>@@ -43,4 +43,5 @@
>                       'default' => false,
>                       'buttontext' => false,
>+                     'overwrite' => false, // HACK ALERT
>                       'size' => 50);
>      }
>@@ -107,4 +108,8 @@
>
>          $input = HTML::input($input);
>+        if ($overwrite)
>+            $input->pushContent(HTML::input(array('name' => 'overwrite',
>+                                                  'value' =>  1,
>+                                                  'type'  => 'hidden')));
>          $input->addTooltip($buttontext);
>          $button = Button('submit:', $buttontext, $class);


-- 

Micki
mailto:mic...@co...

Re: [Phpwiki-talk] Restore 'has edit conflicts - skipped' - how to avoid

[Carsten K. <car...@us...>]

On Saturday, December 6, 2003, at 07:34  pm, Micki Kaufman wrote:

> Hi there.
>
> Here's a simple, but very very annoying new experience I'm having - I 
> hope someone can give me the key.
>
> I'm splitting one of our sites, and after clicking 'upload' to restore 
> the new phpwiki with the prior .zipdump (not a snapshot, because I 
> want to retain the edit history as much as possible), I get the 
> following error in PhpWikiAdministration for every revision of every 
> page after the first:
>
> "PageName
> from MIME file [name] has edit conflicts - skipped "
>
> and for each, I have the option to 'Merge Edit' or 'Restore Anyway'
>
> I know I want to 'Restore Anyway', but we have hundreds of pages here, 
> many with up to ten revisions.
>
> How can I return the behavior to the desired pattern, where all the 
> revisions are loaded in automatically, and I can avoid the hundreds of 
> mouseclicks?
>
> Thanks amazingly much,
> Micki
>

Hi Micki,

Admittedly the loadsave functions do need some more work. In the mean 
time, here's a quick hack I whipped up to do exactly what you need.

Add this line to PhpWikiAdministration:

   <?plugin WikiForm action=upload buttontext="Upload & OVERWRITE" 
overwrite=1 ?>

Patch lib/plugin/WikiForm.php with the enclosed patch.

It should go without saying, but here it is anyway: BE CAREFUL you 
don't do something silly like upload the wrong file! :)

Carsten

Index: WikiForm.php
===================================================================
RCS file: /cvsroot/phpwiki/phpwiki/lib/plugin/WikiForm.php,v
retrieving revision 1.9
diff -U2 -r1.9 WikiForm.php
--- WikiForm.php	26 Feb 2003 01:56:52 -0000	1.9
+++ WikiForm.php	7 Dec 2003 17:08:54 -0000
@@ -43,4 +43,5 @@
                       'default' => false,
                       'buttontext' => false,
+                     'overwrite' => false, // HACK ALERT
                       'size' => 50);
      }
@@ -107,4 +108,8 @@

          $input = HTML::input($input);
+        if ($overwrite)
+            $input->pushContent(HTML::input(array('name' => 
'overwrite',
+                                                  'value' =>  1,
+                                                  'type'  => 
'hidden')));
          $input->addTooltip($buttontext);
          $button = Button('submit:', $buttontext, $class);

Re: [Phpwiki-talk] installing phpwiki on a remote server is a nightmare !!

[Carsten K. <car...@us...>]

On Saturday, December 6, 2003, at 10:05  pm, Dan Sawyer wrote:

> All,
>
> After making many out of the gate errors I got phpwiki to run on my 
> local system.
>
> Wow! It is great!!
>
> I then promised a group I would make this great tool available to 
> them. I thought the install would take 15 minutes. The only tool 
> available is ftp. First the directory structure causes many manual 
> copy steps.
>
> That was the easy part. Now the site seems to manually override my 
> permissions and install every thing with 644 instead of 664. There is 
> no global change in ftp.
>
> 1. Is there an iterative smart ftp client that can make this easier?
>
> 2. How do others do this? (it really limits the middle tier user such 
> as myself)
>
> 3. What am I missing??
>
> Dan

Hi Dan,

I use ncftp or the perl script ftpsync (ftpsync.sf.net) to update my 
remote wikis.

Unfortunately with ftp one is restricted by the permissions the server 
gives gives. ncftp allows you to do things like chmod g+w, but many 
servers do not allow it or do not support it. In that case your only 
recourse is to contact the ftp-server administrator to change write 
access permissions of any individual files. :/

ncftp is smart enough to avoid uploading a file with the same 
modification date, this helps a bit. It also allows recursive gets and 
puts, so you can do "put -r phpwiki" etc. When I have many changes to 
upload, I use the ftpsync script. It takes a while to run because it 
traverses the entire directory tree but has worked flawlessly for me so 
far. There are other ftp synchronization scripts if ftpsync isn't your 
taste.

If you can arrange it with the server admin, the easiest I found is to 
use scp (secure copy). A shell with ssh is handy to login for those 
quick fixes or tweaks with a text editor on the server pico/nano/emacs 
etc. If the admin won't go for scp and/or ssh then you're simply stuck 
with ftp.

Carsten

[Phpwiki-talk] installing phpwiki on a remote server is a nightmare !!

[Dan S. <dan...@ea...>]

All,

After making many out of the gate errors I got phpwiki to run on my 
local system.

Wow! It is great!!

I then promised a group I would make this great tool available to them. 
I thought the install would take 15 minutes. The only tool available is 
ftp. First the directory structure causes many manual copy steps.

That was the easy part. Now the site seems to manually override my 
permissions and install every thing with 644 instead of 664. There is no 
global change in ftp.

1. Is there an iterative smart ftp client that can make this easier?

2. How do others do this? (it really limits the middle tier user such as 
myself)

3. What am I missing??

Dan

[Phpwiki-talk] Restore 'has edit conflicts - skipped' - how to avoid

[Micki K. <mic...@co...>]

I should add I'm on the distribution release, 1.3.6.

Thanks!
Micki

>How can I return the behavior to the desired pattern, where all the 
>revisions are loaded in automatically, and I can avoid the hundreds 
>of mouseclicks?


-- 

Micki
mailto:mic...@co...

[Phpwiki-talk] Re: Phpwiki-talk digest, Vol 1 #831 - 9 msgs

[Micki K. <mic...@co...>]

Sorry for the massive forward in my last post.

Micki

At 4:36 PM -0800 12/6/03, php...@li... wrote:
>Send Phpwiki-talk mailing list submissions to
>...
>End of Phpwiki-talk Digest


-- 

Micki
mailto:mic...@co...

[Phpwiki-talk] Restore 'has edit conflicts - skipped' - how to avoid

[Micki K. <mic...@co...>]

Hi there.

Here's a simple, but very very annoying new experience I'm having - I 
hope someone can give me the key.

I'm splitting one of our sites, and after clicking 'upload' to 
restore the new phpwiki with the prior .zipdump (not a snapshot, 
because I want to retain the edit history as much as possible), I get 
the following error in PhpWikiAdministration for every revision of 
every page after the first:

"PageName
from MIME file [name] has edit conflicts - skipped "

and for each, I have the option to 'Merge Edit' or 'Restore Anyway'

I know I want to 'Restore Anyway', but we have hundreds of pages 
here, many with up to ten revisions.

How can I return the behavior to the desired pattern, where all the 
revisions are loaded in automatically, and I can avoid the hundreds 
of mouseclicks?

Thanks amazingly much,
Micki

At 8:04 PM -0800 12/5/03, php...@li... wrote:
>Send Phpwiki-talk mailing list submissions to
>	php...@li...
>
>To subscribe or unsubscribe via the World Wide Web, visit
>	https://lists.sourceforge.net/lists/listinfo/phpwiki-talk
>or, via email, send a message with subject or body 'help' to
>	php...@li...
>
>You can reach the person managing the list at
>	php...@li...
>
>When replying, please edit your Subject line so it is more specific
>than "Re: Contents of Phpwiki-talk digest..."
>
>
>Today's Topics:
>
>    1. Re: Adding '<caption>' tags to tables from wiki (Reini Urban) 
>(Micki Kaufman)
>    2. phpwiki loads but page content is 'garbage' (Dan Sawyer)
>    3. how to upload phpwiki to a server?? (Dan Sawyer)
>    4. Re: Adding '<caption>' tags to tables from wiki (Reini Urban) 
>(Micki Kaufman)
>    5. Re: Adding '<caption>' tags to tables from wiki (Reini Urban) 
>(Micki Kaufman)
>    6. Re: Adding '<caption>' tags to tables from wiki (Carsten Klapp)
>    7. Re: Re: Adding '<caption>' tags to tables from wiki
>        (Reini Urban) (Reini Urban)
>    8. Re: Re: Adding '<caption>' tags to tables from wiki
>        (Reini Urban) (Reini Urban)
>    9. Re: Re: Adding '<caption>' tags to tables from wiki (Reini 
>Urban) (Carsten Klapp)
>   10. Re: 1.4 before Christmas (Joby Walker)
>
>--__--__--
>
>Message: 1
>Date: Fri, 5 Dec 2003 10:16:06 -0500
>To: php...@li...
>From: Micki Kaufman <mic...@co...>
>Subject: [Phpwiki-talk] Re: Adding '<caption>' tags to tables from 
>wiki (Reini Urban)
>
>Reini and Carsten:
>
>Thanks for your great, quick work on this mini-feature. Our disabled
>and DocBook users alike will be very well served. This weekend I'll
>be upgrading the wikis, and can provide my and the users' feedback.
>
>Stylesheet tweak needed?
>
>On our 1.3.4 wiki, the <caption> contents are rendered as 'yellow
>text' by the default stylesheet. We may wanna make a quick mod to the
>stylesheet so that the captions are in black. The font (medium size,
>non-bold) seems fine as is.
>
>Anyway, rocking work, and many many thanks,
>Micki
>
>>Message: 4
>>Date: Thu, 04 Dec 2003 15:25:20 +0100
>>From: Reini Urban <ru...@x-...>
>>To: php...@li...
>>Subject: Re: [Phpwiki-talk] Adding '<caption>' tags to tables from wiki
>>The attached diff is better.
>>It supports summary also, has no linebreaks and
>>it also includes the new pgsrc of the description page.
>
>
>--
>
>Micki
>mailto:mic...@co...
>
>
>--__--__--
>
>Message: 2
>Date: Fri, 05 Dec 2003 08:05:50 -0800
>From: Dan Sawyer <dan...@ea...>
>To:  php...@li...
>Subject: [Phpwiki-talk] phpwiki loads but page content is 'garbage'
>
>All,
>
>phpwiki 1.3.6 installs and initializes. The pages appear to be being
>built in the 'virgin wiki' page. However all attempts to access those
>pages result in 'gargage' pages. If the initial page is reloaded with
>the back page then the readable content is loaded. If that page is
>reloaded then garbage appears.
>
>The system is Fedora Core 1, the browser is Mozilla 1.4.1. This is
>almost like a 'decode key' issue??
>
>Below is a sample of the page output:
>
>-
>
>
>
>--__--__--
>
>Message: 3
>Date: Fri, 05 Dec 2003 09:18:23 -0800
>From: Dan Sawyer <dan...@ea...>
>To:  php...@li...
>Subject: [Phpwiki-talk] how to upload phpwiki to a server??
>
>All,
>
>I have phpwiki working within the local network. I would like to upload
>that instance to a server. What is the file list and dir list from the
>php dir that needs to be uploaded? (I will edit index.php to create a
>flat file new wiki on that site.)
>
>Dan
>
>
>
>
>
>--__--__--
>
>Message: 4
>Date: Fri, 5 Dec 2003 15:07:43 -0500
>To: php...@li...
>From: Micki Kaufman <mic...@co...>
>Subject: [Phpwiki-talk] Re: Adding '<caption>' tags to tables from 
>wiki (Reini Urban)
>
>Hi Reini:
>
>I noticed the resulting table has the attribute 'caption', like this:
>
><table caption="This is a caption" cellpadding="1" cellspacing="1" border="1">
>
>but it really should be a separate open and close tag, before the
>first 'tr' tag, like:
>
><table cellpadding="1" cellspacing="1" border="1">
><caption>This is a caption</caption>
><tr>
>
>John: do you agree?
>
>Reini - an we get a tweak to achieve this? Thanks!
>Micki
>
>>Message: 4
>>Date: Thu, 04 Dec 2003 15:25:20 +0100
>>From: Reini Urban <ru...@x-...>
>>To: php...@li...
>>Subject: Re: [Phpwiki-talk] Adding '<caption>' tags to tables from wiki
>>The attached diff is better.
>>It supports summary also, has no linebreaks and
>>it also includes the new pgsrc of the description page.
>
>
>--
>
>Micki
>mailto:mic...@co...
>
>
>--__--__--
>
>Message: 5
>Date: Fri, 5 Dec 2003 15:12:41 -0500
>To: php...@li...
>From: Micki Kaufman <mic...@co...>
>Subject: [Phpwiki-talk] Re: Adding '<caption>' tags to tables from 
>wiki (Reini Urban)
>
>I forgot to mention - the ability to set border, cellpadding and
>cellspacing is a great mod - many thanks independently for this!
>
>Thanks,
>Micki
>
>>Hi Reini:
>>
>>I noticed the resulting table has the attribute 'caption', like this:
>>
>><table caption="This is a caption" cellpadding="1" cellspacing="1" 
>>border="1">
>>
>>but it really should be a separate open and close tag, before the
>>first 'tr' tag, like:
>>
>><table cellpadding="1" cellspacing="1" border="1">
>><caption>This is a caption</caption>
>><tr>
>>
>>John: do you agree?
>>
>>Reini - an we get a tweak to achieve this? Thanks!
>>Micki
>>
>>>Message: 4
>>>Date: Thu, 04 Dec 2003 15:25:20 +0100
>>>From: Reini Urban <ru...@x-...>
>>>To: php...@li...
>>>Subject: Re: [Phpwiki-talk] Adding '<caption>' tags to tables from wiki
>>>The attached diff is better.
>>>It supports summary also, has no linebreaks and
>>>it also includes the new pgsrc of the description page.
>>
>
>--
>
>Micki
>mailto:mic...@co...
>
>
>--__--__--
>
>Message: 6
>Date: Fri, 5 Dec 2003 15:41:35 -0500
>Subject: Re: [Phpwiki-talk] Adding '<caption>' tags to tables from wiki
>From: Carsten Klapp <car...@us...>
>To: php...@li...
>
>
>On Thursday, December 4, 2003, at 09:25  am, Reini Urban wrote:
>
>>  The attached diff is better.
>>  It supports summary also, has no linebreaks and
>>  it also includes the new pgsrc of the description page.
>
>Hi,
>
>Thanks you two, for working on this!
>
>I applied the second patch to
>htdocs/phpwiki2/lib/plugin/OldStyleTable.php for testing. Only one
>problem, the caption does not show. :/
>
>
>http://phpwiki.sourceforge.net/phpwiki/OldStyleTablePlugin
>
>
>I found the bug: caption is not an attribute of <table>, rather it must
>be the first sub-element (if present). So it should be like this:
>
><table summary="summary">
><caption>Table caption</caption>
><tr><td>first row</td></tr>
>
>http://www.w3.org/TR/1999/REC-html401-19991224/struct/tables.html
>
>Cheers,
>Carsten
>
>
>Here's the updated patch: (some of it is text reformatting)
>
>Index: OldStyleTable.php
>===================================================================
>RCS file: /cvsroot/phpwiki/phpwiki/lib/plugin/OldStyleTable.php,v
>retrieving revision 1.7
>diff -U2 -r1.7 OldStyleTable.php
>--- OldStyleTable.php	21 Feb 2003 23:00:35 -0000	1.7
>+++ OldStyleTable.php	5 Dec 2003 20:37:28 -0000
>@@ -1,4 +1,5 @@
>   <?php // -*-php-*-
>   rcs_id('$Id: OldStyleTable.php,v 1.7 2003/02/21 23:00:35 dairiki Exp
>$');
>+
>   /**
>    Copyright 1999, 2000, 2001, 2002 $ThePhpWikiProgrammingTeam
>@@ -26,5 +27,5 @@
>    * Usage:
>    * <pre>
>- *  <?plugin OldStyleTable
>+ *  <?plugin OldStyleTable border||=0 summary=""
>    *  ||  __Name__               |v __Cost__   |v __Notes__
>    *  | __First__   | __Last__
>@@ -51,5 +52,5 @@
>
>       function getDescription() {
>-      return _("Layout tables using the old markup style.");
>+        return _("Layout tables using the old markup style.");
>       }
>
>@@ -60,5 +61,15 @@
>
>       function getDefaultArguments() {
>-        return array();
>+        return array(
>+                     'caption'     => '',
>+                     'cellpadding' => '1',
>+                     'cellspacing' => '1',
>+                     'border'      => '1',
>+                     'summary'     => '',
>+                     );
>+    }
>+
>+    function handle_plugin_args_cruft($argstr, $args) {
>+        return;
>       }
>
>@@ -67,12 +78,33 @@
>           include_once('lib/InlineParser.php');
>
>+        $args = $this->getArgs($argstr, $request);
>+        $default = $this->getDefaultArguments();
>+        foreach (array('cellpadding', 'cellspacing', 'border') as
>$arg) {
>+            if (!is_numeric($args[$arg])) {
>+                $args[$arg] = $default[$arg];
>+            }
>+        }
>           $lines = preg_split('/\s*?\n\s*/', $argstr);
>-        $table = HTML::table(array('cellpadding' => 1,
>-                                   'cellspacing' => 1,
>-                                   'border' => 1));
>+        $table_args = array();
>+        $default_args = array_keys($default);
>+        foreach ($default_args as $arg) {
>+            if ($args[$arg] == '' and $default[$arg] == '')
>+                continue;			// ignore '' arguments
>+            $table_args[$arg] = $args[$arg];
>+        }
>+        unset($table_args['caption']);
>+        $table = HTML::table($table_args);
>+        if ($caption = $args['caption']) {
>+            $table->pushContent(HTML::caption(array('align'=>'top'),
>$caption));
>+        }
>
>           foreach ($lines as $line) {
>               if (!$line)
>                   continue;
>+            if (strstr($line, "=")) {
>+           	$tmp = explode("=", $line);
>+           	if (in_array(trim($tmp[0]), $default_args))
>+                    continue;
>+            }
>               if ($line[0] != '|')
>                   return $this->error(fmt("Line does not begin with a
>'|'."));
>@@ -85,6 +117,5 @@
>       function _parse_row ($line, $basepage) {
>           $brkt_link = "\\[ .*? [^]\s] .*? \\]";
>-        $cell_content  = "(?: [^[] | ".ESCAPE_CHAR."\\[ | $brkt_link
>)*?";
>-
>+        $cell_content  = "(?: [^[] | " . ESCAPE_CHAR . "\\[ |
>$brkt_link )*?";
>           preg_match_all("/(\\|+) (v*) ([<>^]?) \s* ($cell_content) \s*
>(?=\\||\$)/x",
>                          $line, $matches, PREG_SET_ORDER);
>@@ -116,4 +147,8 @@
>       }
>   };
>+
>+// Caption & summary patch from [phpwiki-talk] by MickiKaufman and
>+// ReiniUrban 2003-12-04. Not yet checked into CVS.
>+
>
>   // $Log: OldStyleTable.php,v $
>
>
>
>--__--__--
>
>Message: 7
>Date: Fri, 05 Dec 2003 22:14:31 +0100
>From: Reini Urban <ru...@x-...>
>To: php...@li...
>Subject: Re: [Phpwiki-talk] Re: Adding '<caption>' tags to tables from wiki
>  (Reini Urban)
>
>Micki Kaufman schrieb:
>>  I noticed the resulting table has the attribute 'caption', like this:
>>
>>  <table caption="This is a caption" cellpadding="1" cellspacing="1"
>>  border="1">
>>
>>  but it really should be a separate open and close tag, before the first
>>  'tr' tag, like:
>>
>>  <table cellpadding="1" cellspacing="1" border="1">
>>  <caption>This is a caption</caption>
>>  <tr>
>
>oops!
>sorry, i didn't have a look into the specs. i'll do the change asap.
>it's very easy.
>--
>Reini Urban
>http://xarch.tu-graz.ac.at/home/rurban/
>
>
>
>--__--__--
>
>Message: 8
>Date: Fri, 05 Dec 2003 22:16:15 +0100
>From: Reini Urban <ru...@x-...>
>To: php...@li...
>Subject: Re: [Phpwiki-talk] Re: Adding '<caption>' tags to tables from wiki
>  (Reini Urban)
>
>oops again, carsten already did it. thanks.
>
>Reini Urban schrieb:
>  > oops!
>  > sorry, i didn't have a look into the specs. i'll do the change asap.
>  > it's very easy.
>
>>  Micki Kaufman schrieb:
>>>  I noticed the resulting table has the attribute 'caption', like this:
>>>
>>>  <table caption="This is a caption" cellpadding="1" cellspacing="1"
>>>  border="1">
>>>
>>>  but it really should be a separate open and close tag, before the
>>>  first 'tr' tag, like:
>>>
>>>  <table cellpadding="1" cellspacing="1" border="1">
>>>  <caption>This is a caption</caption>
>>>  <tr>
>--
>Reini Urban
>http://xarch.tu-graz.ac.at/home/rurban/
>
>
>
>--__--__--
>
>Message: 9
>Date: Fri, 5 Dec 2003 17:12:51 -0500
>Subject: Re: [Phpwiki-talk] Re: Adding '<caption>' tags to tables 
>from wiki (Reini Urban)
>Cc: Micki Kaufman <mic...@co...>
>To: php...@li...
>From: Carsten Klapp <car...@us...>
>
>
>On Friday, December 5, 2003, at 03:48  pm, Micki Kaufman wrote:
>
>>  Hi Carsten!
>>
>>  Looks great! Rocking rocking rocking!!!
>>
>>  Hey - if centeredness is a little tweaky, can we set the caption to be
>>  left-flush (align=left), or remove the align tag? I assume that's NOT
>>  in the stylesheet cause it's an attribute of the caption element.
>>
>>  What do you think?
>>
>>  Thanks,
>>  Micki
>>
>
>Hi Micki,
>
>I understand the need for align=top for the older browsers, but I'm a
>little reluctant to do (subjectively-) TOO much with depreciated HTML4
>attributes in the release code of PhpWiki.
>
>Of course you're absolutely welcome to modify your own wikis according
>to your situation and needs. :)
>
>It should be pretty easy to tweak, just change this line:
>
>              $table->pushContent(HTML::caption(array('align'=>'top'),
>$caption));
>
>As far as I understand, align=left would insert the caption in
>front(left) of the WHOLE table, probably not what you want. Also, the
>alignment of caption text WITHIN the cell is not clearly defined by the
>HTML standard, and really is up to the individual browser how it is
>displayed. You can try something like this:
>
>              $table->pushContent(HTML::caption(array('align' => 'top',
>                                                      'style' =>
>'text-align:left;'),
>                                                $caption));
>
>Or, add this to the CSS stylesheet: (but it will affect ALL tables in
>PhpWiki, even page lists returned from searches, etc.)
>
>table caption { text-align: left; }
>
>Carsten
>
>
>
>--__--__--
>
>Message: 10
>Date: Fri, 05 Dec 2003 15:58:19 -0800
>From: Joby Walker <joby@u.washington.edu>
>To: Joby Walker <joby@u.washington.edu>
>CC: php...@li...
>Subject: Re: [Phpwiki-talk] 1.4 before Christmas
>
>I'll see what I can do this weekend, but I've been swamped by worms 
>and jury duty...
>
>jbw
>
>Joby Walker wrote:
>
>>  Reini Urban wrote:
>>
>>>  aphid schrieb:
>>>
>>>>  On Nov 9, 2003, at 11:53 AM, Steve Wainstead wrote:
>>>>
>>>>>  I'd like to work on documentation and get the current code base
>>>>>  released as 1.4 before Christmas.
>>>>
>>>>
>>>>
>>>>
>>>>  Hm, any chance at external db user auth making it into 1.4?  That
>>>>  would like Christmas in December.. err.. you know what I mean.
>>>
>>>
>>>
>>>  Yes, the chance is good, since I quit my dayjob which really exhausted
>>>  me, and I have much more time now.
>>>
>>>  I just need some weeks to setup my infrastructure to continue where I
>>>  left.
>>
>>
>>  I should be able to get the group checking working too.
>>
>>  jbw
>>
>>
>>
>>  -------------------------------------------------------
>>  This SF.Net email sponsored by: ApacheCon 2003,
>>  16-19 November in Las Vegas. Learn firsthand the latest
>>  developments in Apache, PHP, Perl, XML, Java, MySQL,
>>  WebDAV, and more! http://www.apachecon.com/
>>  _______________________________________________
>>  Phpwiki-talk mailing list
>>  Php...@li...
>>  https://lists.sourceforge.net/lists/listinfo/phpwiki-talk
>
>
>
>
>--__--__--
>
>_______________________________________________
>Phpwiki-talk mailing list
>Php...@li...
>https://lists.sourceforge.net/lists/listinfo/phpwiki-talk
>
>
>End of Phpwiki-talk Digest


-- 

Micki
mailto:mic...@co...

Re: [Phpwiki-talk] WikiUser.php REQUIRE_EMAIL_VERIFICATION and User classes

[Carsten K. <car...@us...>]

On Saturday, December 6, 2003, at 07:52  am, Reini Urban wrote:

> Carsten Klapp schrieb:
>> Modified Files:
>> 	WikiUser.php Log Message:
>> Security bugfix (minor): Prevent BogoUser~s from saving extraneous
>> _pref object meta-data within locked pages.
>> Previously, BogoUser~s who signed in with a (valid) WikiWord such as
>> "HomePage" could actually save preferences into that page, even though
>> it was already locked by the administrator. Thus, any subsequent
>> WikiLink~s to that page would become prefixed with "that nice little"
>> UserIcon, as if that page represented a valid user.
>> Note that the admin can lock (even) non-existant pages as desired or
>> necessary (i.e. any DB page whose revision==0), to prevent the
>> arbitrary BogoUser from saving preference metadata into such a page;
>> for example, the silly WikiName "@qmgi`Vcft_x|" (that is the
>> \$examplechars presented in login.tmpl, in case it is not visible here
>> in the CVS comments).
>> http://phpwiki.sourceforge.net/phpwiki/
>> %C0%F1%ED%E7%E9%E0%D6%E3%E6%F4%DF%F8%FC?action=lock
>> To remove the prefs metadata from a page, the admin can use the
>> EditMetaData plugin, enter pref as the key, leave the value box empty
>> and then submit the change. For example:
>> http://phpwiki.sourceforge.net/phpwiki/
>> _EditMetaData?page=%C0%F1%ED%E7%E9%E0%D6%E3%E6%F4%DF%F8%FC
>> (It seems a rethinking of WikiUserNew.php with its WikiUser and
>> UserPreferences classes is in order. Ideally the WikiDB would
>> transparently handle such a situation, perhaps BogoUser~s should
>> simply be restricted to saving preferences into a cookie until his/her
>> e-mail address has been verified.)
>
> I think this should be another index.php option.
>
> if (!defined('REQUIRE_EMAIL_VERIFICATION')) 
> define('REQUIRE_EMAIL_VERIFICATION',false);
>
> This would go for storing users in the External DB (if allowed),
> for the EmailNotification on page changes feature and saving prefs in 
> the homepage.
>
> One might need to allow this without EMAIL_VERIFICATION.
>
> Regarding EMAIL_VERIFICATION:
>   we need another url action with the sent id as get parameter
> (e.g.: phpwiki.sf.net/demo/UserName?verify=48731984718937489312749812)
>   and we might need a table to store this pending request id.
>   or would it be enough to store the verification id in the userpage 
> metadata for this short time.?
>   as long as the verify metadata in the users homepage is present, the 
> preferences are restricted to cookies.
>
> So will need those new userpref classes:
>   CookieUserPref, HomepageUserPref, ExternalFileUserPref and 
> ExternalDbUserPref; dependent on where to read/write preferences.
>
> But on the contrary different classes where to read/write authinfo:
>   AnonUserAuth, BogoUserAuth, AdminUserAuth (questionable), 
> CookieUserAuth, HomepageUserAuth, ExternalImapUserAuth, 
> ExternalLdapUserAuth, ExternalFileUserAuth, ExternalDbUserPref.
>
> One could throw away AdminUserAuth because the Anon- and BogoUserAuth 
> class methods should check if the given username is the ADMIN_USER and 
> force a password on this attempted login. All other classes require a 
> password.
>
> Maybe we should provide a ALLOW_EMPTY_PASSWORD config option also, 
> maybe also some kind of password strength restriction policy (min 6 
> chars, ...)
>
> Ok?
> -- 
> Reini Urban
> http://xarch.tu-graz.ac.at/home/rurban/


Yes, I agree new user classes will have to be added for the external 
authentication. So many possibilities you suggested, it's going to take 
a while to finish that all. :)

For the first implementation of WikiUserNew, I think I'll just try to 
get it running with the basic classes (as we have now, just anon, bogo 
and admin), but also keeping in mind to leave room to be able to add 
the external auth.

Last night I thought more about the bogouser prefs "problem", I think I 
have an easy solution:

If ALLOW_BOGO_LOGIN is set:

* BogoUser cannot save preferences into the page at all (or other 
external db/backend), only cookies.
* BogoUser may enter an email address, but it will not be verified, 
because anyone can log in as that user and alter it (malicious or 
accidental).
* Once BogoUser enters a password, he is (naturally) no longer a 
BogoUser class but a PasswordUser. At this point, it does not matter if 
his email is verified or not, we let him save prefs. Provided the admin 
has not set REQUIRE_EMAIL_VERIFICATION.

If ALLOW_PASSWORD_LOGIN is set:

* If a PasswordUser deletes his password (and if ALLOW_BOGO_LOGIN is 
set), he gets a warning: "Your preferences will stored in a cookie from 
now and prefs deleted from the page. Your email address could be 
exposed to other users, so delete it if this is not what you want."
* If ALLOW_BOGO_LOGIN is NOT set, a user cannot delete his password, 
only change it. (But it depends on whether external auth allows this.)

Minimum password length is also a good idea.

Carsten

[Phpwiki-talk] Re: [phpwiki-checkins] CVS: phpwiki index.php,1.113,1.114

[Steve W. <sw...@pa...>]

Be careful when you commit changes to index.php. It breaks the demo and 
test sites. Not a huge deal, but jsut something to be aware of.

Some of you might not know that there even is a test site. It's reloaded 
from scratch every night (database schema wiped and reloaded too).

http://phpwiki.sf.net/test/

~swain

Carsten Klapp wrote:

>Update of /cvsroot/phpwiki/phpwiki
>In directory sc8-pr-cvs1:/tmp/cvs-serv7942
>
>Modified Files:
>	index.php 
>Log Message:
>ACK! gettext is not available at this point in index.php.
>
>Index: index.php
>===================================================================
>RCS file: /cvsroot/phpwiki/phpwiki/index.php,v
>retrieving revision 1.113
>retrieving revision 1.114
>diff -u -2 -b -p -d -r1.113 -r1.114
>--- index.php	5 Dec 2003 15:51:37 -0000	1.113
>+++ index.php	5 Dec 2003 16:00:42 -0000	1.114
>@@ -650,5 +650,5 @@ define('INTERWIKI_MAP_FILE', "lib/interw
> //
> // The default behavior is to match Category* and Topic* links.
>-$keywords = array(_("Category"), _("Topic"));
>+$keywords = array("Category", "Topic");
> $KeywordLinkRegexp = '(?<=^'. join('|^', $keywords) . ')[[:upper:]].*$';
> 
>@@ -666,5 +666,5 @@ if (!defined('COPYRIGHTPAGE_URL')) defin
>     'http://www.gnu.org/copyleft/gpl.html#SEC1');
> if (!defined('AUTHORPAGE_TITLE')) define('AUTHORPAGE_TITLE',
>-    _("The PhpWiki Programming Team"));
>+    "The PhpWiki Programming Team");
> if (!defined('AUTHORPAGE_URL')) define('AUTHORPAGE_URL',
>     'http://phpwiki.sourceforge.net/phpwiki/ThePhpWikiProgrammingTeam');
>@@ -832,4 +832,7 @@ if (defined('VIRTUAL_PATH') and defined(
> 
> // $Log$
>+// Revision 1.114  2003/12/05 16:00:42  carstenklapp
>+// ACK! gettext is not available at this point in index.php.
>+//
> // Revision 1.113  2003/12/05 15:51:37  carstenklapp
> // Added note that use of the configurator is depreciated.
>
>
>
>-------------------------------------------------------
>This SF.net email is sponsored by: SF.net Giveback Program.
>Does SourceForge.net help you be more productive?  Does it
>help you create better code?  SHARE THE LOVE, and help us help
>YOU!  Click Here: http://sourceforge.net/donate/
>_______________________________________________
>phpwiki-checkins mailing list
>php...@li...
>https://lists.sourceforge.net/lists/listinfo/phpwiki-checkins
>
>  
>

[Phpwiki-talk] WikiUser.php REQUIRE_EMAIL_VERIFICATION and User classes

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

Carsten Klapp schrieb:
> Modified Files:
> 	WikiUser.php 
> Log Message:
> Security bugfix (minor): Prevent BogoUser~s from saving extraneous
> _pref object meta-data within locked pages.
> 
> Previously, BogoUser~s who signed in with a (valid) WikiWord such as
> "HomePage" could actually save preferences into that page, even though
> it was already locked by the administrator. Thus, any subsequent
> WikiLink~s to that page would become prefixed with "that nice little"
> UserIcon, as if that page represented a valid user.
> 
> Note that the admin can lock (even) non-existant pages as desired or
> necessary (i.e. any DB page whose revision==0), to prevent the
> arbitrary BogoUser from saving preference metadata into such a page;
> for example, the silly WikiName "@qmgi`Vcft_x|" (that is the
> \$examplechars presented in login.tmpl, in case it is not visible here
> in the CVS comments).
> 
> http://phpwiki.sourceforge.net/phpwiki/
> %C0%F1%ED%E7%E9%E0%D6%E3%E6%F4%DF%F8%FC?action=lock
> 
> To remove the prefs metadata from a page, the admin can use the
> EditMetaData plugin, enter pref as the key, leave the value box empty
> and then submit the change. For example:
> 
> http://phpwiki.sourceforge.net/phpwiki/
> _EditMetaData?page=%C0%F1%ED%E7%E9%E0%D6%E3%E6%F4%DF%F8%FC
> 
> (It seems a rethinking of WikiUserNew.php with its WikiUser and
> UserPreferences classes is in order. Ideally the WikiDB would
> transparently handle such a situation, perhaps BogoUser~s should
> simply be restricted to saving preferences into a cookie until his/her
> e-mail address has been verified.)

I think this should be another index.php option.

if (!defined('REQUIRE_EMAIL_VERIFICATION')) 
define('REQUIRE_EMAIL_VERIFICATION',false);

This would go for storing users in the External DB (if allowed),
for the EmailNotification on page changes feature and saving prefs in 
the homepage.

One might need to allow this without EMAIL_VERIFICATION.

Regarding EMAIL_VERIFICATION:
   we need another url action with the sent id as get parameter
(e.g.: phpwiki.sf.net/demo/UserName?verify=48731984718937489312749812)
   and we might need a table to store this pending request id.
   or would it be enough to store the verification id in the userpage 
metadata for this short time.?
   as long as the verify metadata in the users homepage is present, the 
preferences are restricted to cookies.

So will need those new userpref classes:
   CookieUserPref, HomepageUserPref, ExternalFileUserPref and 
ExternalDbUserPref; dependent on where to read/write preferences.

But on the contrary different classes where to read/write authinfo:
   AnonUserAuth, BogoUserAuth, AdminUserAuth (questionable), 
CookieUserAuth, HomepageUserAuth, ExternalImapUserAuth, 
ExternalLdapUserAuth, ExternalFileUserAuth, ExternalDbUserPref.

One could throw away AdminUserAuth because the Anon- and BogoUserAuth 
class methods should check if the given username is the ADMIN_USER and 
force a password on this attempted login. All other classes require a 
password.

Maybe we should provide a ALLOW_EMPTY_PASSWORD config option also, maybe 
also some kind of password strength restriction policy (min 6 chars, ...)

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