phpwiki-talk

Re: [Phpwiki-talk] Discourage comment spammers with Google's 'rel=nofollow'

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

On Thu, January 20, 2005 11:41, Dan Frankowski said:
> PhpWiki should do this for http://... URLs in an installation.
>
> http://www.google.com/googleblog/2005/01/preventing-comment-spam.html
>
> Clearly not before release, since that should go out.
>
> I will file this as a feature request as well.

I think that a more nuanced approach is required here.

First it should be optional, particularly in a wiki secured as I outlined
earlier this week.  In the wiki I help maintain, many of the external
links relate to the whole purpose of the wiki.  Allowing Google and other
search engines to record these links improves the body of work.

Secondly, where is is turned on, perhaps there should be a plugin that
allows the flag to be turned off on a link by link basis.  Obviously this
will require that the plugin is secured against abuse...

regards,
Charles

[Phpwiki-talk] Discourage comment spammers with Google's "rel=nofollow"

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

PhpWiki should do this for http://... URLs in an installation.

http://www.google.com/googleblog/2005/01/preventing-comment-spam.html

Clearly not before release, since that should go out.

I will file this as a feature request as well.

Dan

Re: [Phpwiki-talk] confused about releases and their dates

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

On Thu, January 20, 2005 9:35, Stan Berka said:
> I'm just looking at the table of phpwiki releases on projects main SF's
> page.  It suggests that "1.2 (stable)" is from Jan 7, 2005 while the
> "1.3 (current)" is from May 2004.  How come?

The 1.2 stable stream has had some cleanup and security fixes recently.
The 1.3 development stream was under heavy development and is now (as far
as I can tell) in stabilisation / bug fix mode with a view to release
1.3.11 soonish. After that there may be one or more development stream
releases, leading to a new stable 1.4 release.

regards,
Charles

[Phpwiki-talk] confused about releases and their dates

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

Hi,
I'm just looking at the table of phpwiki releases on projects main SF's 
page.  It suggests that "1.2 (stable)" is from Jan 7, 2005 while the 
"1.3 (current)" is from May 2004.  How come?

Stan Berka

RE: [Phpwiki-talk] user password help request

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

If you search the archives, I posted a draft of how to do this on Monday
ago, with a subject line of
RFC: HOW TO alternate security setups in PhpWiki

In some of the replies to this, additional useful information was released

Regards,
Charles

-----Original Message-----
From: Joel Sherrill <jo...@OA...> [mailto:joe...@OA...] 
Sent: 20 January 2005 03:33
To: php...@li...
Subject: [Phpwiki-talk] user password help request

Hi,

I let this slide and now it seems to be a serious problem
for us.  We are getting automated spam added to our Wiki front page.
I desperately need to get user authentication working on our
Wiki And it appears that I must not be getting something right
since it seems to work for others.

We are using MySQL as the backend and I don't really care which
authentication scheme we use.  This is a public Wiki so there is
no set of local users to check against.  I would like users to be
able to change their passwords.

Could someone kindly drag me through or send me a config.ini that works
for them?  I have no idea what I am not doing right.  I have tried
this on multiple occassions and not managed to get it right.

Sorry to be a pest but I am horribly confused and need it working
now.

-- 
Joel Sherrill, Ph.D.             Director of Research & Development
jo...@OA...                 On-Line Applications Research
Ask me about RTEMS: a free RTOS  Huntsville AL 35805
    Support Available             (256) 722-9985



-------------------------------------------------------
This SF.Net email is sponsored by: IntelliVIEW -- Interactive Reporting
Tool for open source databases. Create drag-&-drop reports. Save time
by over 75%! Publish reports on the web. Export to DOC, XLS, RTF, etc.
Download a FREE copy at http://www.intelliview.com/go/osdn_nl
_______________________________________________
Phpwiki-talk mailing list
Php...@li...
https://lists.sourceforge.net/lists/listinfo/phpwiki-talk

[Phpwiki-talk] Longer Term Spam Solution

[Russ M. <rlm...@gm...>]

http://www.google.com/googleblog/2005/01/preventing-comment-spam.html

-- 

Russ Miller
rl...@rl...
216.939.0147 /home
216.798.0264 /cell

[Phpwiki-talk] user password help request

[Joel S. <jo...@OA...>]

Hi,

I let this slide and now it seems to be a serious problem
for us.  We are getting automated spam added to our Wiki front page.
I desperately need to get user authentication working on our
Wiki And it appears that I must not be getting something right
since it seems to work for others.

We are using MySQL as the backend and I don't really care which
authentication scheme we use.  This is a public Wiki so there is
no set of local users to check against.  I would like users to be
able to change their passwords.

Could someone kindly drag me through or send me a config.ini that works
for them?  I have no idea what I am not doing right.  I have tried
this on multiple occassions and not managed to get it right.

Sorry to be a pest but I am horribly confused and need it working
now.

-- 
Joel Sherrill, Ph.D.             Director of Research & Development
jo...@OA...                 On-Line Applications Research
Ask me about RTEMS: a free RTOS  Huntsville AL 35805
    Support Available             (256) 722-9985

Re: [Phpwiki-talk] Showing RecentChanges as part of a regular PHP page

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

Le 11 janv. 05, =E0 13:44, James Grimwood a =E9crit :

> Hello
>
> I've got PHPWiki running on my website. It's accessable by clicking on
> a link on my website's main page.
>
> Is there a way I can grab the contents of the RecentChanges in my wiki
> and show that on my main page too? Just as straight text with links,
> not as a browser sidepanel or embedded in a frame? What I'm trying to
> make is a little sidepanel in my website's main page that shows what's
> recently changed in my wiki, in a similar way to SourceForge's "most
> active" panel on their main page.
>
> I don't mind poking around in the code and manually constructing glue
> to call PHPWiki functions, but a few pointers about where to start
> would be nice :-)
>

Just parse the RSS feed from de recentchanges page ... you can use my=20
RssParser.php lib (phpwiki/lib/RssParser.php) to do the task ...
It's a very simple rss lib but does the job ...
Have a look at the RssFeed plugin to see how to use it.
--
Arnaud Fontaine
CRAO
Jabber: sh...@ra...

Re: [Phpwiki-talk] Re: RFC: allow "wiki" to specify location of config.ini

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

Heu .....

Why don't you add a .cvsignore file in co,fig/ directory ?
Just put
config.ini

in it, and cvs will ignore this file ...

RTFM ;)

Le 18 janv. 05, =E0 23:08, Matthew Palmer a =E9crit :

> On Tue, Jan 18, 2005 at 07:53:41PM +0800, Charles Corrigan wrote:
>> a) having to remember to copy config.ini into the CVS controlled=20
>> directory
>> each time I get a fresh version (Eclipse deletes my private version =
of
>> config.ini when I request a refresh from CVS
>
> Sounds like you need to teach eclipse not to be so brain-fuckingly=20
> stupid.
> That really is idiotic behaviour -- people keep all sorts of crap =
lying
> around in their CVS working copies.  Blowing it all away every time=20
> you run
> update would get real old, real fast.
>
>> b) when I get CVS-write access, I will not accidentally checkin my=20
>> private
>> version of config.ini with passwords
>
> So don't cvs add config/config.ini.  That's a fairly long and specific
> string of random characters for your cat to produce while walking on=20=

> your
> keyboard.
>
> - Matt
>
--
Arnaud Fontaine
CRAO
Jabber: sh...@ra...

[Phpwiki-talk] Re: RFC: allow "wiki" to specify location of config.ini

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

On Tue, Jan 18, 2005 at 07:53:41PM +0800, Charles Corrigan wrote:
> a) having to remember to copy config.ini into the CVS controlled directory
> each time I get a fresh version (Eclipse deletes my private version of
> config.ini when I request a refresh from CVS

Sounds like you need to teach eclipse not to be so brain-fuckingly stupid.=
=20
That really is idiotic behaviour -- people keep all sorts of crap lying
around in their CVS working copies.  Blowing it all away every time you run
update would get real old, real fast.

> b) when I get CVS-write access, I will not accidentally checkin my private
> version of config.ini with passwords

So don't cvs add config/config.ini.  That's a fairly long and specific
string of random characters for your cat to produce while walking on your
keyboard.

- Matt

Re: [Phpwiki-talk] RFC: allow "wiki" to specify location of config.ini

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

Charles Corrigan schrieb:
> I understand and agree with why config.ini is not in CVS.  However it does
> cause minor issues for me - when I request a refresh of phpwiki from cvs,
> Eclipse wipes all changed files and other files not in CVS i.e. config.ini
> 
> Anyway, rather than discussing my reasons to want this change - what about
> the technical merits of the change itself?

Why should we add another config var for the config.ini name?
The only reason I see is not to confuse some broken, automated webpage 
updates, e.g. via rsync or ftp.
But with this scenerio, which ignores CVS settings such as Eclipse 
obviously does, I would recommend another safe place for this config.ini 
in question. Somewhere else, so that it will not get overwritten.

IniConfig("/etc/phpwiki.ini"); // as in debian e.g.

Or better fix the wrong app. rsync understand exclude files and lists, 
with ftp it's more difficult, I didn't have a look at Eclipse CVS 
integration so far. Looks very broken to me, not to update, but to get 
fresh new entries all the time. Just to get rid of C - cvs conflicts - 
there are better methods than to delete all existing files.
cvs up -C is the simpliest of all. We use a better method on 
phpwiki.sf.net to do not-conflicting cvs updates.

rurban@sc8-pr-shell1:~/bin$ cat demoup
#!/bin/sh
cd ~/demo

cvs -n up 2>&1 |grep "^C " | cut -c3- > ~/cvsup.lst
for f in $(cat  ~/cvsup.lst); do
   mv $f $f.tmp
   cvs up -C $f 2>&1 | tee -a cvsup.log
done
cvs up 2>&1 | tee -a cvsup.log

You might want to discuss that with the eclipse folks. They will see the 
technical benefits.

> -----Original Message-----
> From: Reini Urban [mailto:ru...@x-...] 
> Sent: 18 January 2005 21:44
> To: php...@li...
> Subject: Re: [Phpwiki-talk] RFC: allow "wiki" to specify location of
> config.ini
> 
> Charles Corrigan schrieb:
>>I would like the wiki file to specify the location of config.ini.  This
>>would allow me to use the clean versions of PhpWiki from CVS without
>>a) having to remember to copy config.ini into the CVS controlled directory
>>each time I get a fresh version (Eclipse deletes my private version of
>>config.ini when I request a refresh from CVS
> 
> config/config.ini is NOT in CVS. On purpose!
> 
>>b) when I get CVS-write access, I will not accidentally checkin my private
>>version of config.ini with passwords
> 
> So don't cvs add config/config.ini
> You can safely commit, cvs will touch only files which are in the 
> CVS/Entries file. config/config.ini is not.
-- 
Reini Urban
http://xarch.tu-graz.ac.at/home/rurban/

[Phpwiki-talk] phpwiki archive page not created.

[donnie j. <don...@gm...>]

Hello,

I am having some problems with phpwiki not creating
archive pages, which also doesn't allow for me to see the "diff"
of any pages...

I have checked the permissions of the "archive" directory, and
it is owned by www:www with 0777 permissions.

I am not sure what else could be preventing the archive
pages from being created...Any help would be great.

Thank you.
__
Donnie

Re: [Phpwiki-talk] RFC: allow "wiki" to specify location of config.ini

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

Charles Corrigan schrieb:
> I would like the wiki file to specify the location of config.ini.  This
> would allow me to use the clean versions of PhpWiki from CVS without
> a) having to remember to copy config.ini into the CVS controlled directory
> each time I get a fresh version (Eclipse deletes my private version of
> config.ini when I request a refresh from CVS

config/config.ini is NOT in CVS. On purpose!

> b) when I get CVS-write access, I will not accidentally checkin my private
> version of config.ini with passwords

So don't cvs add config/config.ini
You can safely commit, cvs will touch only files which are in the 
CVS/Entries file. config/config.ini is not.
-- 
Reini Urban
http://xarch.tu-graz.ac.at/home/rurban/

[Phpwiki-talk] SQL syntax fix 2 in lib/WikiDB/backend/PearDB.php

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

Found in PhpWikiAdministration by clicking on the "Purge Cache" button -
it's been annoying me for a while!

WikiDB_backend_pearDB->get_all_pages(), line 621 - replace
                    . $exclude ? " WHERE $exclude" : ''
with
                    . ( $exclude ? " WHERE $exclude" : '' )

It is possible that the line number is out by 1 or 2 as it took several
lines of error_log() to track this down that may not have been cleaned up
correctly.

regards,
Charles

[Phpwiki-talk] RFC: allow "wiki" to specify location of config.ini

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

I would like the wiki file to specify the location of config.ini.  This
would allow me to use the clean versions of PhpWiki from CVS without
a) having to remember to copy config.ini into the CVS controlled directory
each time I get a fresh version (Eclipse deletes my private version of
config.ini when I request a refresh from CVS
b) when I get CVS-write access, I will not accidentally checkin my private
version of config.ini with passwords

I think that this facility might also be useful for wikifarms (but others
will know better)

Patch:
index.php - line 36 - replace
IniConfig(dirname(__FILE__)."/config/config.ini");

with
if (defined('CONFIG_FILE_LOCATION')) {
	IniConfig(CONFIG_FILE_LOCATION);
} else {
	IniConfig(dirname(__FILE__)."/config/config.ini");
}


wiki - line 19 - insert

The default location for config.ini is in phpwiki\config\config.ini
To define an alternate location for config.ini, insert the following
define before 'include "index.php";' and change the path to your required
location
define('CONFIG_FILE_LOCATION', 'C:\doc_root\config.ini');


If this change is accepted, will need to track down any other places in
the code base that refer to config.ini (mostly it is documentation).

regards,
Charles

Re: [Phpwiki-talk] SQL syntax fix in lib/WikiDB/backend/PearDB.php

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

Charles Corrigan schrieb:
> in WikiDB_backend_PearDB->exists_link() - lines 579 - 581 should be
>                                 . " AND $have.pagename='$qpagename'"
>                                 . " AND $want.pagename='$qlink'"
>                                 . " LIMIT 1");

Aah, thanks. A escape-change left-over. Hopefully the last.

BTW: This is one of the major WikiDB-pear changes from 1.3.10 to 1.3.11. 
I have to document that mor prominently in the ReleaseNotes, that 1.3.11 
requires now a quite new pear DB module. To finally have uniform quoting 
style.

We didn't yet change to the ADODB-style to automatically support all 
databases, but it's on its way. Our pear db backend still requires an 
explicit PearDB_<backend>.php file.

> While tracking this problem, I noticed that the LIMIT clause was commented
> out in most places - is it applicable here?

GetRow needs it explicitly. In most other cases I changed ->query() to 
use ->LimitQuery() instead.
This is just for cross-db compatibility.
E.g. certain SQL operations disallow the "LIMIT from, count" syntax.

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

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

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

Joel Uckelman schrieb:
>>I had a play with apache2.0, php4.3.11 and mysql4.0.23 on windows. What I
>>found was that attempting to create a virgin wiki reliably crashed the
>>apache process with no info in the logs.
> 
> It crashed Apache? Yow! Does that mean that it's an Apache bug? I didn't
> think that PHP was supposed to be able to do that.

Since php is loaded as shared module it is able to crash the parent 
process. It happens all the time on certain php bugs.
Sessions exceeding ~4000 bytes, certain hairy pcre pieces (fixed 
recently), recent 4.3.10 - old zendoptimizer incompatiblities, or just 
thread-unsafe php libs.

Esp. apache2 (in the threaded worker model, old-style prefork is okay) 
is problematic with thread-unsafe php libs. That's why Rasmus excplictly 
recommends NOT to use apache2 worker model in production enviroment, 
together with php.
"Do not use Apache 2.0.x and PHP in a production environment neither on 
Unix nor on Windows." -- 
http://www.php.net/manual/en/install.unix.apache2.php

http://apache.slashdot.org/comments.pl?sid=101407&cid=8644732
http://drbacchus.com/wordpress/index.php?p=844

I personally also found the php mime-type overrides with apache2 are 
broken, but there are workarounds.

>>I "downgraded" to apache1.3 and created the wiki. Since then my dev/test
>>wiki has worked with both apache1.3 and apache2.0 (most of the time I use
>>2.0). I have not made the time to trace and find out exactly why apache2.0
>>crashes
-- 
Reini Urban
http://xarch.tu-graz.ac.at/home/rurban/

[Phpwiki-talk] SQL syntax fix in lib/WikiDB/backend/PearDB.php

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

in WikiDB_backend_PearDB->exists_link() - lines 579 - 581 should be
                                . " AND $have.pagename='$qpagename'"
                                . " AND $want.pagename='$qlink'"
                                . " LIMIT 1");


While tracking this problem, I noticed that the LIMIT clause was commented
out in most places - is it applicable here?

regards,
Charles

RE: [Phpwiki-talk] Fixes to caching

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

Reini,

I see that you committed 1 of the 3 different fixes included in my original
email. I did some further testing and found that my initial report of
remaining errors was due to html caching - now my test case works correctly.

The 2 other updates were:

Only update the _pagedata_cache if the database is queried
----------------------------------------------------------
(the 4 lines involving $readdata). This is important as if the _data_cache
has been updated due to user action, it might be overwritten with stale data
when get_versiondata is called later.


Change $nc (derived from $need_content) to use '1' and '2'
----------------------------------------------------------
If $nc is '0', I found weird stuff happening to _versiondata_cache
(referenced through $cache) and to _pagedata_cache when assigned from $vdata
which was assigned from _versiondata_cache (referenced through $cache). I
wrote the following debugging code and liberally called it in various places
in get_versiondata. For example, after the call to _backend->get_versiondata
it reported that $cache[$pagename][$version][$nc] existed but contained
nothing when $nc was '0'.

if (!defined('WIKIDB_FORCE_CREATE'))
    define('WIKIDB_FORCE_CREATE', -1);
	
if (!defined('CJC_EL'))
	define('CJC_EL','c:\amp\error.log');

if (!defined('CJC_LE'))
	define('CJC_LE',"\r\n");

function log_var($logvar,$varname,$depth = 0) {
	if (is_array($logvar)) {
		$nameprint = 1;
		reset($logvar);
		while (list($k,$v) = each($logvar)) {
			if ($k<>'content' && $k<>'%content') {
				if ($nameprint) {
					$nameprint = 0;
					error_log(str_repeat('
',$depth*2).$varname.CJC_LE,3,CJC_EL);
				}
				if(is_array($v) && $depth < 10) {
	
log_var($v,$varname.'['.$k.']',$depth+1);
				} else {
					error_log(str_repeat('
',($depth+1)*2).$k.' => '.$v.CJC_LE,3,CJC_EL);
				}
			}
		}
	} else {
		error_log(str_repeat('  ',$depth*2).$varname.':
'.$logvar.CJC_LE,3,CJC_EL);
	}
}

Regards,
Charles

-----Original Message-----
From: Charles Corrigan [mailto:ch...@ru...] 
Sent: 17 January 2005 01:46
To: php...@li...
Subject: [Phpwiki-talk] Fixes to caching

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

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

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

Regards,
Charles

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


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

Anyway, my replacement versions of the functions are below

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

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

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

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




-------------------------------------------------------
The SF.Net email is sponsored by: Beat the post-holiday blues
Get a FREE limited edition SourceForge.net t-shirt from ThinkGeek.
It's fun and FREE -- well, almost....http://www.thinkgeek.com/sfshirt
_______________________________________________
Phpwiki-talk mailing list
Php...@li...
https://lists.sourceforge.net/lists/listinfo/phpwiki-talk

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

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

It is a standard release build, so must be php4.3.10

Regards,
Charles

-----Original Message-----
From: Reini Urban [mailto:ru...@x-...] 
Sent: 18 January 2005 03:16
To: php...@li...
Subject: Re: [Phpwiki-talk] 1.3.10 and Apache 2, small projects, wiki spam

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

php-4.3.11: this is not released yet. A snap or 4.3.10?

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



-------------------------------------------------------
The SF.Net email is sponsored by: Beat the post-holiday blues
Get a FREE limited edition SourceForge.net t-shirt from ThinkGeek.
It's fun and FREE -- well, almost....http://www.thinkgeek.com/sfshirt
_______________________________________________
Phpwiki-talk mailing list
Php...@li...
https://lists.sourceforge.net/lists/listinfo/phpwiki-talk

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

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

Russ Miller schrieb:
> On Mon, 17 Jan 2005 20:08:47 +0100, Reini Urban <ru...@x-...> wrote:
>>It should link to our existing WikiSpam page, which misses some latest
>>development (link restriction, SpamAssassinIntegration).

No. It's complete.

> O lord don't bury this in WikiSpam documentation. This is basic setup
> information that needs to be front and center. I would grossly
> estimate that only 50% of downloaders want a wide open wiki. Most are
> looking for a CMS of some kind, and this will allow them to set things
> up pretty quickly.

I didn't say that. Just that this doc, which should go into 
doc/README.Security or such, should point to the existing antispam 
features. (Which are more important than tying down auth, IMHO)

> I think a lot of people are driven away from the project because
> setting up common configs (small group CMS, for instance) requires you
> to know new and poorly doumented permissions features, what the heck a
> 'bogo login" is, etc.
> 
> I would say config for true wiki, single user wiki-as-cms, and small
> group wiki-as-cms would be good documentation to have...

Good idea.
-- 
Reini Urban
http://phpwiki.org/

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

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

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

It crashed Apache? Yow! Does that mean that it's an Apache bug? I didn't
think that PHP was supposed to be able to do that.
 
> I "downgraded" to apache1.3 and created the wiki. Since then my dev/test
> wiki has worked with both apache1.3 and apache2.0 (most of the time I use
> 2.0). I have not made the time to trace and find out exactly why apache2.0
> crashes
> 
> Regards,
> Charles

My Apache 2.0 configuration isn't anything special; after I corrected a bug
in index.php, creating a wiki worked out of the box. I'm running Linux, though;
if your Apache setup is fairly normal, then I'd expect that this is a Windows-
specific problem. That's about all I can say, since I don't have access to
a Windows box running Apache 2.0.

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

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

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

php-4.3.11: this is not released yet. A snap or 4.3.10?

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

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

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

Charles Corrigan schrieb:
> 3 - change the default page permissions. This is the not so well
> documented piece (as far as I can tell). Create a page named . to hold
> these default permissions. Yes, named "." - this cannot be done directly
> from normal web interface. (Note that these permissions may be over-ridden
> at the individual page level.)
> 
> What I did was to
> * export a Zip Dump via the PhpWikiAdministration page
> * extract one of the files from this zip - initially, it might look like

Now I remembered how I edited pagename '.'

/wiki/?action=edit&pagename=.


/wiki/.?action=edit will not work.

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

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

Charles Corrigan schrieb:
> Here is a draft security HOW-TO.  Please comment. There are some
> outstanding questions (particularly about whether it is necessary to lock
> group pages) and there is a bug in SetAcl (regarding removing groups from
> an Acl) that I want to look into before completing this document.
> 
> Eventually, with cleanup, it could become a WikiPage in it's own right.

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

Note that GROUP_METHOD = WIKIPAGE is by far the slowest and uses the 
most memory, but is easiest to maintain.
Unfortunately all security checks (may list, may view, may edit, ...) go 
through the groups, which requires a pagecontent retrieval and several 
more page checks. With DB or LDAP it's almost atomic.

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

/wiki/.?action=edit is forbidden? Oops, that's a bug, introduced lately. 
It should only be forbidden on DATABASE_TYPE = file.

This page should definitely go into the phpwiki docs immediately, 
without any further discussion here. Better fix it in the wiki.

Good work!

It should link to our existing WikiSpam page, which misses some latest 
development (link restriction, SpamAssassinIntegration).

I don't know if we should announce our existing anti-spam methods in a 
wikipage though.
-- 
Reini Urban
http://xarch.tu-graz.ac.at/home/rurban/