phpwiki-talk

Re: [Phpwiki-talk] RE: phpwiki

[Aredridel <are...@nb...>]

> 
> We don't do anything Apache-dependent as far as I recall, unless server
> variables have different names. If you try it let us know.
> 
> ~swain

The server variables are the same -- that's a standard under the CGI 1.1
spec.

Ari

[Phpwiki-talk] RE: phpwiki

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

We don't do anything Apache-dependent as far as I recall, unless server
variables have different names. If you try it let us know.

~swain

On Thu, 8 Feb 2001, Pe, David wrote:

> Using IIS shouldn't be a problem ..right ?
> 
> -----Original Message-----
> From: Steve Wainstead [mailto:sw...@wc...]
> Sent: Thursday, February 08, 2001 10:49 AM
> To: Pe, David
> Cc: php...@li...
> Subject: Re: phpwiki
> 
> 
> On Thu, 8 Feb 2001, Pe, David wrote:
> 
> > is there any plan of migrating phpwiki to NT ?
> > 
> 
> We've had reports of it running on Windows, but I don't recall if NT has
> ever been mentioned. I think if NT supports Apache and PHP, PhpWiki has a
> good chance of working on it. 
> 
> ~swain
> 
> ...............................ooo0000ooo.................................
>    Hear FM quality freeform radio through the Internet: http://wcsb.org/
>                      home page: www.wcsb.org/~swain 
> 

...............................ooo0000ooo..................................
   Hear FM quality freeform radio through the Internet: http://wcsb.org/
                     home page: www.wcsb.org/~swain 

[Phpwiki-talk] RE: phpwiki

[Pe, D. <Dav...@gs...>]

Using IIS shouldn't be a problem ..right ?

-----Original Message-----
From: Steve Wainstead [mailto:sw...@wc...]
Sent: Thursday, February 08, 2001 10:49 AM
To: Pe, David
Cc: php...@li...
Subject: Re: phpwiki


On Thu, 8 Feb 2001, Pe, David wrote:

> is there any plan of migrating phpwiki to NT ?
> 

We've had reports of it running on Windows, but I don't recall if NT has
ever been mentioned. I think if NT supports Apache and PHP, PhpWiki has a
good chance of working on it. 

~swain

...............................ooo0000ooo.................................
   Hear FM quality freeform radio through the Internet: http://wcsb.org/
                     home page: www.wcsb.org/~swain 

[Phpwiki-talk] New stable branch in CVS.

[Jeff D. <da...@da...>]

There is a new tagged branch in the CVS named 'release-1_2-branch'.
It's purpose it's to keep track of bug-fixes/changes in the 1.2.x
branch of phpwiki.

I've propagated all the bug-fixes currently in the main CVS branch
into the new branch.   From now on, if you make a bug-fix in the
main branch which is appropriate to the 1.2.x branch as well, please
commit your changes both places.

Here's a mini-howto on dealing with tagged branches:

To check-out the latest versions of the files within a tagged branch
do something like:

  cvs -du...@cv...:/cvsroot/phpwiki \
    co -r release-1_2-branch -d stable phpwiki

This will checkout the stable branch into the directory named 'stable'.

If you now 'cd' into 'stable', and run a 'cvs status', you will see
that the tag 'release-1_2-branch' is set as a "sticky tag" for each
of the files in the repository.

Now you can edit the files normally, and when you're happy with them,
commit them normally (using 'cvs commit [...]'.)   (The "sticky tag"
stuff causes the commit's to be checked in to the tagged branch,
rather than the MAIN branch.)

I find the following to be useful CVS references:
  http://cvsbook.red-bean.com/cvsbook.html -- a good tutorial
  http://www.loria.fr/~molli/cvs/doc/cvs_toc.html --- the CVS info file, online

Jeff

Re: [Phpwiki-talk] cron jobs

[<ph...@de...>]

On Thu, 8 Feb 2001 17:56:46 +0100, you wrote:
=> How about deleting the 10th version when inserting the 11th? No need to 
=> move this into a cronjob.

	Or [newbie idea # xxxx]: How about deleting the Nth
version, where N = $keep_level, to be defined in config.php? (and
$keep_level == 0 never deletes).


=> Btw, there is a simple hack if you are not allowed to execute cron jobs:
=> use a page that gets called at certain intervals. E.g. I monitor the 
=> availibilty of one of my sites with http://uptime.arsdigita.com/uptime/
=> Uptime requests a certain page about every 20 minutes. All you need to do 
=> is check the time and then perform your "cronjob" :o)

	Very nice. Is it generally dependable in your experience?

	Cheers,

	- Don

Re: [Phpwiki-talk] cron jobs

[Jeff D. <da...@da...>]

>How about deleting the 10th version when inserting the 11th? No need to 
>move this into a cronjob.

It may be that one would want to retain all old versions
to guard against malicious content vandalism by repetitive
changes.   In this case, there should be a manual method
to clear out old pages to be executed only when one
is (reasonably) sure that no such spam exists.

Both approaches (automatic vs manual deletion of old version)
are reasonable, depending on the context.

>E.g. I monitor the 
>availibilty of one of my sites with http://uptime.arsdigita.com/uptime/

Neato.  Thanks for the pointer.

Re: [Phpwiki-talk] cron jobs

[Arno H. <aho...@xm...>]

> If we find the need to move certain database tasks out of the realm of
> Web transactions and into crontabs, we should do this.

I assume that especially with email notofication (e.g. once a day), more=20
advanced demographics like http://senseis.xmp.net/?PagesByDistance etc.
a need for something like this arises.

> However there are needs arising like: a permanent archive might need
> periodic housekeeping, like deleting pages older than ten versions ago.

How about deleting the 10th version when inserting the 11th? No need to=20
move this into a cronjob.


> I think this will open some new possibilities to us.

I agree.

Btw, there is a simple hack if you are not allowed to execute cron jobs:
use a page that gets called at certain intervals. E.g. I monitor the=20
availibilty of one of my sites with http://uptime.arsdigita.com/uptime/
Uptime requests a certain page about every 20 minutes. All you need to do=
=20
is check the time and then perform your "cronjob" :o)

/Arno

Re: [Phpwiki-talk] solution to admin.php problem

[<ph...@de...>]

On Thu, 8 Feb 2001 10:02:42 +0100, you wrote:
=> Bottom line: there's no way to secure config.php on a shared server if the 
=> web server runs as nobody.
	<snip, move, cut, paste, etc>
=> Taken from their security.txt:
=> If you want to run Phorum on a shared server, you absolutely need to wrap
=> the scripts... unless, of course, your provider makes all of your scripts
=> run as your userid.  [...]

	It is a *GoodIdea* if the confidential user, password and
servername info etc are kept in a separate "include/require"
file, so that folks (such as me) who run Wiki under their user
permissions can then move the PASSWORD.INC or whatever totally
out from under the document root.  Also, if left under the
document root, one can use .htaccess to block pedestrian access
through the web server to specific files/types.

	Cheers,

	- Don 

Re: [Phpwiki-talk] cron jobs

[Jeff D. <da...@da...>]

>However there are needs arising like: a permanent archive might need
>periodic housekeeping, like deleting pages older than ten versions ago.
>This can be done with a cron script.


Here's my take on how this should be done (you've seen my philosophy
on this before when we introduced the zip-dump):

All these maintainance tasks should be done by normal CGI means.  Eg.

   admin.php?action=clean_archive&keep_versions=10

would perform what you suggest above.

Then, if you want to cronify it, you can do so on any computer.
Ie. on my home computer I can run:

 GET -Cuser:password http://where.ever/admin.php?action=clean_archive&...

I think using PHP as a standalone interpreter (other than for debugging
purposes) is a bad idea.

Some points:
  Cron is a unix-ism.
  Your method requires shell (and cron) access on the server.
  

[Phpwiki-talk] cron jobs

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

This week I figured out how to create the standalone PHP binary (just
compile it without a server option). I wrote a little test script that
read config.php and called the database to see if IsWikiPage() returned
the right value.

If we find the need to move certain database tasks out of the realm of Web
transactions and into crontabs, we should do this. I think it should be
viewed as an add-on the admin will have to take extra responsibility for;
in other words, PhpWiki should always work "out of the box" on a stock PHP
installation, and should not require cron jobs to function in the long
term.

However there are needs arising like: a permanent archive might need
periodic housekeeping, like deleting pages older than ten versions ago.
This can be done with a cron script.

We'd need simple instructions on setting this up (compile a PHP binary and
put it in /usr/local/bin/ for example), and a scripts directory for cron
jobs (maybe).

I think this will open some new possibilities to us.

~swain

...............................ooo0000ooo.................................
   Hear FM quality freeform radio through the Internet: http://wcsb.org/
                     home page: www.wcsb.org/~swain 

[Phpwiki-talk] Re: phpwiki

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

On Thu, 8 Feb 2001, Pe, David wrote:

> is there any plan of migrating phpwiki to NT ?
> 

We've had reports of it running on Windows, but I don't recall if NT has
ever been mentioned. I think if NT supports Apache and PHP, PhpWiki has a
good chance of working on it. 

~swain

...............................ooo0000ooo.................................
   Hear FM quality freeform radio through the Internet: http://wcsb.org/
                     home page: www.wcsb.org/~swain 

Re: [Phpwiki-talk] FootNotes, Tables, The end of PHP3, I'm still alive, etc...

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

On Wed, 7 Feb 2001, J C Lawrence wrote:
> 
> Best would be to remove all ? and & URL variables to make it easier
> for search engines to index public Wikis.

That's now on the task list and will be in the next stable version.

~swain

...............................ooo0000ooo.................................
   Hear FM quality freeform radio through the Internet: http://wcsb.org/
                     home page: www.wcsb.org/~swain 

Re: [Phpwiki-talk] FootNotes, Tables, The end of PHP3, I'm still alive, etc...

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

On Thu, 8 Feb 2001, Malcolm Ryan wrote:

> This could be done via the following (untested) change to admin.php:
> 
>    // set these to your preferences. For heaven's sake
>    // pick a good password!
>    $wikiadmin   = "malcolmr";
>    $adminkey = "BHZ";
>    $adminpasswd = "750c783e6ab0b503eaa86e310a5db73"; // Not the real value

Would this require the server to write to the file? That in itself is a
problem. We should probably move the login/passwd to a separate file, not
store it in config.php.

If we create our own passwd file via the server, it could be -rw-------
nobody nobody and that might be a minor gain in itself.

Good security is so hard.

~swain

...............................ooo0000ooo.................................
   Hear FM quality freeform radio through the Internet: http://wcsb.org/
                     home page: www.wcsb.org/~swain 

Re: [Phpwiki-talk] One more nit to pick?

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

On Wed, 7 Feb 2001, Jon =C5slund wrote:

> On Wed, Feb 07, 2001 at 11:31:43AM -0800, Jeff Dairiki wrote:
> > Does anyone actually put something nice in signature.png?
> > Can we get rid of it?
>=20
> Yes, please! I don't know why it exists. It's very confusing. A note

Because I wrote as exact a clone of the Portland Pattern Repository as
possible, and they have the signature image. In fact I simply copied all
the HTML from the PPR when I wrote version 1.0. That's why it's there.

I would think it's just a template change to get rid of it.

~swain

> saying thanks for editing followed by ------ should do it. Actually I
> don't like having the confirmation message on the same page as the
> edited page, although I realize this has benefits.

it saves the user another click/wait, so I think it's a good thing...
albeit a little confusing the first time.

~swain

=2E..............................ooo0000ooo................................=
=2E
   Hear FM quality freeform radio through the Internet: http://wcsb.org/
                     home page: www.wcsb.org/~swain=20

Re: [Phpwiki-talk] Footnotes

[Jeff D. <da...@da...>]

In message <007401c09194$2fc438f0$0201a8c0@home>,"Thomas Kalka" writes:
>What do you think about this:
>
>a [<number>] is a footnote if it appears  somewhere in the text, except for
>beeing the first thing in
>a line, where it becomes the definition of the footnote ?
>Then you could add footnote-definititions where you like and they could all
>be displayed at the bottom.

I like this idea.  (In fact I thought of the same thing last night while
lying in bed.)

>Another feature about footnotes i thinks its worth thinking about is to
>include no-number footnotes.
>In that case you wouldnt have to know about the actual count of footnotes to
>introduce a new one.
>It would be also nice, if footnotes would be automatically numbered.

How does one maintain the correct correspondence between reference and
footnote?   Give them names (which are then automatically converted
to numbers)?

Jeff

Re: [Phpwiki-talk] solution to admin.php problem

[Arno H. <aho...@xm...>]

> Don't fix admin.php until you found a fix for config.php -- gives a fal=
se
> sense of security.

Following up on my own email: I remembered that phorum has quite a good=20
description of how to securely install their app.

Taken from their security.txt:

If you want to run Phorum on a shared server, you absolutely need to wrap
the scripts... unless, of course, your provider makes all of your scripts
run as your userid.  [...]

What "wrapping" means is to have the .php scripts executed under your
userid instead of the web server's default "nobody".  This is because,
no matter how well you hide the script (e.g. in a directory that's chmod
711), any user on your server could create a script that is run as
"nobody" by the web server which could [read] your config files.
This is especially bad on a shared server because the config file could
also give the user access to your database passwords which, in many cases=
,
will let them mess with more than just your Phorum tables.

On a shared server, your provider should be "providing" you with a
secure and PHP-friendly script wrapper.  If they are not, you should
either not run scripts like Phorum that read/write files that include
passwords or you should move to another provider.


Bottom line: there's no way to secure config.php on a shared server if th=
e=20
web server runs as nobody.

/Arno

Re: [Phpwiki-talk] solution to admin.php problem

[Arno H. <aho...@xm...>]

>   On machines where httpd runs as 'nobody' (or similar), admin.php must
>   be world readable.  This allows anyone with an account on the machine
>   access to the username and password in admin.php (same problem for
>   the sql password in config.inc).

Solution for admin.php: stored an md5() hash and not the user and/or=20
password itself.

I can't think of a solution for config.php.
This is actually much more serious then the admin password.

Don't fix admin.php until you found a fix for config.php -- gives a false=
=20
sense of security.

/Arno

Re: [Phpwiki-talk] FootNotes, Tables, The end of PHP3, I'm still alive, etc...

[J C L. <cl...@ka...>]

On Wed, 07 Feb 2001 11:19:29 -0800 
Jeff Dairiki <da...@da...> wrote:

> If there's a push for keeping the mark-up simple, why footnotes?
> Carrying the references around as page meta-data has been a
> pain-in-the-database-code.  Why not just get rid of it all?

Wikis are cominginto increasing use as engineering and coroporate
documentation systems (usually with various sorts of access and
versioning control).  Footnotes are almost a requirement for
engineering Wikis -- especially for technical review or analysis
documents.

> User ID's / Logins:

>   I think they're a good idea.  (Useful for some sites, at least.)

SourceForge has a fairly pleasant bit of PHP code to handle user
registrations with email confirmations etc.  I've been extending it
here to support PHPLib-style templates (I'm actually using a
superset of PHPLib's template class) and its pretty clean code.
	
>   On a related note, there's a bug:

>   Currently 'index.php?zip=all' will get you to the wiki page
> named 'zip=all'.  This is probably a bad idea ('zip=all' is an
> allowable page name, but it should have to be url-encoded.)  I'll
> fix this unless you object.

Best would be to remove all ? and & URL variables to make it easier
for search engines to index public Wikis.

-- 
J C Lawrence                                       cl...@ka...
---------(*)                          http://www.kanga.nu/~claw/
--=| A man is as sane as he is dangerous to his environment |=--

Re: [Phpwiki-talk] Vote!

[J C L. <cl...@ka...>]

On Wed, 07 Feb 2001 11:01:55 -0800 
phpwiki  <ph...@de...> wrote:

> Also I'd prefer time/attention be spent on those things that make
> the wiki UI so great - it's simplicity and absolute immediate
> hyper-link abilities. Perhaps faster/better cross-link lists
> including that great little "related" feature.

Explicit support for SeeAlso: is a Good Thing.

-- 
J C Lawrence                                       cl...@ka...
---------(*)                          http://www.kanga.nu/~claw/
--=| A man is as sane as he is dangerous to his environment |=--

Re: [Phpwiki-talk] tables & footnotes

[J C L. <cl...@ka...>]

On Wed, 7 Feb 2001 18:32:07 +0100 
Arno Hollosi <aho...@xm...> wrote:

> In order to be able to reference footnotes more than once
> (assuming the last [x] is always the footnote itself) we could do
> the following: currently all tokens are replaced by $replacements
> at the end of the line.  Why not hold of this replacement until
> all lines are done, and then replace them in one big swoosh. Then
> $replacements of previous lines could still be redefined. The
> other solution is to provide hooks for post- & pre-processing of
> the entire $content.

The last [x] strting in column zero is the footnote.  Everything
else is a link to its anchor

-- 
J C Lawrence                                       cl...@ka...
---------(*)                          http://www.kanga.nu/~claw/
--=| A man is as sane as he is dangerous to his environment |=--

Re: [Phpwiki-talk] Vote!

[J C L. <cl...@ka...>]

On Wed, 7 Feb 2001 13:48:50 -0500 (EST) 
Steve Wainstead <sw...@wc...> wrote:

> I want a straw poll here on the list. All in favor of simple HMLT
> table syntax, or not, speak your piece now.

I'm in favour of somethine like TWiki's | format |.

-- 
J C Lawrence                                       cl...@ka...
---------(*)                          http://www.kanga.nu/~claw/
--=| A man is as sane as he is dangerous to his environment |=--

Re: [Phpwiki-talk] FootNotes, Tables, The end of PHP3, I'm still alive, etc...

[Malcolm R. <mal...@cs...>]

> 	
> Security:
> 
>   On machines where httpd runs as 'nobody' (or similar), admin.php must
>   be world readable.  This allows anyone with an account on the machine
>   access to the username and password in admin.php (same problem for
>   the sql password in config.inc).
> 
>   Is there a solution?

Well, we could do what the UNIX passwd system does, and compute and store
a hash of the password (one-way encrypted) instead of the plain-text. 

This could be done via the following (untested) change to admin.php:

   // set these to your preferences. For heaven's sake
   // pick a good password!
   $wikiadmin   = "malcolmr";
   $adminkey = "BHZ";
   $adminpasswd = "750c783e6ab0b503eaa86e310a5db73"; // Not the real value

   // Do not tolerate sloppy systems administration
   if (empty($wikiadmin) || empty($adminpasswd)) {
      echo "Set the administrator account and password first.\n";
      exit;
   }

   // from the manual, Chapter 16
   if (($PHP_AUTH_USER != $wikiadmin  )  ||
       (bin2hex(mhash(MHASH_MD5, $PHP_AUTH_PW, $adminkey)) != $adminpasswd)) {
      Header("WWW-Authenticate: Basic realm=\"PhpWiki\"");
      Header("HTTP/1.0 401 Unauthorized");
      echo gettext ("You entered an invalid login or password.");
      exit;
   }

Unfortunately, I can't test this, because none of the PHP installations 
available to me have mhash installed. 

Generating an encrypted password would require a separate program, but 
is easily done.

This is still vulnerable to dictionary attacks, but if the password is 
well chosen, it should be fairly secure. 

Malcolm

-- 
Malcolm Ryan - mal...@cs... - http://www.cse.unsw.edu.au/~malcolmr/
  AI Dept, CSE, UNSW, Australia, Phone: +61 2 9385-6906 Fax: +61 2 9385-1814

           "He causes his sun to rise on the evil and the good,
           and sends rain on the righteous and the unrighteous." - Matt 5:45

[Phpwiki-talk] Vote!

[Thomas K. <th...@co...>]

tables with embedded html: nooo
simple table markup : yes

could look like=20

| a | b | c | is  |a              |b                |c                  =
|
|>a |^b |<c | is  |              a|       b         |c                  =
|
||a | c |     is  |a                                |c                  =
|

Thomas

[Phpwiki-talk] Footnotes

[Thomas K. <th...@co...>]

What do you think about this:

a [<number>] is a footnote if it appears  somewhere in the text, except for
beeing the first thing in
a line, where it becomes the definition of the footnote ?
Then you could add footnote-definititions where you like and they could all
be displayed at the bottom.


Another feature about footnotes i thinks its worth thinking about is to
include no-number footnotes.
In that case you wouldnt have to know about the actual count of footnotes to
introduce a new one.
It would be also nice, if footnotes would be automatically numbered.

Thomas

Re: [Phpwiki-talk] Re: Stable branch, CVS details (was: FootNotes, Tables, The end of PHP3...)

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

On Wed, 7 Feb 2001, Jeff Dairiki wrote:

> Perhaps we should create a 'release-1_2-branch' tag in the CVS, so that
> when a developer (like myself) fixes a bug (like the diff hang bug) he
> can/should fix it in both the development branch and the stable branch.

You are correct, sir... we'll tag it as a branch.

~swain

...............................ooo0000ooo.................................
   Hear FM quality freeform radio through the Internet: http://wcsb.org/
                     home page: www.wcsb.org/~swain