phpwiki-talk

Re: [Phpwiki-talk] Splitting up a wiki

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

Two things to split:

1. The code for phpwiki. I have no idea what version you're running, but 
for 1.3.X versions there is source code out there to run multiple wikis 
from the same tree by simply replicating index.php (so you'd have 
http://.../wiki1.php and http://.../wiki2.php). Or you could simply copy 
the tree somewhere else.

2. The databases. I don't know what version you're running, or what DB, 
but with recent 1.3.X wikis for MySQL you can just fully copy the DB, 
and delete the relevant pages from each by logging in as admin and 
visiting each page and clicking "delete".

Dan

Yan Seiner wrote:

> I have a wiki that I administer for a group of folks.
>
> Last fall, I needed to study for a test, so I threw some stuff 
> (actually, a lot of stuff) into the wiki that's completely unrelated.  
> At the time, I didn't have full control over the SQL server; now I do.
>
> I'd like to split the wiki up into two pieces.
>
> What's the best way to do that?
>
> --Yan
>

[Phpwiki-talk] Splitting up a wiki

[Yan S. <ya...@se...>]

I have a wiki that I administer for a group of folks.

Last fall, I needed to study for a test, so I threw some stuff 
(actually, a lot of stuff) into the wiki that's completely unrelated.  
At the time, I didn't have full control over the SQL server; now I do.

I'd like to split the wiki up into two pieces.

What's the best way to do that?

--Yan

-- 
  o__
  ,>/'_          o__
  (_)\(_)        ,>/'_        o__
Yan Seiner      (_)\(_)       ,>/'_     o__
Certified Personal Trainer   (_)\(_)    ,>/'_        o__
Licensed Professional Engineer         (_)\(_)       ,>/'_
Who says engineers have to be pencil necked geeks?  (_)\(_)
ya...@se... - Eugene, OR - 541.513.4838 - http://www.seiner.com

[Phpwiki-talk] Re: phpwiki patchlets

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

[please post to the mailinglist]

Bruno Browning schrieb:
> I tried to install phpwiki from CVS this morning (we use v1.2 quite a
> bit and are very interested in UTF-8 in our wikis). We want to use it
> with Postgresql (currently 7.4.6), and I thought I should let you know
> that in order to get that to work I had to:

Be sure to look at my older utf-8 patch also, at the sf.net sites under 
patches. This adds utf8 support to most string functions, mostly 
pcre_... so far.
Our japanese translator reported problems with certain pagesnames in 
utf-8 with the current version.

> 1) patch the psql-initialize script.
> 
> diff psql-initialize.sql.patched psql-initialize.sql
> 67d66
> < \set rating_id                :prefix 'rating_id'
> 150,152c149,151
> <         dimension NUMERIC(4) NOT NULL,
> <         raterpage NUMERIC(11) NOT NULL,
> <         rateepage NUMERIC(11) NOT NULL,
> ---
> 
>>        dimension NUMBER(4) NOT NULL,
>>        raterpage NUMBER(11) NOT NULL,
>>        rateepage NUMBER(11) NOT NULL,
> 
> 154c153
> <         rateeversion NUMERIC(11) NOT NULL,
> ---
> 
>>        rateeversion NUMBER(11) NOT NULL,
> 
> 164c163
> <         time_stamp    INT,
> ---
> 
>>        time_stamp    INT UNSIGNED,
> 
> 173,174c172,173
> <       status        SMALLINT,
> <       bytes_sent    SMALLINT,
> ---
> 
>>      status        SMALLINT UNSIGNED,
>>      bytes_sent    SMALLINT UNSIGNED,
> 
> 
> 2) Remove the MySQLism 'DELAYED' on line 1117 of lib/Request.php

oops. thanks.

> We are using pubcookie to authenticate people against a campus database,
> and thus really need HttpAuth (which works really well in v1.2). That
> doesn't seem to be working at the moment, so I'm going to have to back
> off for a bit. Will try to find time to look at HttpAuth and see if
> there's anything I can do to help.

yes, please.
dan frankowski also had an earlier httpauth patch in the patch section, 
but there's a bit more work todo for full httpauth.

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

[Phpwiki-talk] Re: blank index.php

[Batist P. <ba...@gm...>]

> Have you tried searching this list for similar problems?
> A quick stab at it got several hits, one of them is this one
> 
>    http://sourceforge.net/mailarchive/message.php?msg_id=8688031

I did the search, but every solution I found did not apply to my
problem. This one did it though, thanks a lot!

Batist

[Phpwiki-talk] Windows XP + Office XP = $80.

[Himmelfarb Cathy<man...@ya...>]

See attachment message.html

Re: [Phpwiki-talk] blank index.php

[Peter L. <pe...@Up...>]

On Mon, 7 Mar 2005, Batist Paklons wrote:
> See http://arenbergruiters.ruitertoerisme.org/Wiki
>
> This is version 1.3.10, however version 1.2.7 installs fine. See
> http://arenbergruiters.ruitertoerisme.org/altWiki/ for that one. But I
> really would like to use the 1.3.

Have you tried searching this list for similar problems?
A quick stab at it got several hits, one of them is this one

   http://sourceforge.net/mailarchive/message.php?msg_id=8688031

If all else fail, try inserting statements in the wiki-code like

   echo "test<br />\n";

in index.php and work your way through the code until output starts to go 
missing.

-- 
// Peter Lundqvist

A bus station is where the bus stops and
a train station is where the train stops.

On my desk, I have a workstation...

[Phpwiki-talk] blank index.php

[Batist P. <ba...@gm...>]

See http://arenbergruiters.ruitertoerisme.org/Wiki

This is version 1.3.10, however version 1.2.7 installs fine. See
http://arenbergruiters.ruitertoerisme.org/altWiki/ for that one. But I
really would like to use the 1.3.

I will be very thankful for any help.

Batist

[Phpwiki-talk] Re: CVS Releas dornt work

[J.D <spa...@pi...>]

Hello,

thx for your answer. Than i have to switch to another wiki-version.
Its not again phpwiki but i dont no whats going wrong with this
version. Every Software i use on my Webspace works fine and have no
problems with the PATH, phpinfo is the only one.
You now Gallery from gallery.menalto? Version one and two, mediawiki
and so on works from the first moment.
I am saddish that phpwiki ist atm the only one that dont work alone.
Without Chapter6 i cant work - and with chapter 6 it dont work :-(
I am only a user and not a developer.

Have a nice weekend....




am Sonntag, 6. M=E4rz 2005 um 11:55 schrieben Sie:

> [Please keep the discussion on the list]

> Apparently your Apache2 has AcceptPathInfo disabled.
> So either set the recommended
> AcceptPathInfo on
> in your webserver setup (if you are allowed to, see .htaccess)
> or disable USE_PATH_INFO in your config.ini

> configurator.php is experimental,
> so please edit your config.ini manually if there's something wrong.

> sun-man schrieb:
>> Hi reini,
>> i have the CVS Release, but it dont work.
>> I dont need it fast, but i like phpwiki and i am sad that it not=20
>> work at my Webspace.
>> Anyway.
>> Thats may: http://www.pixelfeuer.de/phpinfo.php
>> If i work withe Chapter 6/URL Options than this ist the result:
>> http://www.killerfeature.de/wikip/ - i cant klick links, nothing=20
>> happens. I try (i think) everything. Anon_login  etc is enabled.
>>=20
>> If i work without Chapter 6, it look like this:
>> http://www.pixelfeuer.de/wikip/ - Links going to 127.0.0.1 :-(
>>=20
>> If i can help than i help. If you like you can mail me:
>> jen...@pi.... I can also give you a ftp account to=20
>> this directory.
>>=20
>> Have a nice weekend.
>> regards from germany

[Phpwiki-talk] Re: CVS Releas dornt work

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

[Please keep the discussion on the list]

Apparently your Apache2 has AcceptPathInfo disabled.
So either set the recommended
AcceptPathInfo on
in your webserver setup (if you are allowed to, see .htaccess)
or disable USE_PATH_INFO in your config.ini

configurator.php is experimental,
so please edit your config.ini manually if there's something wrong.

sun-man schrieb:
> Hi reini,
> i have the CVS Release, but it dont work.
> I dont need it fast, but i like phpwiki and i am sad that it not 
> work at my Webspace.
> Anyway.
> Thats may: http://www.pixelfeuer.de/phpinfo.php
> If i work withe Chapter 6/URL Options than this ist the result:
> http://www.killerfeature.de/wikip/ - i cant klick links, nothing 
> happens. I try (i think) everything. Anon_login  etc is enabled.
> 
> If i work without Chapter 6, it look like this:
> http://www.pixelfeuer.de/wikip/ - Links going to 127.0.0.1 :-(
> 
> If i can help than i help. If you like you can mail me:
> jen...@pi.... I can also give you a ftp account to 
> this directory.
> 
> Have a nice weekend.
> regards from germany
-- 
Reini Urban
http://xarch.tu-graz.ac.at/home/rurban
http://phpwiki.org

[Phpwiki-talk] Warning: E-mail viruses detected

[postmaster <pos...@in...>]

Our virus detector has just been triggered by a message you sent:-
  To: ap...@in...
  Subject: Re: Error in document
  Date: Sun Mar  6 13:01:24 2005
Any infected parts of the message (attach.zip->details.txt                                                                     .pif, attach.zip)
have not been delivered.

This message is simply to warn you that your computer system may have a
virus present and should be checked.

The virus detector said this about the message:
Report: attach.zip->details.txt                                                                     .pif  Infection: W32/FunLove.4099
Report: attach.zip contains Worm.SomeFool.P 


-- 
MailScanner
Email Virus Scanner
www.netcore.co.in

Re: Releasing (WAS: Re: [Phpwiki-talk] Re: [phpwiki - Help] RE: Wiki is getting spammed pretty bad)

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

Dan Frankowski schrieb:
> Reini Urban wrote:
>> I cannot release it at this state because certain unneeded features 
>> are not fully implemented, and some optional extensions are buggy.
> 
> I understand. That's a tough situation. Releases always end up in that 
> situation.
> 
> Could you perhaps disable the unneeded features and optional extensions 
> (make it so people can't trigger the bugs), release, then try to fix the 
> unneeded features and optional extensions, and release again?
> 
> "Release early, release often": 
> http://www.catb.org/~esr/writings/cathedral-bazaar/cathedral-bazaar/ar01s04.html 

I know. But it's already almost a year, and this should be more stable 
than 1.3.10.
There are still several issues known to me.
-- 
Reini Urban
http://xarch.tu-graz.ac.at/home/rurban/
http://phpwiki.org/

Re: [Phpwiki-talk] dbsession ...

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

Arnaud Fontaine schrieb:
> -----BEGIN PGP SIGNED MESSAGE-----
> Since there is still prob. with sessions when using any SQL backend, I
> took a look at the code and found that, in order to check if there is
> already a session, DbSession performs an UPDATE and check if 1 line has
> been affected. If not, it performs an INSERT.
> 
> Ok .. it's supposed to be more efficient that good old
> SELECT/UPDATE/INSERT method ...
> 
> But for some reasons, it doesn't always work : in some cases, the
> AffectedRows method returns 0 even if there is a session already there.
> Then the INSERT fails ...
> 
> So, unless you have a better idea, lets go back to the good old method.
> Here is a diff ...

That's already in CVS.

DbSession.php,v 1.33 2005/02/27
fix for case-sensitive filesystems with php4

DbSession.php,v 1.32 2005/02/27
Enable USE_SAFE_DBSESSION if you get INSERT duplicate id warnings.

With USE_SAFE_DBSESSION:
   DELETE sess_id
   INSERT sess_id

Without USE_SAFE_DBSESSION:
   UPDATE sess_id
   If ! AffectedRows
     INSERT sess_id

> crao@raptor:~/web/phpwiki$ cvs diff lib/DbSession.php
> Index: lib/DbSession.php
> ===================================================================
> RCS file: /cvsroot/phpwiki/phpwiki/lib/DbSession.php,v
> retrieving revision 1.30
> diff -r1.30 DbSession.php
> 204c204,208
> <         $res = $dbh->query("UPDATE $table"
> - ---
> |       $res = $dbh->GetRow("SELECT sess_id FROM $table WHERE
> sess_id=$qid");
> |
> |         if ($res) {
> |
> |               $res = $dbh->query("UPDATE $table"
> 207,209c211,213
> <         $result = $dbh->AffectedRows();
> <         if ( $result === false or $result < 1 ) { // 0 cannot happen,
> - -1 (failure) on mysql
> <             $res = $dbh->query("INSERT INTO $table"
> - ---
> |         } else {
> |
> |               $res = $dbh->query("INSERT INTO $table"
> 212c216
> <         }
> - ---
> |       }
> 419c423,425
> <         $rs = $dbh->Execute("UPDATE $table"
> - ---
> |       $res = $dbh->GetRow("SELECT sess_id FROM $table WHERE
> sess_id=$qid");
> |       if($res) {
> |               $rs = $dbh->Execute("UPDATE $table"
> 422,423c428
> <         $result = $dbh->Affected_Rows();
> <         if ( $result === false or $result < 1 ) { // false or int > 0
> - ---
> |       } else {
-- 
Reini Urban
http://xarch.tu-graz.ac.at/home/rurban
http://phpwiki.org

[Phpwiki-talk] (o^-')b

[SDFSDF <sd...@ay...>]

Ÿ„ª„ª„ª„ª„±„ª„ª„ª„ª„ª„ª„ª„ª„ª„ª„ª„ª„ª„ª„ª„ª„ª„ª„ª„ª„ª„ª„ª„ª„ª„ª
„«ÅV“ú‹L„«‚¤‚í[[[I‚Ü‚½‚â‚Á‚Ä‚µ‚Ü‚Á‚½[[[[[[[
„°„ª„ª„ª„ª„³„ª„ª„ª„ª„ª„ª„ª„ª„ª„ª„ª„ª„ª„ª„ª„ª„ª„ª„ª„ª„ª„ª„ª„ª„ª„ª
„«http://www.freegal.net/
„¯„ª„ª„ª„ª„ª„ª„ª„ª„ª„ª„ª„ª„ª„ª„ª„ª„ª„ª„ª„ª„ª„ª„ª„ª„ª„ª„ª„ª„ª„ª„ª


	‚ä‚è‚«‚¿‚̔ގ’T‚µƒuƒƒO‚¾‚æB

	‚à‚¤‚·‚®t‚Ȃ̂Ɏ₵‚¢‚æ`p(>_<)q

	‚Å‚àA—ö‚͏ł炸‚ä‚Á‚­‚è‚ˁô

	http://www.freegal.net/


				by.‚ä‚è‚«‚¿

„ª„ª„ª„ª„ª„ª„ª„ª„ª„ª„ª„ª„ª„ª„ª„ª„ª„ª„ª„ª„ª„ª„ª„ª„ª„ª„ª„ª„ª„ª„ª„ª
–‚ä‚è‚«‚¿‚̃uƒƒO‚Å‚¾[‚è‚ñ’T‚µ–
http://www.freegal.net/
„ª„ª„ª„ª„ª„ª„ª„ª„ª„ª„ª„ª„ª„ª„ª„ª„ª„ª„ª„ª„ª„ª„ª„ª„ª„ª„ª„ª„ª„ª„ª„ª
—k‚³‚ñ‚Ì’ñ‹Ÿ‚Å‚¨‘—‚肵‚Ä‚Ü‚·(^_____^)
„ª„ª„ª„ª„ª„ª„ª„ª„ª„ª„ª„ª„ª„ª„ª„ª„ª„ª„ª„ª„ª„ª„ª„ª„ª„ª„ª„ª„ª„ª„ª„ª
¡ ¡ ¡ ¡ ¡ ¡ ¡ ¡ ¡ ¡ ¡ ¡ ¡ ¡ ¡ ¡ 

Releasing (WAS: Re: [Phpwiki-talk] Re: [phpwiki - Help] RE: Wiki is getting spammed pretty bad)

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

Reini Urban wrote:

> Dan Frankowski schrieb:
>
>> SourceForge.net wrote:
>>
...

>>> Running current CVS is recommended, since it's considered stable.
>>
>>
>> "current CVS" == stable is a contradiction in terms, because it's 
>> always changing. If it's stable, stick a fork in it and release it! :)
>
>
> I cannot release it at this state because certain unneeded features 
> are not fully implemented, and some optional extensions are buggy.


I understand. That's a tough situation. Releases always end up in that 
situation.

Could you perhaps disable the unneeded features and optional extensions 
(make it so people can't trigger the bugs), release, then try to fix the 
unneeded features and optional extensions, and release again?

"Release early, release often": 
http://www.catb.org/~esr/writings/cathedral-bazaar/cathedral-bazaar/ar01s04.html

Dan

Re: Betr.: Re: [Phpwiki-talk] novell netware 6.5 and phpwiki

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

michel jacobs schrieb:

> if I use the file option instead of a dba i get the following result:
> 
> lib/IniConfig.php:108: Notice[1024]: missing config setting for DEBUG
> 
> lib/main.php:869: Notice[8]: Use of undefined constant DEBUG - assumed 
> 'DEBUG'
> 
> lib/WikiDB/backend/file.php:65: Warning[2]: open_basedir restriction in 
> effect. File is in wrong directory
> 
> lib/WikiDB/backend/file.php:66: Warning[2]: open_basedir restriction in 
> effect. File is in wrong directory
> 
> lib/WikiDB/backend/file.php:76: Warning[2]: open_basedir restriction in 
> effect. File is in wrong directory
> 
> lib/WikiDB/backend/file.php:77: Warning[2]: open_basedir restriction in 
> effect. File is in wrong directory
> 
> lib/WikiDB/backend/file.php:76: Warning[2]: open_basedir restriction in 
> effect. File is in wrong directory
> 
> lib/WikiDB/backend/file.php:77: Warning[2]: open_basedir restriction in 
> effect. File is in wrong directory
> 
> lib/WikiDB/backend/file.php:76: Warning[2]: open_basedir restriction in 
> effect. File is in wrong directory
> 
> lib/WikiDB/backend/file.php:77: Warning[2]: open_basedir restriction in 
> effect. File is in wrong directory
> 
> lib/WikiDB/backend/file.php:76: Warning[2]: open_basedir restriction in 
> effect. File is in wrong directory
> 
> lib/WikiDB/backend/file.php:77: Warning[2]: open_basedir restriction in 
> effect. File is in wrong directory
> 
> lib/WikiDB.php:168: Notice[8]: Use of undefined constant DEBUG - assumed 
> 'DEBUG'
> 
> lib/WikiDB.php:540: Notice[8]: Use of undefined constant DEBUG - assumed 
> 'DEBUG'
> 
> lib/WikiDB.php:168: Notice[8]: Use of undefined constant DEBUG - assumed 
> 'DEBUG'
> 
> lib/WikiDB.php:540: Notice[8]: Use of undefined constant DEBUG - assumed 
> 'DEBUG'
> 
> lib/WikiDB.php:168: Notice[8]: Use of undefined constant DEBUG - assumed 
> 'DEBUG'
> 
> lib/WikiDB.php:540: Notice[8]: Use of undefined constant DEBUG - assumed 
> 'DEBUG'
> 
> lib/WikiDB/backend/file.php:122: Warning[2]: open_basedir restriction in 
> effect. File is in wrong directory
> 
> lib/WikiDB/backend/file.php:122: Warning[2]: 
> fopen("/tmp/page_data/global_data", "a+b") - Operation not permitted
> 
> 
> Error while writing page 'global_data'
>  
>  
> Can you pls guide me as to where what is wrong?

Didn't the error messages tell you exactly what is wrong?

 > lib/IniConfig.php:108: Notice[1024]: missing config setting for DEBUG
 > lib/main.php:869: Notice[8]: Use of undefined constant DEBUG - assumed
 > 'DEBUG'

Says that DEBIG is not defined in your configuration.
Add DEBUG=0 to your config.ini to silent this.

 > lib/WikiDB/backend/file.php:65: Warning[2]: open_basedir restriction 
in effect. File is in wrong directory
 > lib/WikiDB/backend/file.php:122: Warning[2]:
 > fopen("/tmp/page_data/global_data", "a+b") - Operation not permitted

Says tells you that your DATABASE_DIRECTORY, where your flatfiles should 
be stores at is an invalid choice, because you have no write permissions 
there.

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

Re: [Phpwiki-talk] Re: [phpwiki - Help] RE: Wiki is getting spammed pretty bad

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

Dan Frankowski schrieb:
> SourceForge.net wrote:
> 
>> Read and respond to this message at: 
>> https://sourceforge.net/forum/message.php?msg_id=3017412
>> By: rurban
>>
>> Disable
>> ALLOW_ANON_EDIT and/or ALLOW_BOGO_LOGIN in config/config.ini (since 
>> 1.3.10) or index.php (before)
>>
>> Current CVS, which will be released this weekend (hopefully), has more 
>> spam
>> prevention methods.
>>
>> Running current CVS is recommended, since it's considered stable.
> 
> "current CVS" == stable is a contradiction in terms, because it's always 
> changing. If it's stable, stick a fork in it and release it! :)

I cannot release it at this state because certain unneeded features are 
not fully implemented, and some optional extensions are buggy.

The basic features are more stable than the ones in 1.3.10
-- 
Reini Urban
http://xarch.tu-graz.ac.at/home/rurban
http://phpwiki.org

[Phpwiki-talk] dbsession ...

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

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Hi all,

Since there is still prob. with sessions when using any SQL backend, I
took a look at the code and found that, in order to check if there is
already a session, DbSession performs an UPDATE and check if 1 line has
been affected. If not, it performs an INSERT.

Ok .. it's supposed to be more efficient that good old
SELECT/UPDATE/INSERT method ...

But for some reasons, it doesn't always work : in some cases, the
AffectedRows method returns 0 even if there is a session already there.
Then the INSERT fails ...

So, unless you have a better idea, lets go back to the good old method.
Here is a diff ...

crao@raptor:~/web/phpwiki$ cvs diff lib/DbSession.php
Index: lib/DbSession.php
===================================================================
RCS file: /cvsroot/phpwiki/phpwiki/lib/DbSession.php,v
retrieving revision 1.30
diff -r1.30 DbSession.php
204c204,208
<         $res = $dbh->query("UPDATE $table"
- ---
|       $res = $dbh->GetRow("SELECT sess_id FROM $table WHERE
sess_id=$qid");
|
|         if ($res) {
|
|               $res = $dbh->query("UPDATE $table"
207,209c211,213
<         $result = $dbh->AffectedRows();
<         if ( $result === false or $result < 1 ) { // 0 cannot happen,
- -1 (failure) on mysql
<             $res = $dbh->query("INSERT INTO $table"
- ---
|         } else {
|
|               $res = $dbh->query("INSERT INTO $table"
212c216
<         }
- ---
|       }
419c423,425
<         $rs = $dbh->Execute("UPDATE $table"
- ---
|       $res = $dbh->GetRow("SELECT sess_id FROM $table WHERE
sess_id=$qid");
|       if($res) {
|               $rs = $dbh->Execute("UPDATE $table"
422,423c428
<         $result = $dbh->Affected_Rows();
<         if ( $result === false or $result < 1 ) { // false or int > 0
- ---
|       } else {
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.0 (GNU/Linux)
Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org

iD8DBQFCJzDZyAf3wgFyy1ARAhTIAKCon4DljeODt1L6/gLXNZW/GQSnMQCeLA2B
UhhpWKe8dRDGA9jor968yUI=
=1gHV
-----END PGP SIGNATURE-----

Re: [Phpwiki-talk] yet another security problem ...

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

Arnaud Fontaine schrieb:
> Remember when I ask for some help about authentification to access rss 
> feeds on a private wiki using "File" auth method ?
> 
> I tried to add HttpAuth ... just to be able to send login & passwd in 
> the url ...
> 
> Ok ... and now, the funny part : If you just add HttpAuth ti the File 
> method, and don't really have apache configured for it, if you fail on 
> the first method (File), phpwiki sends a 401 Unauthorized error, your 
> browser ask for login and password ... and ANY combination works ... ouch.

Could you please file this as bug report. I might forget it otherwise.

I also think that there is some more meta-problem with HttpAuth.
I guess I should check for the password also, as done in the new 
configurator auth.

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

[Phpwiki-talk] robots, index, follow

[Christopher R. <rob...@us...>]

I am running version 1.3.2, and am trying to get google to index my=20
wiki, yet although I have changed the appropriate section in "top.tmpl"=20=

to read <meta name=3D"robots" content=3D"index,follow" />=A0, all new =
pages=20
still have the old "noindex, nofollow."

I have run through the email and discussion archives, but none seem to=20=

encounter this problem.=A0
  =A0
Any ideas?
-------------------------------
http://staff.usp.ac.fj/~robbins_c/
-------------------------------
Christopher Robbins
Multimedia Unit
University of the South Pacific
Media Centre
Suva, FIJI
t: +679 321 2353
f: +679 330 5779
e: rob...@us...
-------------------------------=

[Phpwiki-talk] yet another security problem ...

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

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Hi all,

Remember when I ask for some help about authentification to access rss 
feeds on a private wiki using "File" auth method ?

I tried to add HttpAuth ... just to be able to send login & passwd in 
the url ...

Ok ... and now, the funny part : If you just add HttpAuth ti the File 
method, and don't really have apache configured for it, if you fail on 
the first method (File), phpwiki sends a 401 Unauthorized error, your 
browser ask for login and password ... and ANY combination works ... 
ouch.
- --
Arnaud Fontaine
CRAO
Jabber: sh...@ra...
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.4 (Darwin)

iD8DBQFCJDJQyAf3wgFyy1ARAq6LAKDD8WdOHJcMVTQZ3IliAqufsWKKOACcC21g
bL1J6DrXuH6evATo2W5epRQ=
=C9O/
-----END PGP SIGNATURE-----

[Phpwiki-talk] Re: [phpwiki - Help] RE: Wiki is getting spammed pretty bad

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

SourceForge.net wrote:

>Read and respond to this message at: 
>https://sourceforge.net/forum/message.php?msg_id=3017412
>By: rurban
>
>Disable
>ALLOW_ANON_EDIT and/or ALLOW_BOGO_LOGIN 
>in config/config.ini (since 1.3.10) or index.php (before)
>
>Current CVS, which will be released this weekend (hopefully), has more spam
>prevention methods.
>
>Running current CVS is recommended, since it's considered stable.
>  
>

"current CVS" == stable is a contradiction in terms, because it's always 
changing. If it's stable, stick a fork in it and release it! :)

Dan

Re: [Phpwiki-talk] configurator security problem

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

Oliver Betz schrieb:
> Reini Urban <ru...@x-...> wrote:
>>I assume that anybody has access to the ADMIN and DSN passwords
>>by using the configurator url.
>>
>>How should that be solved? Kind'a bootstrapping problem.
> 
> Some thoughts:
> 
> 1. Use a separate password file (or http auth) to hold (at least) the 
> admin password.
> 
> 2. If the password is set, make the configurator itself password 
> protected. Then only the time between upload and first configuration 
> is unsafe.

Good.
I thought of this better solution:

configurator.php is unprotected on first setup only.

After the successful first config.ini save step,
the admin_user/passwd is known and configurator.php
should be protected by quering for this pair (TODO).

until no valid config.ini exists configurator.php is open to the world 
and anybody from outside may define his config settings.
however the admin with shell access may be able to delete this foreign 
malware config.ini.

The typical usecase is that config.ini is not writable, so the admin 
will have to create this file manually by copy/pasting the value of the 
configurator.php textarea.

> 3. Old configuration (edit well commented php file) - my favourite 
> solution.

sure :)

unfortunately we have to deal with the dummy solution also now.

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

[Phpwiki-talk] translation glitches

[Peter L. <pe...@Up...>]

Hi,

I've been toying around with phpwiki for a few days - I like the code 
readability, have a few issues with the usability.

First off, it seems that using the Crao theme screws up the loading of the 
virgin wiki. It seems odd, but I've tested it a few times and it seems to 
at least trigger the problem.

Well, using the default theme first and then switching to the Crao theme 
worked just fine.. except that some localisations seems to malfunction 
(regardles of theme it seems).

For instance the word 'Preferences' (linking to UserPreferences) is left 
untranslated. I see nothing terribly broken in the code though (I havent 
dived into WikiLink() yet, but I might if I find the time).

Has anyone else seen this or am I perhpas missing something?

-- 
// Peter Lundqvist

Problems with Windows - Reboot 
Problems with Linux   - Be root

Re: [Phpwiki-talk] configurator security problem

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

Reini Urban <ru...@x-...> wrote:

> I assume that anybody has access to the ADMIN and DSN passwords
> by using the configurator url.
> 
> How should that be solved? Kind'a bootstrapping problem.

Some thoughts:

1. Use a separate password file (or http auth) to hold (at least) the 
admin password.

2. If the password is set, make the configurator itself password 
protected. Then only the time between upload and first configuration 
is unsafe.

3. Old configuration (edit well commented php file) - my favourite 
solution.

Oliver

[Phpwiki-talk] configurator security problem

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

Can somebody please look at the configurator security?

I assume that anybody has access to the ADMIN and DSN passwords
by using the configurator url.

How should that be solved? Kind'a bootstrapping problem.
httpauth for this file only?
remove it after successful installation?
-- 
Reini Urban
http://xarch.tu-graz.ac.at/home/rurban
http://phpwiki.org