phpwiki-talk

[Phpwiki-talk] small bug and patch for Calendar List Plugin

[John C. <joh...@ua...>]

Hello,
  Noticed a small bug in the Calendar List plugin.  It was not generating
the page name the same way as the calendar prlugin, so if you used a prefix,
the CLP would not pick up the page.

  And now a feature request... it would be nice to have the CLP display only
the first n lines, or the page summary, instead of the entire page.  We put
meeting minutes into our calendar and that kind of makes the CLP useless :-)

Below is a patch for making the CLP work like the  CP.

Thanks,

John Cole

Index: lib/plugin/CalendarList.php
===================================================================
RCS file: /cvsroot/phpwiki/phpwiki/lib/plugin/CalendarList.php,v
retrieving revision 1.1
diff -u -r1.1 CalendarList.php
--- lib/plugin/CalendarList.php 18 Nov 2003 19:06:03 -0000 1.1
+++ lib/plugin/CalendarList.php 6 Jan 2004 15:23:11 -0000
@@ -27,7 +27,7 @@
     }
 
     function getDefaultArguments() {
-        return array('prefix'       => '[pagename]',
+        return array('prefix'       => '[pagename]' . SUBPAGE_SEPARATOR,
                      'date_format'  => '%Y-%m-%d',
                      'year'         => '',
                      'month'        => '',
@@ -42,7 +42,7 @@
         $args = &$this->args;
         $date_string = strftime($args['date_format'], $time);
 
-        $page_for_date = $args['prefix'] . SUBPAGE_SEPARATOR .
$date_string;
+        $page_for_date = $args['prefix'] . $date_string;
         $t = localtime($time, 1);
 
         $td = HTML::td(array('align' => 'center'));

-------------------------------------
This email and any files transmitted with it are confidential and intended solely for the use of the individual or entity to whom they are addressed. If you have received this email in error please notify the system manager. This message contains confidential information and is intended only for the individual named. If you are not the named addressee you should not disseminate, distribute or copy this e-mail.

[Phpwiki-talk] documentation update - README.coding

[Bob A. <apt...@cy...>]

Hi,

You may want to change the URL to PEAR coding style in
doc/README.coding from

    http://www.php.net/manual/en/pear.standards.php

to

    http://pear.php.net/manual/en/standards.php

Also, the current Vim tab settings for PEAR coding style is

  set expandtab
  set shiftwidth=4
  set softtabstop=4
  set tabstop=4

which goes against the 'please use spaces and set tab width to 8' style
specified. Regardless, it should be easy enough to change to whatever
style is deemed appropriate for the project. Personally, I try to stay
consistent with a project's dominant style[1] but it rarely hurts to
explicitly spell it out.

A more rigorous standard is at
http://www.phpinfo.net/articles/article_php-coding-standard.html It's
probably overkill but it can't hurt to skim it for good ideas that don't
require a lot of investment.

Ideally, we could recommend a GPL'd cross-platform command-line PHP
source code formatter ("pretty-printer") and a config file. Something
like perltidy would be nice; all I can find are either online formatters
(no source, no CLI), source highlighters (only formats code for
presentation), commercial tools (no GPL), or Windows-only tools (not
cross-platform.) Maybe someone else can coax a better answer out of
Google.

Also, another nice resource I found was php_abb.vim, a set of Vim macros
that expand PHP functions, etc., from abbreviations. It doesn't help
with coding standards but it may simplify PHP coding for the
brain-damaged Vim users among us[2]. :)

Please don't take any of this as criticism of phpwiki development; I'm
just looking for ways to help people contribute legible code and to
clean up coding on my own projects.

hth,

-- Bob

[1] Except for the case of badly-formatted perl, in which case I run the
code through perltidy() and pray the maintainer has sense enough to
check in the reformatted code.

[2] No flames, please. Gads, I can still remember sitting in my Machine
Language Programming class, scowling at the terminal, asking my TA if
there was any other editor I could use besides vi. His answer: "Nope."
That was almost twenty years ago and I'm _still_ stuck using this crappy
editor. Every 2-3 years I try to get with the program and use emacs but
every time I do, I end up beating my head against the keyboard and
weeping uncontrollably because I accidentally hit
<alt><meta><esc><backspace>-Q which is mapped to "destabilize Bolivian
economy" or "cause mudslides in Orange County" or something, then I give
up, taking my vi-damaged brain back to my brain-damaged editor... :)

Re: [Phpwiki-talk] ziphtml/dumphtml and ended by a zip/dump not complete

[Bob A. <apt...@cy...>]

Hi,

[... drifting in from the ancient past ...]

On Mon, 3 Nov 2003 10:06:51 -0000 "Frank Shearar"
<fra...@rn...> wrote:

> > >>> "ad...@fo..." 11/02/03 18:07 >>>
> > The dumphtml  or the  ziphtml action (from  the latest version  of the
> > cvs) generates an incomplete dump.  For dumphtml, I have an average of
> > 120 pages generated but stops before  end (there is quite more in your
> > wiki  around 1000).  For the  zip file,  the generation  stops  at the
> > middle  with a  corrupted zip  archive.  It seems  that this  function
> > generates  a  sig11  on  the  related httpd  daemon  (only  with  this
> > function). 
> > 
> > rcs_id('$Id: main.php,v 1.99 2003/03/07 02:39:47 dairiki Exp $');
> > rcs_id('$Id: loadsave.php,v 1.80 2003/03/07 02:46:57 dairiki Exp $');
> > 
> > Apache/1.3.28   (Unix)  PHP/4.3.3   mod_gzip/1.3.19.1a  mod_perl/1.28
> > mod_python/2.7.8 Python/2.3 mod_ssl/2.8.15 OpenSSL/0.9.7c
> > 
> > Is it a known  issue ? or is it related to the  size of the Wiki (more
> > than 1000 pages) ? or something else related to PHP itself ? 
> 
> The last time I tried this (on a wiki with ~1500 pages) what I found was
> that each page would take longer to dump than the page before. You'll be
> able to see if you're having the same problem by inspecting the XHTML
> generated - each page will have a "phpwiki source:" comment which gets
> progressively longer.
> 
> The solution is to change your index.php somewhere around line 57 from
> 
>   if (!defined('DEBUG')) define ('DEBUG', 1);
> 
> to
> 
>   if (!defined('DEBUG')) define ('DEBUG', false);
> 
> Once I'd done this I could quite happily do a proper zipdump.

I'm running 1.3.3 and sometime in the indeterminate past my automated
job to pull the full (archive) zip dumps started generating corrupted
archives. Oddly, these files were smaller than the zip snapshots.

Recently I dug into the code looking for an answer and I started
substituting files from CVS into the current application. This didn't
work because my problem wasn't in the code, it was in php.ini. Once I
increased memory_limit from 8M to 32M and increased max_execution_time
from 90 to 180, the problem of corrupt archives went away.

I'm virtually certain that increasing memory_limit solved the problem,
though I have no idea what the actual limit should be (MB consumed per
wiki page or per MB of wiki content); I doubt that increasing
max_execution_time helped any. Either way, the problem is resolved for
the time being, and hopefully I'll get my wiki moved to a more modern,
supported platform soon. Getting the zip dump working has made this much
more achievable.

One other question: is there a way to get a zip dump without going
through the webserver, i.e. is there a php command-line script I can run
to get the zip dump? My version of Apache has become very unstable as of
late and I was worried that I wouldn't be able to pull a decent backup
before the server just tanked completely.

Thanks much,

-- Bob

[Phpwiki-talk] Re: Error: XML cannot be displayed

[Doyce T. <sm...@av...>]

<!DOCTYPE html PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">
<html>
<head>
  <meta http-equiv="Content-Type" content="text/html;charset=ISO-8859-1">
  <title></title>
</head>
<body>
<meta content="text/html;charset=ISO-8859-1" http-equiv="Content-Type">
<title></title>
And just to show I want to help out when I can... I didn't see a reply
to this in the archives, so...<br>
<br>
What you have to do to fix this is edit the index.php and uncomment
this line:<br>
<br>
define('COMPRESS_OUTPUT', false);<br>
&nbsp;<br>
This shuts off php's attempts to compress the output files for the wiki
-- I'd guess you're on apache and the server's already trying to do
this, but it could be any number of things -- at any rate, the
compression is failing, which is what's kicking out the error.&nbsp; If you
shut off the attempt... no more problems.<br>
<br>
&nbsp;On Nov 24, 2003, at 2:24 PM, Stanislaw Berka wrote:<br>
&nbsp;<br>
&nbsp;&gt; One of my PHPWiki's, displays a message "The XML page cannot be &nbsp;<br>
&nbsp;&gt; displayed".&nbsp; If you do refresh, the page shows fine and from now
on it &nbsp;<br>
&nbsp;&gt; all works.&nbsp; The error is only the first time per session.&nbsp; Any
ideas?<br>
&nbsp;&gt; Stan Berka<br>
&nbsp;&gt;<br>
&nbsp;&gt; ----- The complete error message:<br>
&nbsp;&gt;<br>
&nbsp;&gt; The XML page cannot be displayed<br>
&nbsp;&gt; Cannot view XML input using XSL style sheet. Please correct the
error &nbsp;<br>
&nbsp;&gt; and then click the Refresh button, or try again later.<br>
<br>
&nbsp;<br>
<br>
</body>
</html>

[Phpwiki-talk] Assertion failed errors on flatfile phpwiki

[Doyce T. <sm...@av...>]

Pertinent info:  I'm on a hosted account.  The server is running Linux, 
Apache version 1.3.29, PHP version 4.3.4, and I'm running flatfile dbm 
(the default config).  The wiki can be viewed at 
http://www.average-bear.com/wiki/

-----

My problem: I'm consistently getting 'assertion failed' messages while 
using phpwiki.  Examples follow:

EXAMPLE 1
When saving a page I've been editing, I will often (not always) get an 
error message when I hit save: a page will display:

lib/WikiDB.php:787: Fatal[0]: <br 
/>/home/doyce/public_html/wiki/lib/WikiDB.php:787: : Assertion failed <br />

    * Note 1: this doesn't always happen -- usually I get this error 
when I save a page to which I've added a WikiWord.  The page DOES still 
save... if I refresh from the error message page, the 'reload' 
confirmation appears and the page loads correctly.

    * Note 2:  the <br /> bits in the error message are not a result of 
me Viewing the source of the page... they actually display that way on 
the page.  "View source" on this error message shows me that the page is 
specifically showing me the special html characters using ascii encoding.

EXAMPLE 2
The 'Diff' button on the bottom of each page fails intermittently (about 
as often as I get the error message in Example 1, above, but not on the 
same pages.  The error message (very similar to Example 1) reads:

lib/WikiDB.php:787: Fatal[0]: <br 
/>/home/doyce/public_html/wiki/lib/WikiDB.php:787: : Assertion failed <br />

EXAMPLE 3
On most of the pages on which Diff doesn't work, Page History also fails:

lib/WikiDB.php (In template 'browse') (In template 'body') (In template 
'html'):787: Fatal[0]: <br 
/>/home/doyce/public_html/wiki/lib/WikiDB.php:787: : Assertion failed <br />

EXAMPLE 4
The RecentChanges page simple doesn't work at all.  The error message 
reads: 

lib/WikiDB/backend/dumb/MostRecentIter.php (In template 'browse') (In 
template 'body') (In template 'html'):28: Fatal[0]: <br 
/>/home/doyce/public_html/wiki/lib/WikiDB/backend/dumb/MostRecentIter.php:28: 
: Assertion failed <br />

EXAMPLE 5
RecentEdits also doesn't work at all.  The error message is suspiciously 
similar to the RecentChanges message:

lib/WikiDB/backend/dumb/MostRecentIter.php (In template 'browse') (In 
template 'body') (In template 'html'):28: Fatal[0]: <br 
/>/home/doyce/public_html/wiki/lib/WikiDB/backend/dumb/MostRecentIter.php:28: 
: Assertion failed <br />

-----

I realize that most of these errors are probably connected to one or two 
screw ups in configuration on my part, and I'm perfectly willing to work 
through whatever I need to do to fix them -- I'm very impressed with 
PHPWiki as a whole and I look forward to working with it extensively in 
the future, so any help on these issues would be much appreciated.  Thanks.

Re: [Phpwiki-talk] Corrupted 1.3.7 archive

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

On Sun, Jan 04, 2004 at 01:58:37PM -0500, Steve Wainstead wrote:
> Where did you find the download link? I just checked phpwiki.org and 
> the project dowload page, and the tarball is 1.3MB and untars just 
> fine.
> 
> http://prdownloads.sourceforge.net/phpwiki/phpwiki-1.3.7.tgz

...?use_mirror=flow

And it just did it again - another 8.5MB download.

It may be a mirror problem....

<tick tock>

Yup, it's a mirror problem.  Aleron worked fine.

Oh joy of frantabulous joys.  SF has mirror problems - and damned *weird* ones
at that... might want to kick them about that or something, because some
proportion of users (most aussie ones, I would presume) are getting screwed up
downloads.

- Matt

Re: [Phpwiki-talk] Corrupted 1.3.7 archive

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

Where did you find the download link? I just checked phpwiki.org and 
the project dowload page, and the tarball is 1.3MB and untars just 
fine.

http://prdownloads.sourceforge.net/phpwiki/phpwiki-1.3.7.tgz

On Jan 3, 2004, at 6:54 PM, Matt Palmer wrote:

> Who thought it was a clever idea to put another a corrupted 1.3.7 
> tarball into
> the 1.3.7 archive?  Bloated the thing out to 8.5 MB.  It's also badly
> corrupted.  Could someone fix the tarball up and let me know when it's 
> done so
> I can start work packaging this latest version for Debian?
>
> - Matt
>
>
> -------------------------------------------------------
> This SF.net email is sponsored by: IBM Linux Tutorials.
> Become an expert in LINUX or just sharpen your skills.  Sign up for 
> IBM's
> Free Linux Tutorials.  Learn everything from the bash shell to sys 
> admin.
> Click now! http://ads.osdn.com/?ad_id=1278&alloc_id=3371&op=click
> _______________________________________________
> Phpwiki-talk mailing list
> Php...@li...
> https://lists.sourceforge.net/lists/listinfo/phpwiki-talk
>

[Phpwiki-talk] Corrupted 1.3.7 archive

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

Who thought it was a clever idea to put another a corrupted 1.3.7 tarball into
the 1.3.7 archive?  Bloated the thing out to 8.5 MB.  It's also badly
corrupted.  Could someone fix the tarball up and let me know when it's done so
I can start work packaging this latest version for Debian?

- Matt

[Phpwiki-talk] possible exploit with 1.3.2-jeffs-hacks ?

[etb <li...@so...>]

Hi Everyone,

   I was running 1.3.2-jeffs-hacks and noticed something a bit unusual
in the log. v 1.3.2-jeff-hacks was in the /phpwiki directory:

[A]
128.242.197.XXX - - [25/Dec/2003:19:53:41 -0500] "GET /phpwiki
            HTTP/1.0" 301 319 "-" "Mozilla/4.0 (compatible; MSIE 5.01;
            Windows 98; MSN 6.0)"

[B]
128.242.197.XXX - - [25/Dec/2003:19:53:41 -0500] "GET
            /phpwiki/index.php/Psychotropic%20Drugs?PHPSESSID=dc10fb8c24e4fcbfa76464ae487cd978
            HTTP/1.0" 200 10857 "-" "Mozilla/4.0 (compatible; MSIE
            5.01; Windows 98; MSN 6.0)"

[C]
128.242.197.XXX - - [25/Dec/2003:19:53:46 -0500] "GET /phpwiki/
            HTTP/1.0" 200 9487 "-" "Mozilla/4.0 (compatible; MSIE
            5.01; Windows 98; MSN 6.0)"

The above seemed weird but a red flag did not go up. Notice how the
client was re-directed to a sub-topic from Apache in [A] and later
went back to the directory itself in [C]. The correct ordering is [A]
[C] [B]. Okay, a little odd, then this about 5 hours later:

[D]
128.242.197.XXX - - [26/Dec/2003:00:22:13 -0500] "GET /phpwiki
            HTTP/1.0" 301 319 "-" "Mozilla/4.5 [en]C-CCK-MCD {U S
            WEST.net} (Win98; I)"

[E]
128.242.197.XXX - - [26/Dec/2003:00:22:32 -0500] "GET
            /phpwiki/index.php/Psychotropic%20Drugs?PHPSESSID=dc10fb8c24e4fcbfa76464ae487cd978
            HTTP/1.0" 200 10857 "-" "Mozilla/4.61 (Macintosh; I; PPC)"

[F] ** Correct behavior - note that the user agent has changed from [D] **
128.242.197.XXX - - [26/Dec/2003:00:22:32 -0500] "GET /phpwiki
            HTTP/1.0" 301 319 "-" "Mozilla/4.61 (Macintosh; I; PPC)"

[G]
128.242.197.XXX - - [26/Dec/2003:00:22:36 -0500] "GET /phpwiki/
            HTTP/1.0" 200 9487 "-" "Mozilla/4.61 (Macintosh; I; PPC)"

[H]
128.242.197.XXX - - [26/Dec/2003:00:56:55 -0500] "GET
            /phpwiki/index.php/Psychotropic%20Drugs?PHPSESSID=dc10fb8c24e4fcbfa76464ae487cd978
            HTTP/1.0" 200 10857 "-" "Mozilla/4.0 (compatible; MSIE
            5.5; Windows 98; StarBand Version 1.0)"

[I]
128.242.197.XXX - - [26/Dec/2003:00:57:08 -0500] "GET
            /phpwiki/index.php/Psychotropic%20Drugs?PHPSESSID=dc10fb8c24e4fcbfa76464ae487cd978
            HTTP/1.0" 200 10857 "-" "Mozilla/4.0 (compatible; MSIE
            5.01; Windows 98; MSN 6.0)"

[J]
128.242.197.XXX - - [26/Dec/2003:01:45:09 -0500] "GET
            /phpwiki/index.php/Psychotropic%20Drugs?PHPSESSID=dc10fb8c24e4fcbfa76464ae487cd978
            HTTP/1.0" 200 10857 "-" "Mozilla/4.0 (compatible; MSIE
            5.01; Windows NT 5.0; NetCaptor 6.1.1P)"

[K]
128.242.197.XXX - - [26/Dec/2003:01:45:10 -0500] "GET /phpwiki
            HTTP/1.0" 301 319 "-" "Mozilla/4.0 (compatible; MSIE 5.01;
            Windows NT 5.0; NetCaptor 6.1.1P)"

[L]
128.242.197.XXX - - [26/Dec/2003:01:45:14 -0500] "GET /phpwiki/
            HTTP/1.0" 200 9487 "-" "Mozilla/4.0 (compatible; MSIE
            5.01; Windows NT 5.0; NetCaptor 6.1.1P)"

Anyway, I took phpwiki down until this is cleared up. Does this appear
to be anything I should be concerned about?

Thank you,
Elizabeth

Re: [Phpwiki-talk] rh9, virtual hosts, PrettyWiki or just plain Working?

[Bishop <bi...@pl...>]

Hey Folks,

Hope Xmas was good (for those that do that).

I've got an update on my previous problem, and some of it's good news: 
I've successfully set up a virtual host without requiring any alteration
of the phpwiki RPM, and it only needs two files to get going right:

 - wiki file in the virtualhost document root that looks like this:
http://cvs.platypus.bc.ca/cgi-bin/viewcvs.cgi/*checkout*/bishop/sites/www.platypus.bc.ca/wiki?rev=1.5
 - apache virtualhost setup that includes:
<virtualhost my.site.name>
        # regular stuff, plus:
	alias themes/ /var/www/html/phpwiki/themes/
</VirtualHost>

<Directory /virtualhost/document/root>
	Options +Includes
	Options +Indexes
	Options +ExecCGI
	AllowOverride AuthConfig
</Directory>

Mine includes this and a few more bits:
http://cvs.platypus.bc.ca/cgi-bin/viewcvs.cgi/*checkout*/bishop/virtualhosts/virtuals/platypus.bc.ca?rev=1.11


THE PROBLEM:
I'm still required to use an URL like:  https://my.site.name/wiki/HomePage
and I'd absolutely *love* to find out hwo to make it so that I only need
https://my.site.name/HomePage as a URL.

Anyone succeeded on this, yet?

I can't believe I've made it this far, that I still have most of my hair,
and I even have it all in CVS, even if several beers and the odd pizza
gave their all to support me in this endeavour.  Oh, and all the poor
souls on Halo:!Blood-Only[T1] over whom I totally ran amok in one
singularly excellent night of truly inspired gameplay.  Woo!

 - bish

> http://phpwiki.sourceforge.net/phpwiki/PrettyWiki
>
> Hey Folks,
>
> Last night was full of frustration.  My goal was to get a virtualhost
> PrettyWiki'ed server going with the wiki as its default page, but I was
> completely unsuccessful before exhaustion claimed me about 0800.
>
> I'm hoping someone's done this exact thing:
>
> I want to have a centralized phpwiki installation (/var/www/html/phpwiki/
> as per
> http://apt.platypus.bc.ca/~bishop/apt/RPMS.bish/phpwiki-1.3.7-0.20031219.05.rh9.i386.rpm)
>  and use a index.php in the vhost documentroot to start the wiki.  So,
> here's my setup so far:
>  - RH9 + httpd, php, the usual
> http://apt.platypus.bc.ca/~bishop/apt/RPMS.bish/phpwiki-1.3.7-0.20031219.05.rh9.i386.rpm
> http://apt.platypus.bc.ca/~bishop/apt/i386/rh9/RPMS.bish/apache-incdirmod-1.4-5.20031208.14.rh9.noarch.rpm
>    (that second one sets up dir-tree inclusion of the httpd.d dir)
>  - /etc/httpd/conf/httpd.d/virtualhost.default.conf:
>       NameVirtualHost *:80
>       <virtualhost _default_:80>
>       </virtualhost>
>  - /etc/httpd/conf/httpd.d/virtuals/wiki.platypus.bc.ca:
> (http://cvs.platypus.bc.ca/cgi-bin/viewcvs.cgi/*checkout*/bishop/virtualhosts/virtuals/wiki.platypus.bc.ca?rev=1.1)
>         <VirtualHost *:80>
>         ServerName        www.wiki.platypus.bc.ca
>         ServerAlias        wiki.platypus.bc.ca
>         ServerAlias        www
>         ServerAdmin        web...@wi...
>         DocumentRoot        /home/wiki/wiki
>
>         ErrorLog        logs/wiki.platypus.bc.ca/error_log
>         CustomLog        logs/wiki.platypus.bc.ca/access_log combined
>
>         UserDir                disabled
>         </VirtualHost>
>
>         <Directory /home/wiki>
>         Order Allow,Deny
>         Allow from All
>         Options +Indexes
>         AllowOverride AuthConfig
>         </Directory>
>
>         <Directory /home/wiki/wiki>
>         Options +Includes
>         Options +ExecCGI
>         AllowOverride FileInfo
>         </Directory>
>
> now, when I hit the URL:
> /var/www/html/phpwiki/lib/Template.php:21: Warning[2]: fopen("", "rb") -
> No such file or directory
> /var/www/html/phpwiki/lib/Template.php:22: Warning[2]: stat failed for
> (errno=2 - No such file or directory)
> /var/www/html/phpwiki/lib/Template.php:22: Warning[2]: fread(): supplied
> argument is not a valid File-Handle resource
> /var/www/html/phpwiki/lib/Template.php:23: Warning[2]: fclose(): supplied
> argument is not a valid File-Handle resource
> /var/www/html/phpwiki/lib/Template.php:21: Warning[2]: fopen("", "rb") -
> No such file or directory
> /var/www/html/phpwiki/lib/Template.php:22: Warning[2]: stat failed for
> (errno=2 - No such file or directory)
> /var/www/html/phpwiki/lib/Template.php:22: Warning[2]: fread(): supplied
> argument is not a valid File-Handle resource
> /var/www/html/phpwiki/lib/Template.php:23: Warning[2]: fclose(): supplied
> argument is not a valid File-Handle resource
> /var/www/html/phpwiki/lib/Theme.php:195: Notice[1024]:
> templates/browse.tmpl: not found
> /var/www/html/phpwiki/lib/Theme.php:195: Notice[1024]:
> templates/html.tmpl: not found
>
> SO: What I'm thinking, right now, is that I'm not using this as per
> directions on the bottle.  There may be a bug in the code, and indications
> are that it's near the theming bit, that make a centrally-loated phpwiki
> installation and vhost configs impossible.
>
> Anyone else successfully used a centrally installed phpwiki with
> replacement 'wiki' files located in other parts of the system?
>
> Yours in potential frustration,
>  - bish
>
>
> -------------------------------------------------------
> This SF.net email is sponsored by: IBM Linux Tutorials.
> Become an expert in LINUX or just sharpen your skills.  Sign up for IBM's
> Free Linux Tutorials.  Learn everything from the bash shell to sys admin.
> Click now! http://ads.osdn.com/?ad_id=1278&alloc_id=3371&op=click
> _______________________________________________
> Phpwiki-talk mailing list
> Php...@li...
> https://lists.sourceforge.net/lists/listinfo/phpwiki-talk
>

Re: [Phpwiki-talk] Permissions for index.php -- hide MySQL password?

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

Carsten Klapp schrieb:
> On Monday, December 22, 2003, at 12:10  pm, Reini Urban wrote:
>> that's unfortunately a mysql architectural problem. their fault.
>> every perl and php programmer must deal with that solution somehow.
>>
>> one can read in a local file with the password, which is not in
>> the web docroot, but it must be passed cleartext to the database.
>> since php's are normally associated with the php engine, and no one 
>> local access to the webserver (shell or ftp account), it's quite secure.
>>
>> for important mysql passwords in php apps, one stores the passwords in 
>> a secure location. but it must be readable by the apache user, so 
>> anyone with problematic/erratic php script (there are thousands, I 
>> worked for a very large ISP) will be able to read it, if he knows where.
>>
>>> It seems like a security problem, since index.php must be
>>> readable by the web server; it might be possible for anyone
>>> with a login on the project servers to read the MySQL password.
>>> I've read through archives for PHP, MySQL, and PhpWiki, but
>>> there doesn't seem to be a definitive solution. It seems the
>>> standard operating procedure is to ask the SF sysadmins to
>>> "chgrp nobody index.php". Is there another way?
>>> It may be not so much of an issue, since by design, a wiki
>>> is pretty much wide open for abuse anyway. But it seems
>>> like the MySQL-password-in-a-script problem must be generic to many 
>>> SF projects that use MySQL.
>>
>> yes, see above.
>>
>>> How was this problem solved for the PhpWiki project
>>> demonstration wiki?
>>
>> password stored plaintext in index.php.
>> no one without shell account is able to see the content of index.php.

> However, if anyone does figure out how to use an encrypted database 
> password in PhpWiki's index.php, I'm sure such a modification would be 
> welcome.

as I explained this is impossible.
mysql_connect() expects the password to be plaintext.
see http://www.mysql.com/doc/en/mysql_real_connect.html
http://www.mysql.com/doc/en/Password_security.html and
http://www.mysql.com/doc/en/Secure_connections.html

Mysql supports SSL since 4.0.0, but(!) you have to compile your own 
client and server. and it's quite slow since it encrypts the whole 
protocol data exchange, not only auth.


BTW: MySQL 5.0.0alpha came out right now. nice christmas present.
stored procedures finally, as already presented at the last mysql 
conference.
-- 
Reini Urban
http://xarch.tu-graz.ac.at/home/rurban/

Re: [Phpwiki-talk] Permissions for index.php -- hide MySQL password?

[Bishop <bi...@pl...>]

>
> On Monday, December 22, 2003, at 12:10  pm, Reini Urban wrote:
>
>> Robert Dodier schrieb:
>>> I have a question about the MySQL password. I see that I
>>> can put the admin password in index.php in encrypted form --
>>> that's great. But can I also encrypt the MySQL password?
>>
>> that's unfortunately a mysql architectural problem. their fault.
>> every perl and php programmer must deal with that solution somehow.
>>
>> one can read in a local file with the password, which is not in
>> the web docroot, but it must be passed cleartext to the database.
>> since php's are normally associated with the php engine, and no one
>> local access to the webserver (shell or ftp account), it's quite
>> secure.
>>
>> for important mysql passwords in php apps, one stores the passwords in
>> a secure location. but it must be readable by the apache user, so
>> anyone with problematic/erratic php script (there are thousands, I
>> worked for a very large ISP) will be able to read it, if he knows
>> where.
>>
>>> It seems like a security problem, since index.php must be
>>> readable by the web server; it might be possible for anyone
>>> with a login on the project servers to read the MySQL password.
>>> I've read through archives for PHP, MySQL, and PhpWiki, but
>>> there doesn't seem to be a definitive solution. It seems the
>>> standard operating procedure is to ask the SF sysadmins to
>>> "chgrp nobody index.php". Is there another way?
>>> It may be not so much of an issue, since by design, a wiki
>>> is pretty much wide open for abuse anyway. But it seems
>>> like the MySQL-password-in-a-script problem must be generic to many
>>> SF projects that use MySQL.
>>
>> yes, see above.
>>
>>> How was this problem solved for the PhpWiki project
>>> demonstration wiki?
>>
>> password stored plaintext in index.php.
>> no one without shell account is able to see the content of index.php.
>> --
>> Reini Urban
>> http://xarch.tu-graz.ac.at/home/rurban/
>
> Hi,
>
> I agree with Reini, normally it's not a security issue because usually
> no one has access to the index.php file anyway.
>
> As far as I know, most web-hosts/providers do not even allow direct
> MySQL access from outside their domain anyway, probably only within
> their own localhost(webserver) via php, and not from any external IP
> address.

So, if you store your virtualhost www files in cvs, or plan to, make sure
the index.php (or wiki) file doesn't contain any db password stuff!

(or don't store it in the same place with the viewcvs, or put that one
file or a dbpwd.php inclusion file into the .cvsignore)

 - bish
cvs update -D 1994 bishop/life

Re: [Phpwiki-talk] Permissions for index.php -- hide MySQL password?

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

On Monday, December 22, 2003, at 12:10  pm, Reini Urban wrote:

> Robert Dodier schrieb:
>> I have a question about the MySQL password. I see that I
>> can put the admin password in index.php in encrypted form --
>> that's great. But can I also encrypt the MySQL password?
>
> that's unfortunately a mysql architectural problem. their fault.
> every perl and php programmer must deal with that solution somehow.
>
> one can read in a local file with the password, which is not in
> the web docroot, but it must be passed cleartext to the database.
> since php's are normally associated with the php engine, and no one 
> local access to the webserver (shell or ftp account), it's quite 
> secure.
>
> for important mysql passwords in php apps, one stores the passwords in 
> a secure location. but it must be readable by the apache user, so 
> anyone with problematic/erratic php script (there are thousands, I 
> worked for a very large ISP) will be able to read it, if he knows 
> where.
>
>> It seems like a security problem, since index.php must be
>> readable by the web server; it might be possible for anyone
>> with a login on the project servers to read the MySQL password.
>> I've read through archives for PHP, MySQL, and PhpWiki, but
>> there doesn't seem to be a definitive solution. It seems the
>> standard operating procedure is to ask the SF sysadmins to
>> "chgrp nobody index.php". Is there another way?
>> It may be not so much of an issue, since by design, a wiki
>> is pretty much wide open for abuse anyway. But it seems
>> like the MySQL-password-in-a-script problem must be generic to many 
>> SF projects that use MySQL.
>
> yes, see above.
>
>> How was this problem solved for the PhpWiki project
>> demonstration wiki?
>
> password stored plaintext in index.php.
> no one without shell account is able to see the content of index.php.
> -- 
> Reini Urban
> http://xarch.tu-graz.ac.at/home/rurban/

Hi,

I agree with Reini, normally it's not a security issue because usually 
no one has access to the index.php file anyway.

As far as I know, most web-hosts/providers do not even allow direct 
MySQL access from outside their domain anyway, probably only within 
their own localhost(webserver) via php, and not from any external IP 
address.

However, if anyone does figure out how to use an encrypted database 
password in PhpWiki's index.php, I'm sure such a modification would be 
welcome.

Carsten

Re: [Phpwiki-talk] Permissions for index.php -- hide MySQL password?

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

Reini Urban schrieb:
> You can setup any auth scheme, whatever you want.
> But I don't think that http digest auth has wide client support. 
> everybody still uses Basic, with the password md5'ed in the header. 

oops, base64 of course.
-- 
Reini Urban

Re: [Phpwiki-talk] 1.3.7 released

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

Ye are welcome :)
10xz for the handy wiki... I'm going to test the new one now :-]

On Tuesday 23 December 2003 02:08, Steve Wainstead wrote:
> Thanks for the catches, everyone. New tarball on the site. This one,
> hopefully, is correct.
>
> I'm going home and taking some cold medicine now. This just hasn't been
> my week.
> ~swain
>
> On Dec 22, 2003, at 4:45 AM, Doncho N. Gunchev wrote:
> >   Wow... what's that?
> > phpwiki-1.3.6.tar.gz	1454 kb	Nov 16, 2003 21:20
...

-- 
Regards,
  Doncho N. Gunchev

Re: [Phpwiki-talk] Permissions for index.php -- hide MySQL password?

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

Sergio Trejo schrieb:
> I saw someone also post recently about using a .htaccess file 
> (presumably using Basic Authentication) which is really perhaps not a 
> good idea considering the password gets sent in the clear. Also noticed 
> the suggestion to use mod_auth_mysql. But getting back to the idea of 
> authenticating for access to a PHPWiki instance via the context of 
> .htaccess (or directory context in httpd.conf, etc.) ... what about the 
> possibility of using Digest Authentication (mod_auth_digest)? I know its 
> still considered experimental by Apache since the server doesn't check 
> the nonce reflected by the browser (and for a while there was a problem 
> with browsers not supporting MD5 digest authentication), but most modern 
> day browsers I think are now supporting digest access. Perhaps its 
> overkill to use both digest (such as at the Wiki's root directory such 
> that .htaccess files are not constantly being parsed by httpd for every 
> request in subrealms)? Just an idea perhaps worth contemplating.

You can setup any auth scheme, whatever you want.
But I don't think that http digest auth has wide client support. 
everybody still uses Basic, with the password md5'ed in the header. but 
you need a sniffer to get at these.

What I wrote about .htaccess auth, is that we will include a file-style 
auth scheme, which can be used optionally, similar to basic http auth.
That means, you don't get the browsers popup with user/password, instead 
you can login at the normal phpwiki login page and authenticate against 
any htaccess style file. (username:encrypted_password\n...)
such files are very simple to maintain and easier to setup, than http 
auth, which needs support by the local system administrator.
-- 
Reini Urban
http://xarch.tu-graz.ac.at/home/rurban/

Re: [Phpwiki-talk] Newbie question

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

Sergio Trejo schrieb:
> Hmmm....  I wonder if Subversion < http://subversion.tigris.org/ > is 
> ready for prime time yet and perhaps could be used for PHPWiki?

please not!
sf.net supports cvs, not subversion.
cvs is mature and stable and has some known limitations for young 
projects (frequent directory renaming e.g.)

subversion (as well as mcvs and more) has more features than cvs, but is 
very fresh, and is NOT supported by sf.net and the developers are not 
used to it.

I would prefer mcvs for private toy projects instead of subversion, 
since it uses the same cvs server database, it just adds some hash stuff 
on the client side. but you need clisp, which is a pain to compile on 
certain systems.
-- 
Reini Urban
http://xarch.tu-graz.ac.at/home/rurban/

RE: [Phpwiki-talk] Permissions for index.php -- hide MySQL password?

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

>From: Robert Dodier <rob...@ya...>
>To: php...@li...
>Subject: [Phpwiki-talk] Permissions for index.php -- hide MySQL password?
>Date: Mon, 22 Dec 2003 08:55:43 -0800 (PST)
>
>Hello everyone,
>
>I've installed PhpWiki on my project website at SourceForge
>and I have to say, it is really terrific! Thanks to the
>development team for a job well done.
>
>I have a question about the MySQL password. I see that I
>can put the admin password in index.php in encrypted form --
>that's great. But can I also encrypt the MySQL password?
>
>It seems like a security problem, since index.php must be
>readable by the web server; it might be possible for anyone
>with a login on the project servers to read the MySQL password.
>
>I've read through archives for PHP, MySQL, and PhpWiki, but
>there doesn't seem to be a definitive solution. It seems the
>standard operating procedure is to ask the SF sysadmins to
>"chgrp nobody index.php". Is there another way?
>
>It may be not so much of an issue, since by design, a wiki
>is pretty much wide open for abuse anyway. But it seems
>like the MySQL-password-in-a-script problem must be
>generic to many SF projects that use MySQL.
>
>How was this problem solved for the PhpWiki project
>demonstration wiki?
>
>Thanks for any light you can shed on this issue --
>
>Robert Dodier

I saw someone also post recently about using a .htaccess file (presumably 
using Basic Authentication) which is really perhaps not a good idea 
considering the password gets sent in the clear. Also noticed the suggestion 
to use mod_auth_mysql. But getting back to the idea of authenticating for 
access to a PHPWiki instance via the context of .htaccess (or directory 
context in httpd.conf, etc.) ... what about the possibility of using Digest 
Authentication (mod_auth_digest)? I know its still considered experimental 
by Apache since the server doesn't check the nonce reflected by the browser 
(and for a while there was a problem with browsers not supporting MD5 digest 
authentication), but most modern day browsers I think are now supporting 
digest access. Perhaps its overkill to use both digest (such as at the 
Wiki's root directory such that .htaccess files are not constantly being 
parsed by httpd for every request in subrealms)? Just an idea perhaps worth 
contemplating.

Peace on Earth,

Serj

_________________________________________________________________
Add photos to your messages with MSN 8. Get 2 months FREE*. 
http://join.msn.com/?page=features/featuredemail

Re: [Phpwiki-talk] Newbie question

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

>From: Steve Wainstead <sw...@pa...>
>To: russ <rl...@rl...>
>CC: php...@li...
>Subject: Re: [Phpwiki-talk] Newbie question
>Date: Sat, 20 Dec 2003 09:03:20 -0500
>
>Time and again, I turn to the Red Bean book, free and online:
>
>http://cvsbook.red-bean.com/cvsbook.html
>
>It's a great combination of tutorial and cookbook.
>~swain

Hmmm....  I wonder if Subversion < http://subversion.tigris.org/ > is ready 
for prime time yet and perhaps could be used for PHPWiki?

_________________________________________________________________
Tired of spam? Get advanced junk mail protection with MSN 8. 
http://join.msn.com/?page=features/junkmail

[Phpwiki-talk] Various Newbie Questions

[Alexandre E. <aen...@in...>]

Have only done a few things with phpWiki so far but am really impressed 
by it. It's this exact combination of simplicity, convenience, and 
flexibility we so rarely find in commercial programs and make 
open-source so cool.

BTW, I use phpWiki 1.3.6 on an Apple iBook Mac OS X 10.2.8, Apache 
1.3.26, PHP 4.3.0, and MySQL 4.0.14. I'm guessing the most relevant 
part is that I'm running through SQL..

Now, a few questions, as a newbie. Didn't find answers in the obvious 
doc yet. Feel free to respond privately. Sorry if some are too obvious. 
They sound pretty much like feature requests but I don't know if these 
features are already available or not.

So, is there a (simple) way to...

...change a page name/title?

...change a username?

...have a small phpWiki archive hosted for free, somewhere?

...wikify (phpWiki-compatible) external pages from HTML?

...send a specific page to XML and/or zip?

...do a site-wide find and replace?

...make plugin output editable?

...have a "question mark" button default to "?action=edit" instead of 
create?

...add "BackLinks" buttons in the WantedPages?

...quickly make "journal" entries, linked simply by the date?



Sorry if that's a lot. The first two (changing a page name/title and 
changing a username) are the  most important.

Thanks!

Alexandre Enkerli
Ph.D. Candidate
Department of Folklore and Ethnomusicology
Indiana University

Re: [Phpwiki-talk] 1.3.7 released

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

Thanks for the catches, everyone. New tarball on the site. This one, 
hopefully, is correct.

I'm going home and taking some cold medicine now. This just hasn't been 
my week.
~swain

On Dec 22, 2003, at 4:45 AM, Doncho N. Gunchev wrote:
>   Wow... what's that?
> phpwiki-1.3.6.tar.gz	1454 kb	Nov 16, 2003 21:20
> phpwiki-1.3.7.tgz	8700 kb	Dec 21, 2003 14:28
>   such a big archive size change?
> (Apache/2.0.45 (Unix) Server at unc.dl.sourceforge.net Port 80)
> --- cut ---
> tar tvzf phpwiki-1.3.7.tgz
> drwxrwxr-x swain/swain       0 2003-12-22 00:30:35 ./
> -rw-rw-r-- swain/swain   33430 2003-12-22 00:30:06 ./list
> -rw-rw-r-- swain/swain   33437 2003-12-22 00:25:04 ./list~
> drwxrwxr-x swain/swain       0 2003-12-22 00:22:05 ./phpwiki-1.3.7/
> drwxrwxr-x swain/swain       0 2003-12-22 00:21:57 ./phpwiki-1.3.7/CVS/
> ...
> -rw-rw-r-- swain/swain    1555 2003-02-28 01:55:52 
> ./phpwiki-1.3.7/themes/default/templates/wikiblog.
> -rw-rw-r-- swain/swain      45 2003-12-22 00:30:18 
> ./phpwiki-1.3.6.tar.gz
> -rw-rw-r-- swain/swain 1409024 2003-12-22 00:30:42 
> ./phpwiki.1.3.7.tar.gz
> drwxrwxr-x swain/swain       0 2003-12-22 00:22:05 ./phpwiki-1.3.7/
> drwxrwxr-x swain/swain       0 2003-12-22 00:21:57 ./phpwiki-1.3.7/CVS/
> -rw-rw-r-- swain/swain      55 2003-12-22 00:21:56 
> ./phpwiki-1.3.7/CVS/Root
> ...
> tar tzvf phpwiki.1.3.7.tar.gz # (the one that was inside)
> ...
> -rw-rw-r-- swain/swain     249 2003-03-05 23:38:15 
> ./phpwiki-1.3.7/themes/default/templates/body.tmpl
> -rw-rw-r-- swain/swain   36169 2003-01-12 19:54:09 
> ./phpwiki-1.3.7/themes/default/templates/MAP.pdf
>
> gzip: stdin: unexpected end of file
> tar: Unexpected EOF in archive
> tar: Error is not recoverable: exiting now
> --- cut ---
>
> btw: the link to 1.3.7 on the homepage is broken, there is no
> phpwiki-1.3.7.tar.gz, only phpwiki-1.3.7.tgz. The archive seems
> quite broken and so on...
>
> -- 
> Regards,
>   Doncho N. Gunchev
>

Re: [Phpwiki-talk] Permissions for index.php -- hide MySQL password?

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

Robert Dodier schrieb:
> I have a question about the MySQL password. I see that I
> can put the admin password in index.php in encrypted form --
> that's great. But can I also encrypt the MySQL password?

that's unfortunately a mysql architectural problem. their fault.
every perl and php programmer must deal with that solution somehow.

one can read in a local file with the password, which is not in
the web docroot, but it must be passed cleartext to the database.
since php's are normally associated with the php engine, and no one 
local access to the webserver (shell or ftp account), it's quite secure.

for important mysql passwords in php apps, one stores the passwords in a 
secure location. but it must be readable by the apache user, so anyone 
with problematic/erratic php script (there are thousands, I worked for a 
very large ISP) will be able to read it, if he knows where.

> It seems like a security problem, since index.php must be
> readable by the web server; it might be possible for anyone
> with a login on the project servers to read the MySQL password.
> 
> I've read through archives for PHP, MySQL, and PhpWiki, but
> there doesn't seem to be a definitive solution. It seems the
> standard operating procedure is to ask the SF sysadmins to
> "chgrp nobody index.php". Is there another way?
> 
> It may be not so much of an issue, since by design, a wiki
> is pretty much wide open for abuse anyway. But it seems
> like the MySQL-password-in-a-script problem must be 
> generic to many SF projects that use MySQL.

yes, see above.

> How was this problem solved for the PhpWiki project
> demonstration wiki?

password stored plaintext in index.php.
no one without shell account is able to see the content of index.php.
-- 
Reini Urban
http://xarch.tu-graz.ac.at/home/rurban/

[Phpwiki-talk] Permissions for index.php -- hide MySQL password?

[Robert D. <rob...@ya...>]

Hello everyone,

I've installed PhpWiki on my project website at SourceForge
and I have to say, it is really terrific! Thanks to the 
development team for a job well done. 

I have a question about the MySQL password. I see that I
can put the admin password in index.php in encrypted form --
that's great. But can I also encrypt the MySQL password?

It seems like a security problem, since index.php must be
readable by the web server; it might be possible for anyone
with a login on the project servers to read the MySQL password.

I've read through archives for PHP, MySQL, and PhpWiki, but
there doesn't seem to be a definitive solution. It seems the
standard operating procedure is to ask the SF sysadmins to
"chgrp nobody index.php". Is there another way?

It may be not so much of an issue, since by design, a wiki
is pretty much wide open for abuse anyway. But it seems
like the MySQL-password-in-a-script problem must be 
generic to many SF projects that use MySQL.

How was this problem solved for the PhpWiki project
demonstration wiki?

Thanks for any light you can shed on this issue --

Robert Dodier

__________________________________
Do you Yahoo!?
New Yahoo! Photos - easier uploading and sharing.
http://photos.yahoo.com/

Re: [Phpwiki-talk] 1.3.7 released

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

Bah. I did it  again! :-P

~swain

On Dec 21, 2003, at 8:03 PM, Bishop wrote:

> Steve said:
>> This release contains lots of bugfixes and optimizations by Carsten.
>
> But CVS (index.php) said:
>> define ('PHPWIKI_VERSION', '1.3.7pre');
>
> And I wondered:
> Are ya teasing, Steve, or has cvs just not been committed?
>
> My CVS RPM thingy only triggers on the SF cvs, and that file's not been
> altered in 16 days.
>
>  - bish
>

Re: [Phpwiki-talk] 1.3.7 released

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

On Sunday, December 21, 2003, at 08:03  pm, Bishop wrote:

> Steve said:
>> This release contains lots of bugfixes and optimizations by Carsten.
>
> But CVS (index.php) said:
>> define ('PHPWIKI_VERSION', '1.3.7pre');
>
> And I wondered:
> Are ya teasing, Steve, or has cvs just not been committed?
>
> My CVS RPM thingy only triggers on the SF cvs, and that file's not been
> altered in 16 days.
>
>  - bish

Whups, you're right. Looks like we forgot to change that line in 
index.php to:
define ('PHPWIKI_VERSION', '1.3.7');
... before tarring up the release. I'll upload a replacement archive to 
SF in the next few days if Steve doesn't beat me to it. :)

I checked quickly within the tar file and all the recent CVS commits 
are there, so I'm pretty sure it is just the version number that was 
left behind.

Later,
Carsten