phpwiki-talk

Re: [Phpwiki-talk] Filename "duplicated" in /phpwiki/themes/MacOS/buttons/de/

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

Charles Corrigan schrieb:
> Now to work out how to install and use the php debugger in Eclipse :-)

There are three of them: zend, xdebug and apd

* xdebug is the best, but probably not supported.
   And it has two different modes: the old gdb and the new xml format.
   "dbgbased" means the old xdebug protocol, which is not so great.
   Better write your own php socket client to understand the gdb
   protocol or better the new xml protocol as the zend ide does,
   than using this weird russian debugger IDE.
* zend is second best, but proprietary and therefore probably
   not supported. (being replaced by xdebug anyway)
* apd is not so great.

We could make the wiki.editor work with Eclipse also.
Via xmlrpc or SOAP. I need some testapp for SOAP anyway.
The hypergraph applet would be fine for Eclipse also.

[BTW: no need to reply to both, just the list is enough]
-- 
Reini Urban

RE: [Phpwiki-talk] Filename "duplicated" in /phpwiki/themes/MacOS/buttons/de/

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

Thanks,

That did the trick...

Now to work out how to install and use the php debugger in Eclipse :-)

Regards,
Charles

-----Original Message-----
From: Reini Urban [mailto:ru...@x-...] 
Sent: 20 December 2004 17:02
To: php...@li...
Subject: Re: [Phpwiki-talk] Filename "duplicated" in
/phpwiki/themes/MacOS/buttons/de/


For consistency I changed the lib/removepage.php:50 definition to 
"Remove Page", so it should be Seite+L%F6schen.png and
Seite+l%F6schen.png is now deleted.
-- 
Reini Urban
http://xarch.tu-graz.ac.at/home/rurban/

Re: [Phpwiki-talk] Plugins

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

Russ Miller schrieb:
> On Mon, 20 Dec 2004 10:06:53 +0100, Reini Urban <ru...@x-...> wrote:
>>No. You have to use it as actionpage like
>>
>>wiki/somepage?action=CreatePage&s=NewPage or
>>wiki/somepage?action=CreatePage&s=NewPage&template=CategoryHomePage
>>
>>or as plugin-form, like:
>>
>><?plugin-form CreatePage ?>
>>
>>in some page, and enter the new pagename into the form.
> 
> 
> Check, I'm doing the latter. Like I said, I enter the page I wish to
> create into the form and it takes me to a new, unedited page called
> 'CreatePage'. Additionally I found that my PluginManager page seems
> broken, perhaps that's a cause? I get this error after the first
> paragraph:

I see. The actionpage CreatePage must exist, so that the action can be 
preformed.
Create it with <?plugin CreatePage ?> or
run ?action=upgrade.
I just did that for you.

> lib/WikiPluginCached.php (In template 'browse') (In template 'body')
> (In template 'html'):35: Warning[2]: main(Cache.php): failed to open
> stream: No such file or directory
> 
> I attempted to turn caching off when I originally set up the wiki...

Hmm. This looks strange. CreatePage is uncached.
WikiPluginCached is only needed for some image creating plugins, like 
Ploticus, VisualWiki, TexToPng, ...

Anyway, you have to provide a valid PLUGIN_CACHED_CACHE_DIR, esp. on 
Windows.

Internal WikiDB page caching has nothing to do with plugin caching. 
(which caches intermediate images)

> Poke around if you like at www.rlm3.com/wiki, I'd appreciate any advice.
-- 
Reini Urban

Re: [Phpwiki-talk] Plugins

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

On Mon, 20 Dec 2004 10:06:53 +0100, Reini Urban <ru...@x-...> wrote:

> No. You have to use it as actionpage like
> 
> wiki/somepage?action=CreatePage&s=NewPage or
> wiki/somepage?action=CreatePage&s=NewPage&template=CategoryHomePage
> 
> or as plugin-form, like:
> 
> <?plugin-form CreatePage ?>
> 
> in some page, and enter the new pagename into the form.

Check, I'm doing the latter. Like I said, I enter the page I wish to
create into the form and it takes me to a new, unedited page called
'CreatePage'. Additionally I found that my PluginManager page seems
broken, perhaps that's a cause? I get this error after the first
paragraph:

lib/WikiPluginCached.php (In template 'browse') (In template 'body')
(In template 'html'):35: Warning[2]: main(Cache.php): failed to open
stream: No such file or directory

I attempted to turn caching off when I originally set up the wiki...

Poke around if you like at www.rlm3.com/wiki, I'd appreciate any advice.

russ


-- 

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

Re: [Phpwiki-talk] Plugins

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

Russ Miller schrieb:
> Having some difficulty using the CreatePage plugin. It's simply
> forwarding me to a (new, unedited) page called CreatePage, which is
> what the "action" in the form is calling, I see. Do i have to do
> something from admin to activate the plugin?

No. You have to use it as actionpage like

wiki/somepage?action=CreatePage&s=NewPage or
wiki/somepage?action=CreatePage&s=NewPage&template=CategoryHomePage

or as plugin-form, like:

<?plugin-form CreatePage ?>

in some page, and enter the new pagename into the form.

All this is described at the CreatePagePlugin page.
http://phpwiki.sourceforge.net/phpwiki/CreatePagePlugin
-- 
Reini Urban
http://xarch.tu-graz.ac.at/home/rurban/

Re: [Phpwiki-talk] Filename "duplicated" in /phpwiki/themes/MacOS/buttons/de/

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

Another good catch!

Charles Corrigan schrieb:
> I have started to use Eclipse and PHPeclipse to help me work out more of 
> what is happening with the issues that I have reported.
> 
> When I use Eclipse to import CVS from Sourceforge, I get an error 
> message for /phpwiki/themes/MacOS/buttons/de/ telling me that 
> “Seite+l%F6schen.png” and “Seite+L%F6schen.png” have the same name with 
> different case (i.e. “l” and “L”).  For unix systems this is technically 
> valid but I use windows and so it is a problem for me.
> 
> My guess is that the two different names are an accident not deliberate… 
> is it possible to work out which one is correct and remove the other?

Button filenames are automatically used from the urlencoded message.
To check this out look at the locale definition:
   locale/po/de.po
search for the strings:
=>

#: ../lib/removepage.php:50
msgid "Remove page"
msgstr "Seite löschen"

#: ../lib/Theme.php:920 ../lib/removepage.php:22
msgid "Remove Page"
msgstr "Seite Löschen"

Then look at the sources, and decide what's better.

For consistency I changed the lib/removepage.php:50 definition to 
"Remove Page", so it should be Seite+L%F6schen.png and
Seite+l%F6schen.png is now deleted.
-- 
Reini Urban
http://xarch.tu-graz.ac.at/home/rurban/

[Phpwiki-talk] Plugins

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

Having some difficulty using the CreatePage plugin. It's simply
forwarding me to a (new, unedited) page called CreatePage, which is
what the "action" in the form is calling, I see. Do i have to do
something from admin to activate the plugin?

russ

-- 

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

[Phpwiki-talk] Filename "duplicated" in /phpwiki/themes/MacOS/buttons/de/

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

I have started to use Eclipse and PHPeclipse to help me work out more of
what is happening with the issues that I have reported.

 

When I use Eclipse to import CVS from Sourceforge, I get an error message
for /phpwiki/themes/MacOS/buttons/de/ telling me that "Seite+l%F6schen.png"
and "Seite+L%F6schen.png" have the same name with different case (i.e. "l"
and "L").  For unix systems this is technically valid but I use windows and
so it is a problem for me.

 

My guess is that the two different names are an accident not deliberate. is
it possible to work out which one is correct and remove the other?

 

Regards,

Charles

 

[Phpwiki-talk] 1.3.11 authentication

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

Joel Sherrill <jo...@OA...> schrieb:
> Reini Urban wrote:
>> Note, that 1.2.x is not in active development, and probably insecure, 
>> but is 10x faster, 10x smaller and has 10x less features than the 
>> current 1.3.x development branch. A new 1.3.11 release will arrive soon.
> 
> I hate to ask this but will 1.3.11 address some of the weirdnesses
> with the authentication?  That has been the only gripe I have
> really had with the rtems wiki (http://www.rtems.com/phpwiki).

Which problems?
I know about httpauth not being working (got better, just the admin_user 
is ignored),
PersonalPages problems (not being able to reproduce).

Most problems so far are related to PASSWORD_LENGTH_MINIMUM = 0
(allowing empty passwords), or non-persistent sessions. (which has 
nothing to do with auth)
I print now a warning for all methods if PASSWORD_LENGTH_MINIMUM is 
violated.

Or using slow USER_AUTH_POLICY = old and having IMAP or other issues 
then (as in previous vesions also).

> Someone mentioned some issues with internationalization.  If you
> are interested in a description, I can get him to write them up.
> I think it starts with his name having a non-ASCI character in it.

I remember. That's another issue I introduced lately and have to fix.
The docs state that all i18n username wordchars are valid, and current 
code disallows them. For security concerns with certain methods.
I'll re-enable them for some auth methods: class specific isValidName()
Bogo and PersonalPage are safe.
-- 
Reini Urban

Re: [Phpwiki-talk] phpwiki-1.2.6 released

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

Reini Urban wrote:

> Note, that 1.2.x is not in active development, and probably insecure, 
> but is 10x faster, 10x smaller and has 10x less features than the 
> current 1.3.x development branch. A new 1.3.11 release will arrive soon.

I hate to ask this but will 1.3.11 address some of the weirdnesses
with the authentication?  That has been the only gripe I have
really had with the rtems wiki (http://www.rtems.com/phpwiki).

Someone mentioned some issues with internationalization.  If you
are interested in a description, I can get him to write them up.
I think it starts with his name having a non-ASCI character in it.

I am not complaining.  Thanks for phpwiki.

-- 
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

[Phpwiki-talk] phpwiki-1.2.6 released

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

phpwiki-1.2.6 is a bugfix for the flatfile database backend only.
Other backends are not affected.

Fixed TitleSearch and Backlinks for flatfile. (Thanks to some user Raj)
Enable MostPopular (hitcount storage) for flatfile.

Note, that 1.2.x is not in active development, and probably insecure, 
but is 10x faster, 10x smaller and has 10x less features than the 
current 1.3.x development branch. A new 1.3.11 release will arrive soon.

I found one more minor issue with serial dumps containing the string
"Mime-Version: 1.0 (Produced by PhpWiki 1.1.x)" which was fixed to carry 
the current version number.

Download:
http://sourceforge.net/project/showfiles.php?group_id=6121&package_id=14187
in some hours at your nearest mirror.

ChangeLog:
2004-12-19 01:02 rurban

	Release 1.2.6
	* lib/db_filesystem: fix GetAllWikiPagenames() which broke
         TitleSearch and Backlinks on flatfile. Thanks to Raj sf bug
         #1079662.
	* lib/db_filesystem: add MostPopular functionality for flatfile.
	* admin/zip.php: bump version number


Reini Urban schrieb:
 > I've made available a patch against 1.2.5 for a needed phpwiki-1.2.6
 > release, which will fix the flatfile database setup.
 > Without this patch, flatfile is not functional for FindPage and 
Backlinks.
 > I've also added the MostPopular feature on flatfile. Just for 
convenience.
 >
 > 
http://sourceforge.net/tracker/index.php?func=detail&aid=1087720&group_id=6121&atid=306121 

 >
 > which fixes this bug:
 > 
http://sourceforge.net/tracker/index.php?func=detail&aid=1079662&group_id=6121&atid=106121 

 >
 > If noone objects I will package a new 1.2.6 release within two days.
 > Thanks a lot to some user named Raj!
-- 
Reini Urban
http://phpwiki.org/

[Phpwiki-talk] 1.2.5 flatfile database patch

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

I've made available a patch against 1.2.5 for a needed phpwiki-1.2.6 
release, which will fix the flatfile database setup.
Without this patch, flatfile is not functional for FindPage and Backlinks.
I've also added the MostPopular feature on flatfile. Just for convenience.
 
http://sourceforge.net/tracker/index.php?func=detail&aid=1087720&group_id=6121&atid=306121
which fixes this bug:
http://sourceforge.net/tracker/index.php?func=detail&aid=1079662&group_id=6121&atid=106121

If noone objects I will package a new 1.2.6 release within two days.
Thanks a lot to some user named Raj!
-- 
Reini Urban
http://phpwiki.org/

[Phpwiki-talk] sf.net services limited for ~10 hrs,

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

Just about 20 min ago they unmounted the sf.net web servers
(project space),
so cvs and cron updates from user accounts will not make it to
the website.
   http://sourceforge.net/docman/display_doc.php?group_id=1&docid=2352

At least almost all of my current fixes were gone through, just the 
recent sidebar logo update is missing.
   http://phpwiki.sourceforge.net/demo/sidebar/
-- 
Reini Urban
http://phpwiki.org/

[Phpwiki-talk] RPC: wiki.listLinks proposal type=empty

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

Testing the new hyperwiki browser (see 
http://phpwiki.sourceforge.net/demo/sidebar/HyperWiki ) led to an xmlrpc 
API problem, discussed at
http://www.jspwiki.org/Wiki.jsp?page=WikiRPCInterfaceListLinks

wiki.listLinks(pagename) return the list of linked pages.
   struct  { page, type, href }
type: "local" or "external"
href: not very well defined.
   minimal: "APageThatDoesNotExist",the pagename, using the baseurl.
   maximal: 
http://server/wiki/index.php?pagename=APageThatDoesNotExist&action=edit 
or APageThatDoesNotExist?action=edit (on USE_PATH_INFO)

How to return empty pages?
Different engines use different edit action
urls. JSPWiki uses
http://www.jspwiki.org/Edit.jsp?page=APageThatDoesNotExist

I don't want hyperwiki to display empty pages, and external pages
neither. Currently a ?action=edit url is returned.

To filter out those empty pages either add a new type=empty
(preferred, since this does not require any hyperwiki.jar changes) or
parse the href string for "[/=][Ee]dit" for jspwiki and phpwiki.
This is too application specific.

Note that the sf.net server is heavily overloaded and the hyperwiki java 
plugin might not react and therefore lock down your browser. On other 
servers it works perfectly.
-- 
Reini Urban
http://phpwiki.org/

[Phpwiki-talk] phpwiki.sf.net/phpwiki11/

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

I enabled the current sf.net wiki content with the current CVS engine 
(again) under the url
   http://phpwiki.sourceforge.net/phpwiki11/

It is the same codebase as the demo branch (symlinked), just using the 
phpwiki-1.3.10 database from the homepage.
This will be switched after the new release soon.
(/phpwiki11/ => /phpwiki/, /phpwiki/ => /phpwiki10/)

Please don't test new features which will not work with the current 
1.3.10 version there, use the demo wiki instead.

I just had to add the new page.cached_html mysql column by doing 
?action=upgrade. So cached_html is not shared amongst both engines.
This also added some new actionpages which should do no harm.

Switching between both version might lead to session problems and 
incompatible session objects.
Delete your phpwiki.sourceforge.net PHPSESSID cookie then.
   Mozilla: Extras => Cookie-Manager
   IE: restart the browser.
-- 
Reini Urban
http://phpwiki.org/

[Phpwiki-talk] old PhpWiki:InterWikiLinks work again

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

I just fixed again the old PhpWiki:InterWikiLinks which used 
PhpWiki:page => http://phpwiki.sourceforge.net/phpwiki/index.php?page
and not the new http://phpwiki.sourceforge.net/phpwiki/page url.

Earlier this year I disabled the .htaccess rewrite rule,
because it lead to multiple requests on the strange sf.net mod_proxy 
farm. Now I hacked the url rewriting in the php starter script, which 
doesn't bother the proxy.

So phpwiki < 1.3.8 interwiki maps link again to the correct page. 
However it is recommended to update your interwiki maps regularly.
-- 
Reini Urban
http://phpwiki.org/

Re: [Phpwiki-talk] How stable/secure is "current"?

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

Jim Popovitch schrieb:
> I see on the sf.net download site that PhpWiki 1.3 (current) hasn't been
> updated since May, while PhpWiki 1.2 (stable) was updated a few days
> ago.  I am in the process of rolling out a new production wiki and I was
> wondering if v1.3 is stable/secure enough or if more focus is still
> given to v1.2.  Any input is appreciated.  Thanks.

Focus is on v1.3 as already noted in the v1.2 release notes.
I even doubt that 1.2 is secure enough, however it is rather stable.
Until recently you were forced to use register_globals=on which is a 
security nightmare. And the workaround allowing register_globals=off was 
not tested well enough against any security issues.

Stock 1.3.10 has some known problems and bugs under special configurations.
httpauth doesn't work, flatfile is broken, using ACL with a '.' page 
might lead to server crashes, certain admin group queries also, ...
See the PhpWikiDemo:ReleaseNotes for details.
   http://phpwiki.sourceforge.net/demo/en/ReleaseNotes

Current CVS has less problems, but there are other new issues I'm 
working on:

pagedata cache: might display wrong author/owner under special
circumstances, pagedata_cache on PageGroupTest/subpage.

blogging, HttpAuth and VisualWiki is under construction.
But just since about two days, for about the next 3 days.
An older CVS checkout will be stable.

action=edit under Apache2 might have problems under certain configurations.
php5 is broken.
-- 
Reini Urban
http://phpwiki.org/

Re: [Phpwiki-talk] root taking over - help!

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

Giovanni Sce schrieb:
>>Date: Thu, 16 Dec 2004 15:33:59 +0100
>>From: Reini Urban <ru...@x-...>
>>To:  gi...@be...
>>CC:  php...@li...
>>Subject: Re: [Phpwiki-talk] root taking over - help!
>>
>>Giovanni Sce schrieb:
>>
>>>today, without have changed anything user "root" is taking over my phpwiki!! :-(
>>
>>First clam down. Nothing happened and happens.
>>
>>
>>>I haven't changed basically anything in the config file ever, I only used to
>>>sign in
>>>(not authenticated) with my WikiUserName and it was lasting for the session.
>>>Now,  at every page loaded next to sign in button says:
>>>" You are signed but not authenticated as root"
>>
>>That means, that you stored a cookie with WIKI_ID=root.
>>You probably signed in once as user "root".
>>To get rid of this informative message just sign as a user.
> 
> 
> Signing in with a different user name as been my first attempt, tried
> it many times, I even have my PersonalPage, it let me sign in, but
> the next time it loads a new page it has "root" again!!
> That's why I'm nervous... and I can't understand why it happens!

So your sessions are not stored (or loaded), and just the WIKI_ID=root 
cookie is loaded. Investigate why your sessions don't work.

You might want to delete this cookie in question also if the name "root" 
troubles you. But this has nothing to do with the unix user root.

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

[Phpwiki-talk] Still root signed in

[Giovanni S. <gi...@be...>]

Hello,
I still have this awful problem with a root user signed in, thanks
Reini,
but, since your suggestion doesn't work, I'm still quite worry of seing
a signed root in my web site, especially since it is on an external host
service.

Did that ever happen to anybody else? Does anybody have any idea what
can it be?

If anybody can be so kind to think about this that I believe can be a
very serious
problem to other site the address is http://www.digitalright.org/wiki.
Try to sign in with any WikiName, click on any link (reload a page) and
you'll
see that your UserName disappear and root appears.

Thanks,

Gio

[Phpwiki-talk] How stable/secure is "current"?

[Jim P. <ji...@ya...>]

I see on the sf.net download site that PhpWiki 1.3 (current) hasn't been
updated since May, while PhpWiki 1.2 (stable) was updated a few days
ago.  I am in the process of rolling out a new production wiki and I was
wondering if v1.3 is stable/secure enough or if more focus is still
given to v1.2.  Any input is appreciated.  Thanks.

-Jim P.

Re: [Phpwiki-talk] root taking over - help!

[Giovanni S. <gi...@be...>]

>
> Date: Thu, 16 Dec 2004 15:33:59 +0100
> From: Reini Urban <ru...@x-...>
> To:  gi...@be...
> CC:  php...@li...
> Subject: Re: [Phpwiki-talk] root taking over - help!
>
> Giovanni Sce schrieb:
> > today, without have changed anything user "root" is taking over my phpwiki!! :-(
>
> First clam down. Nothing happened and happens.
>
> > I haven't changed basically anything in the config file ever, I only used to
> > sign in
> > (not authenticated) with my WikiUserName and it was lasting for the session.
> > Now,  at every page loaded next to sign in button says:
> > " You are signed but not authenticated as root"
>
> That means, that you stored a cookie with WIKI_ID=root.
> You probably signed in once as user "root".
> To get rid of this informative message just sign as a user.

Signing in with a different user name as been my first attempt, tried
it many times, I even have my PersonalPage, it let me sign in, but
the next time it loads a new page it has "root" again!!
That's why I'm nervous... and I can't understand why it happens!

Thanks,

Gio

Re: [Phpwiki-talk] Wiki migration leaves me unable to login

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

Christian Wach schrieb:
> Just wondering how to proceed next...
> 
> The situation is that an install of 1.3.4 was hacked (trashing the
> index.php config settings). The server was taken down, and new
> webspace set up. I put the files on the new server, loaded the db,
> replaced index.php and configured it with the previous settings,
> and all content is now fine.
> 
> However, I can no longer log in either as the administrator or a
> bogouser.

BogoUser login works for me, so admin user login should work also.
Maybe you mixed up ENCRYPTED_PASSWD?

> 
> if (!defined('ADMIN_USER')) define('ADMIN_USER', 'WebMaster');
> if (!defined('ADMIN_PASSWD')) define('ADMIN_PASSWD', '******');
> if (!defined('ENCRYPTED_PASSWD')) define('ENCRYPTED_PASSWD', 'false');
> 
> if (!defined('ALLOW_USER_LOGIN')) define('ALLOW_USER_LOGIN', 'true');
> if (!defined('ALLOW_HTTP_AUTH_LOGIN')) define('ALLOW_HTTP_AUTH_LOGIN', 
> 'false');
> if (!defined('ALLOW_BOGO_LOGIN')) define('ALLOW_BOGO_LOGIN', 'true');
> if (!defined('REQUIRE_SIGNIN_BEFORE_EDIT')) 
> define('REQUIRE_SIGNIN_BEFORE_EDIT', 'true');
> 
> The Wiki is at:
> http://www.bristolwireless.net/
> 
> Any thoughts?
-- 
Reini Urban
http://xarch.tu-graz.ac.at/home/rurban/

[Phpwiki-talk] Wiki migration leaves me unable to login

[Christian W. <ne...@ha...>]

Hi,

Just wondering how to proceed next...

The situation is that an install of 1.3.4 was hacked (trashing the
index.php config settings). The server was taken down, and new
webspace set up. I put the files on the new server, loaded the db,
replaced index.php and configured it with the previous settings,
and all content is now fine.

However, I can no longer log in either as the administrator or a
bogouser.

if (!defined('ADMIN_USER')) define('ADMIN_USER', 'WebMaster');
if (!defined('ADMIN_PASSWD')) define('ADMIN_PASSWD', '******');
if (!defined('ENCRYPTED_PASSWD')) define('ENCRYPTED_PASSWD', 'false');

if (!defined('ALLOW_USER_LOGIN')) define('ALLOW_USER_LOGIN', 'true');
if (!defined('ALLOW_HTTP_AUTH_LOGIN')) define('ALLOW_HTTP_AUTH_LOGIN', 
'false');
if (!defined('ALLOW_BOGO_LOGIN')) define('ALLOW_BOGO_LOGIN', 'true');
if (!defined('REQUIRE_SIGNIN_BEFORE_EDIT')) 
define('REQUIRE_SIGNIN_BEFORE_EDIT', 'true');

The Wiki is at:
http://www.bristolwireless.net/

Any thoughts?

Cheers,

Chris

Re: [Phpwiki-talk] root taking over - help!

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

Giovanni Sce schrieb:
> today, without have changed anything user "root" is taking over my phpwiki!! :-(

First clam down. Nothing happened and happens.

> I haven't changed basically anything in the config file ever, I only used to
> sign in
> (not authenticated) with my WikiUserName and it was lasting for the session.
> Now,  at every page loaded next to sign in button says:
> " You are signed but not authenticated as root"

That means, that you stored a cookie with WIKI_ID=root.
You probably signed in once as user "root".
To get rid of this informative message just sign as a user.

"You are signed but not authenticated as xxx" says that phpwiki thinks 
that you are the user xxx, and will mark your changes in RecentChanges 
with this author_id. Just informative help, which is better than the IP.
Also stored with every page change is the authenticated_id, which is 
empty in this case.

If you need true authentication, "Signed in user xxx" is not enough, you 
might need to provide a password or use a proper CamelCase BogoLogin, 
until you are "Authenticated as user xxx".

> Obviously I didn't create any phpwiki root user!! I did open up my directories,
> bot lib, other executable and the data dir to 777 (I know... bad...).
> 
> I'm very nervous now, what's going on?! How is something/someone signing
> in as root?!
> 
> Thanks for any advice (beside shut down everything!).

no need to do that.
-- 
Reini Urban
http://xarch.tu-graz.ac.at/home/rurban/

Re: [Phpwiki-talk] Wikiblog plugin problem ..

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

Le 15 d=E9c. 04, =E0 16:31, Reini Urban a =E9crit :
>
> And please be patient with the new blogging stuff, I'm just=20
> committing. It will need a couple of some more days until it is=20
> finished.
>
> WikiBlog has some annoying side-effects. mode=3Dadd makes only sense =
if=20
> the user is authenticated if it's his blog. Otherwise it's a comment.
> mode=3Dadd should be checked automatically.
> And some more arguments and features are missing.
>   limit=3D<max. number of displayed blogs>
>   limit per week or month
> Use a full featured editbox for "add", not just the simple textarea.
>

As you're working on this ... I noticed that only admin can modify a=20
post ....
--
Arnaud Fontaine
CRAO
Jabber: sh...@ra...