phpwiki-talk

Re: [Phpwiki-talk] Very simple ACL possible?

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

Tom Chance schrieb:
> Can I, using phpwiki 1.3.10, just set it up so that one user can have edit 
> rights across the wiki, but not deletion rights? A very quick hack to the 
> code will suffice, to hardcode this one user in. Any pointers would be 
> appreciated.

I would recommend the latest CVS version, since 1.3.10 had some bugs 
with ACL's.

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

[Phpwiki-talk] Very simple ACL possible?

[Tom C. <li...@to...>]

Hello,

Can I, using phpwiki 1.3.10, just set it up so that one user can have edit 
rights across the wiki, but not deletion rights? A very quick hack to the 
code will suffice, to hardcode this one user in. Any pointers would be 
appreciated.

Regards,
Tom

[Phpwiki-talk] out of memory error

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

Installing PhpWiki 1.3.10 using mysql on a linux machine, I have encountered
two problems:

1) The first time I tried to access the wiki I got nothing. Blank page.
   Poking around, I found the following lines in index.php:

// If any page is empty, comment the if ... line out,
// to force include "lib/main.php".
if (SCRIPT_FILENAME == __FILE__)
    include(dirname(__FILE__)."/lib/main.php");

I commented out the if (...) line, and loaded the page again, it started
loading the wiki, then:

2) I got the following error:

Fatal error: Allowed memory size of 8388608 bytes exhausted at (null):0 (tried to allocate 11520 bytes) in /tmp_amd/buzzer/export/buzzer/1/malcolmr/public_html/systems-wiki/lib/plugin/RssFeed.phpon line 112

Fatal error: Allowed memory size of 8388608 bytes exhausted at (null):0 (tried to allocate 0 bytes) in Unknownon line 0

Malcolm

-- 
Malcolm Ryan - mal...@cs... - http://malcolmr.web.cse.unsw.edu.au

                        "Blessed are the poor in spirit, 
                      for theirs is the kingdom of heaven."     -- Matt 5:3

Re: [Phpwiki-talk] Automatic config rewriter php -> ini

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

One disadvantage: you'll always support two ways (ini and php). This 
requires more code maintenance. I claim you'd be happier if you could 
somehow easily migrate people, so in the end you only support one way. 
For example, offer a tool that takes an index.php and makes an INI file 
out of it. Then this tool can be deprecated and go away after a few 
releases.

In general, supporting fewer ways to do the same thing in the long run 
is good.

Just an idea.

Dan

Joby Walker wrote:

> Matthew Palmer wrote:
>
>> Has anyone made any progress in this area?  The major hold-up for me
>> updating Debian to 1.3.1[01] is that it'll force every PHPWiki user in
>> Debian to rewrite their config files, which is unlikely to make them 
>> jump
>> for joy.
>
>
> I'm a good way toward being done.  Been busy with work, getting a new 
> laptop, and rebuilding my windows server at home.  Once I have the CLI 
> client working and tested I'll commit it.
>
>>
>> I did have one (potential) brain-wave, which would also, as a 
>> side-effect,
>> solve the major cause of complaint against the ini-file system.  Put
>> together code which parses the INI file and writes a config.php full of
>> define()s and whatever else takes your fancy, and source *that* 
>> instead of
>> doing an INI parse every invocation.  Then, just have a bit of code that
>> compares the mtime of config.ini with that of config.php, and rewrite
>> config.php if it's older than config.ini.  The first user to hit the new
>> config file gets a 1-2 second slowdown, maybe, but that can be server 
>> lag,
>> and everyone else gets smokingly fast response times.
>>
>
> Yeah thought of that too.  It'll be an option for the CLI client to 
> build a config.php.  Then if config.php is present it'll use it 
> instead of config.ini.
>
> jbw
>
>
> -------------------------------------------------------
> This SF.Net email is sponsored by The 2004 JavaOne(SM) Conference
> Learn from the experts at JavaOne(SM), Sun's Worldwide Java Developer
> Conference, June 28 - July 1 at the Moscone Center in San Francisco, CA
> REGISTER AND SAVE! http://java.sun.com/javaone/sf Priority Code NWMGYKND
> _______________________________________________
> Phpwiki-talk mailing list
> Php...@li...
> https://lists.sourceforge.net/lists/listinfo/phpwiki-talk

Re: [Phpwiki-talk] new member pmeignen

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

Reini Urban wrote:

> PS:
> I'm considering this for DanFr as well, but at first I have to 
> decouple the wikilens specific stuff more from our core.
> This will affect lib/wikilens, lib/plugin/RateIt, and themes/wikilens.


Reini,

We'd also like very much to be decoupled, it's just not been highest on 
our list. Hearing your thoughts would be appreciated.

We will probably not keep everything in lib/plugin/RateIt.php, because 
we will want separate files for organizing code. (Imagine stuffing all 
of lib into one file!). However, we'd be happy to keep our stuff in a 
separate place, perhaps all in lib/wikilens, or lib/plugin/wikilens. Let 
us know any opinions.

Also, eventually we will pull our stuff out of WikiDB into separate 
files. I agree with you that a RatingsDB can be completely separate from 
the page DB (although maybe defaulted the same).

Also, a question about themes/wikilens. Mike is currently working on 
making it work for us and removing duplicate code from other places. 
However, does that mean that our users (who will want ratings widgets 
for example) can't choose other themes? That seems too bad. Maybe it 
would be cool to have a hook into a 'default'-theme-like place that 
could show up in lots of different themes. This is not a high priority, tho.

Much higher priority is getting the user login, account creation, and 
password management really smooth.

Also, for us, we are interested in versioned "structured data" (fields 
like author and title for a book, location and cost for a restaurant, 
etc.). I will send out a proposal for that soon. For those who are 
worried I am trying to turn Phpwiki into some generic groupware, I say: 
no, versioned (wiki-able!) structured data could be generically useful 
in MANY different domains, plenty of which have nothing to do with 
WikiLens, and it is still very wiki-flavored.

> And I don't have that much time yet to integrate their huge changes 
> right now. Still 2 remaining fatals to catch.


I think it's fine that you postpone integration for more important, core 
things. Making the user stuff really smooth, easy, and reliable would be 
great.

Dan

Re: [Phpwiki-talk] German translation issue

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

On Wed, Jun 16, 2004 at 03:10:58PM +0200, Reini Urban wrote:
> Matthew Palmer schrieb:
> >I'm dealing with the backlog of Debian phpwiki bugs, and I've come across
> >one which doesn't appear to have been dealt with  upstream yet.
> >
> >The problem is a discrepancy between the po translation of 'RecentChanges'
> >and the name of the RecentChanges equivalent in the german pgsrc.  The page
> >name is "FrischeSeiten", while the po translation is "NeuesteAnderungen"
> >(with an accent over the 'A').
> >
> >I don't know German, so I can't comment as to which one is better, but I
> >think the two should certainly have the same name.
> >
> >For the original bug report, see http://bugs.debian.org/245812.
> 
> Sorry, cannot reproduce.
> po/de.po has "Neueste?nderungen" for "RecentChanges".
> Exactly since 1.3.5 (Revision 1.82, Updated translation strings from 
> Helmer Pardun.)
> 
> There still exists locale/de/pgsrc/FrischeSeiten for legacy reasons,
> but the links should all show "Neueste?nderungen".

That's the problem.  The links all point to a page called
"Neueste?nderungen", but the page they should be heading for is
"FrischeSeiten".

- Matt

Re: [Phpwiki-talk] User Auth no longer crashing!

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

John Cole schrieb:
> Now for the current new-install bug list ;-)
> 
> 1) I get the following errors at the top of page when signing in and just
> after signing in.
> 
> lib\WikiUserNew.php:2662: Warning[2]: fsockopen(): php_network_getaddresses:
> gethostbyname failed
> 
> lib\WikiUserNew.php:2662: Warning[2]: fsockopen(): unable to connect to
> uai.com:25

worked around this email verification warning.

> 2) Lots of issues loading a blank wiki on Apache 2.0.48
>   With no pages in the database, it crashes after loading GoogleLink.
> Trying to reload with those pages in, causes a crash after
> FrameIncludePlugin.
> 
>   Deleting the offending pages (assuming they are next alphabetically)
> causes a crash on the next one in line.

...
which php version?

> 3) Warning at end of loading blank wiki on Apache 1.3.31 (everything loads,
> however)
> lib\plugincache-config.php:97: Notice[8]: Undefined index: TEMP

So please define your cache settings.
I will not workaround an ill-configured system, without 
$CacheParams['cache_dir'] and no $_ENV['TEMP']

> 4) Loading new wiki with IIS6 and php as a module, OldTextFormattingRules
> crashes php.  Removing lines 18-21 lets the pgsrc load finish.  

...

> 5) *BIG BUG* You cannot edit a page with Apache 2.0.48 or Apache 1.3.31 or
> IIS 6
> 
> My Apache 1.3.31 reported this in the php error log...
> [16-Jun-2004 12:49:33] PHP Fatal error:  Call to a member function on a
> non-object in c:\program files\apache
> group\apache\htdocs\phpwiki\lib\editpage.php on line 215

fixed.

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

Re: [Phpwiki-talk] Automatic config rewriter php -> ini

[Joby W. <joby@u.washington.edu>]

Matthew Palmer wrote:
> Has anyone made any progress in this area?  The major hold-up for me
> updating Debian to 1.3.1[01] is that it'll force every PHPWiki user in
> Debian to rewrite their config files, which is unlikely to make them jump
> for joy.

I'm a good way toward being done.  Been busy with work, getting a new 
laptop, and rebuilding my windows server at home.  Once I have the CLI 
client working and tested I'll commit it.

> 
> I did have one (potential) brain-wave, which would also, as a side-effect,
> solve the major cause of complaint against the ini-file system.  Put
> together code which parses the INI file and writes a config.php full of
> define()s and whatever else takes your fancy, and source *that* instead of
> doing an INI parse every invocation.  Then, just have a bit of code that
> compares the mtime of config.ini with that of config.php, and rewrite
> config.php if it's older than config.ini.  The first user to hit the new
> config file gets a 1-2 second slowdown, maybe, but that can be server lag,
> and everyone else gets smokingly fast response times.
> 

Yeah thought of that too.  It'll be an option for the CLI client to 
build a config.php.  Then if config.php is present it'll use it instead 
of config.ini.

jbw

[Phpwiki-talk] User Auth no longer crashing!

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

Reini,
  It works!!! Yea!

  I can now authenticate on XP/Apache 2/PHP 4.3.7

  Great Job Reini!

  Now for the current new-install bug list ;-)

1) I get the following errors at the top of page when signing in and just
after signing in.

lib\WikiUserNew.php:2662: Warning[2]: fsockopen(): php_network_getaddresses:
gethostbyname failed

lib\WikiUserNew.php:2662: Warning[2]: fsockopen(): unable to connect to
uai.com:25

2) Lots of issues loading a blank wiki on Apache 2.0.48
  With no pages in the database, it crashes after loading GoogleLink.
Trying to reload with those pages in, causes a crash after
FrameIncludePlugin.

  Deleting the offending pages (assuming they are next alphabetically)
causes a crash on the next one in line.

3) Warning at end of loading blank wiki on Apache 1.3.31 (everything loads,
however)
lib\plugincache-config.php:97: Notice[8]: Undefined index: TEMP

4) Loading new wiki with IIS6 and php as a module, OldTextFormattingRules
crashes php.  Removing lines 18-21 lets the pgsrc load finish.  

5) *BIG BUG* You cannot edit a page with Apache 2.0.48 or Apache 1.3.31 or
IIS 6

My Apache 1.3.31 reported this in the php error log...
[16-Jun-2004 12:49:33] PHP Fatal error:  Call to a member function on a
non-object in c:\program files\apache
group\apache\htdocs\phpwiki\lib\editpage.php on line 215

Making LOTS of progres Reini :-)

Thanks,

John Cole

Re: [Phpwiki-talk] user authentication

[Lisa G. <lc...@sa...>]

I've tried doing group method WIKIPAGE, the only text in the
Administrator's page being

* MyAdminUser

----

CategoryGroup

In which case, although I have no idea how to set MyAdminUser's
password, phpWiki seems to think that it is the password I set in
config.ini for ADMIN_USER (which is a different WikiWord than
MyAdminUser).  If I sign out of my Kerberos login and sign in as
MyAdminUser (using the ADMIN_USER password), then it will revert back to
the Kerberos account on any action.  If I click on one of the
AdminPlugin buttons (i.e. in PhpWikiAdministration), which pops up a
window asking for a password, and I enter the MyAdminUser login, then
PhpWiki just hangs and doesn't change pages to anything.
 
I've also tried having the entry in the Adminstrators page be a valid
Kerberos login, which leads to the old problem of having to relogin
every page.  I've also tried having the group method be a flat file and
run into the same problems.  

I am using version 1.3.10.

I am really stuck, and if it is possible to make this work, I need step
by step instructions for the config.ini and other files.  If it is not
possible to make this work, I will need to use a different wiki,
although I've put in a lot of effort trying to make PhpWiki
authentication work.  


On Wed, 2004-06-16 at 03:19, Reini Urban wrote:
> Lisa Glendenning schrieb:
> > So what authentication method would this admin user be using and how
> > would I reflect this in config.ini?
> 
> Any.
> 
> > 
> > On Tue, 2004-06-15 at 01:00, Reini Urban wrote:
> > 
> >>Lisa Glendenning schrieb:
> >>
> >>
> >>>I am trying to use HttpAuth to authenticate through a Kerberos pop-up
> >>>window.  This is working fine - except for anything requiring
> >>>administrative privileges.  It is basically impossible to log on as the
> >>>administrator.  I have tried making the adminstrator an existing
> >>>Kerberos user and a separate WikiWord.  I've also tried many
> >>>combinations of the user authentication options.  No matter what, the
> >>>adminstrative login won't 'stick'.  Every page asks for the admin login,
> >>>and actions done won't actually take effect (such as unlocking a page). 
> >>>It will default back to the Kerberos login.  Any thoughts?
> >>
> >>You are right. This is an overthought with HttpAuth.
> >>I would suggest to setup an Administrators group and add some user (not 
> >>ADMIN_USER) to this group. This user will have Admin Permissions then, 
> >>but not the special admin login method, which does not work for http 
> >>auth (yet).
> >>
> >>I usually create this page:
> >>CategoryGroup
> >>
> >>* [Administrators]
> >>
> >>and this page:
> >>Administrators
> >>
> >>* MyAdminUser
> >>
> >>----
> >>CategoryGroup
> > 
> > 
> > 
> > 
> 

RE: [Phpwiki-talk] user authentication

[<EAG...@RE...>]

yes it is running.

Thanks Reini....

I add this line in lib/IniConfig.php :

 define('USE_DB_SESSION', false);

and in lib/WikiUserNew.php :

This was fixed in CVS.
Add
include_once(dirname(__FILE__)."/pear/File_Passwd.php");
before that
// "__PHP_Incomplete_Class"
line

Thanks.
-----Mensaje original-----
De: php...@li...
[mailto:php...@li...]En nombre de Reini
Urban
Enviado el: mi=E9rcoles, 16 de junio de 2004 6:25
Para: php...@li...
Asunto: Re: [Phpwiki-talk] user authentication


[CC deleted. we prefer to keep the conversation on the list only. No=20
need to send it personally also]

EAG...@RE... schrieb:
> Setting USE_DB_SESSION=3Dtrue I still have the same problem.
> =20
> Setting USE_DB_SESSION=3Dfalse  I have this error message:
> =20
> *Fatal error*: Cannot instantiate non-existent class: file_passwd in=20
> */usr/local/apache/htdocs/phpwiki-1.3.10/lib/WikiUserNew.php* on line =
*2122*
> Any idea ?

This was fixed in CVS.
Add
include_once(dirname(__FILE__)."/pear/File_Passwd.php");
before that
// "__PHP_Incomplete_Class"
line

>     -----Mensaje original-----
>     *De:* php...@li...
>     [mailto:php...@li...]*En nombre de
>     *Barrow H Kwan
>     *Enviado el:* martes, 15 de junio de 2004 12:17
>     *Para:* Reini Urban <rurban
>     *CC:* php...@li...;
>     php...@li...
>     *Asunto:* Re: [Phpwiki-talk] user authentication
>=20
>=20
>     I have the same problem ( I have posted this few days ago on a
>     different thread but got no answer ).  I use Postgresql to store
>     pages and use file base authentication.   I did try to set
>     USE_DB_SESSION to true ( try to set it to false as well ), but it
>     didn't work ( in fact I got some error when I set it to false ).
>=20
>     Does the authentication really work on phpwiki?  I didn't mean it =
is
>     broken but not work as everyone thought.  ( I don't think login in
>     each page is right ).
>=20
>=20
>=20
>=20
>     *Reini Urban <ru...@x-...>*
>     Sent by: php...@li...
>=20
>     06/15/2004 07:39 AM
>=20
>     =09
>     To
>     =09
>     cc
>     	php...@li...
>     Subject
>     	Re: [Phpwiki-talk] user authentication
>=20
>=20
>     =09
>=20
>=20
>=20
>=20
>=20
>     EAG...@RE... schrieb:
>      > I have the same problem using File authentication, (a file like
>     /etc/shadow) ,
>      > I need login in each page.
>      > Is these solution right for my problem ?
>=20
>     No, you are experienceing lost sessions.
>     You can try to set USE_DB_SESSION true or false, until you find =
the
>     real
>     solution to your problem.
>=20
>      > -----Mensaje original-----
>      > De: php...@li...
>      > [mailto:php...@li...]En nombre de =
Reini
>      > Urban
>      > Enviado el: martes, 15 de junio de 2004 4:00
>      > Para: Lisa Glendenning
>      > CC: php...@li...
>      > Asunto: Re: [Phpwiki-talk] user authentication
>      >
>      > Lisa Glendenning schrieb:
>      >>I am trying to use HttpAuth to authenticate through a Kerberos =
pop-up
>      >>window.  This is working fine - except for anything requiring
>      >>administrative privileges.  It is basically impossible to log =
on
>     as the
>      >>administrator.  I have tried making the adminstrator an =
existing
>      >>Kerberos user and a separate WikiWord.  I've also tried many
>      >>combinations of the user authentication options.  No matter =
what, the
>      >>adminstrative login won't 'stick'.  Every page asks for the =
admin
>     login,
>      >>and actions done won't actually take effect (such as unlocking =
a
>     page).
>      >>It will default back to the Kerberos login.  Any thoughts?
>      >
>      >
>      > You are right. This is an overthought with HttpAuth.
>      > I would suggest to setup an Administrators group and add some
>     user (not
>      > ADMIN_USER) to this group. This user will have Admin =
Permissions
>     then,
>      > but not the special admin login method, which does not work for =
http
>      > auth (yet).
>      >
>      > I usually create this page:
>      > CategoryGroup
>      >
>      > * [Administrators]
>      >
>      > and this page:
>      > Administrators
>      >
>      > * MyAdminUser
>      >
>      > ----
>      > CategoryGroup
>     --=20
>     Reini Urban
>     http://xarch.tu-graz.ac.at/home/rurban/
>=20
>=20
>=20
>     -------------------------------------------------------
>     This SF.Net email is sponsored by The 2004 JavaOne(SM) Conference
>     Learn from the experts at JavaOne(SM), Sun's Worldwide Java =
Developer
>     Conference, June 28 - July 1 at the Moscone Center in San =
Francisco, CA
>     REGISTER AND SAVE! http://java.sun.com/javaone/sf Priority Code =
NWMGYKND
>     _______________________________________________
>     Phpwiki-talk mailing list
>     Php...@li...
>     https://lists.sourceforge.net/lists/listinfo/phpwiki-talk
>=20
> AVISO LEGAL:
> Esta informaci=F3n es privada y confidencial y est=E1 dirigida =
=FAnicamente a=20
> su destinatario. Si usted no es el destinatario original de este =
mensaje=20
> y por este medio pudo acceder a dicha informaci=F3n por favor elimine =
el=20
> mensaje. La distribuci=F3n o copia de este mensaje est=E1 =
estrictamente=20
> prohibida. Esta comunicaci=F3n es s=F3lo para prop=F3sitos de =
informaci=F3n y no=20
> debe ser considerada como propuesta, aceptaci=F3n ni como una =
declaraci=F3n=20
> de voluntad oficial de REPSOL YPF S.A. y/o subsidiarias y/o afiliadas. =

> La transmisi=F3n de e-mails no garantiza que el correo electr=F3nico =
sea=20
> seguro o libre de error. Por consiguiente, no manifestamos que esta=20
> informaci=F3n sea completa o precisa. Toda informaci=F3n est=E1 sujeta =
a=20
> alterarse sin previo aviso.
>=20
> This information is private and confidential and intended for the=20
> recipient only. If you are not the intended recipient of this message=20
> you are hereby notified that any review, dissemination, distribution =
or=20
> copying of this message is strictly prohibited. This communication is=20
> for information purposes only and shall not be regarded neither as a=20
> proposal, acceptance nor as a statement of will or official statement=20
> from REPSOL YPF S.A. and/or subsidiaries and/or affiliates. Email=20
> transmission cannot be guaranteed to be secure or error-free. =
Therefore,=20
> we do not represent that this information is complete or accurate and =
it=20
> should not be relied upon as such. All information is subject to =
change=20
> without notice.
>=20


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



-------------------------------------------------------
This SF.Net email is sponsored by The 2004 JavaOne(SM) Conference
Learn from the experts at JavaOne(SM), Sun's Worldwide Java Developer
Conference, June 28 - July 1 at the Moscone Center in San Francisco, CA
REGISTER AND SAVE! http://java.sun.com/javaone/sf Priority Code NWMGYKND
_______________________________________________
Phpwiki-talk mailing list
Php...@li...
https://lists.sourceforge.net/lists/listinfo/phpwiki-talk


AVISO LEGAL:
Esta informaci=F3n es privada y confidencial y est=E1 dirigida =
=FAnicamente a su destinatario. Si usted no es el destinatario original =
de este mensaje y por este medio pudo acceder a dicha informaci=F3n por =
favor elimine el mensaje. La distribuci=F3n o copia de este mensaje =
est=E1 estrictamente prohibida. Esta comunicaci=F3n es s=F3lo para =
prop=F3sitos de informaci=F3n y no debe ser considerada como propuesta, =
aceptaci=F3n ni como una declaraci=F3n de voluntad oficial de REPSOL YPF =
S.A. y/o subsidiarias y/o afiliadas. La transmisi=F3n de e-mails no =
garantiza que el correo electr=F3nico sea seguro o libre de error. Por =
consiguiente, no manifestamos que esta informaci=F3n sea completa o =
precisa. Toda informaci=F3n est=E1 sujeta a alterarse sin previo aviso.=20

This information is private and confidential and intended for the =
recipient only. If you are not the intended recipient of this message =
you are hereby notified that any review, dissemination, distribution or =
copying of this message is strictly prohibited. This communication is =
for information purposes only and shall not be regarded neither as a =
proposal, acceptance nor as a statement of will or official statement =
from REPSOL YPF S.A. and/or subsidiaries and/or affiliates. Email =
transmission cannot be guaranteed to be secure or error-free. Therefore, =
we do not represent that this information is complete or accurate and it =
should not be relied upon as such. All information is subject to change =
without notice.

[Phpwiki-talk] more new install problems...

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

Hey guys,
  This time I'm on a new physical server :-) Apache 1.3.31/PHP 4.3.7/W2K3
Server

  Here are the problems setting this up so far.

---------------------------
  Loading pgsrc has this error at the bottom (but things seem to work)

lib\plugincache-config.php:97: Notice[8]: Undefined index: TEMP

NOTE:  OldTextFormattingRules does not crash PHP with Apache 1.3.31
---------------------------
  
  Trying to edit gets the following error.  This may be a config error on my
part, I've loaded so many combinations lately I'm getting dizzy :-)

[Tue Jun 15 16:11:57 2004] [error] PHP Fatal error:  Call to a member
function on a non-object in c:\\program files\\apache
group\\apache\\htdocs\\phpwiki\\lib\\editpage.php on line 215
---------------------------

I also have IIS6/PHP4.3.7/W2K3 Server with the following results
Note that you must comment out line 54 in index.php and set USE_PATH_INFO =
FALSE to get phpWiki to work with IIS (at least version 6)

---------------------------  

With IIS6 OldTextFormattingRules crashes php.  No error log is written, so I
don't have much more info than before.

You get the following error when loading pgsrc:
lib\plugincache-config.php:97: Notice[8]: Undefined index: TEMP
--------------------------
And trying to edit crashes php, no error reported, just a blank page.

--------------------------


I'll get the latest versions today as soon as the sf CVS servers let me
(they seem to have had a lot of problems lately).

John

Re: [Phpwiki-talk] Automatic config rewriter php -> ini

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

Matthew Palmer schrieb:
> Has anyone made any progress in this area?  The major hold-up for me
> updating Debian to 1.3.1[01] is that it'll force every PHPWiki user in
> Debian to rewrite their config files, which is unlikely to make them jump
> for joy.

I hoped joby wants to do that, because my time is very limited with 
testing and bug hunting.
It's not really hard to write though.

> I did have one (potential) brain-wave, which would also, as a side-effect,
> solve the major cause of complaint against the ini-file system.  Put
> together code which parses the INI file and writes a config.php full of
> define()s and whatever else takes your fancy, and source *that* instead of
> doing an INI parse every invocation.  Then, just have a bit of code that
> compares the mtime of config.ini with that of config.php, and rewrite
> config.php if it's older than config.ini.  The first user to hit the new
> config file gets a 1-2 second slowdown, maybe, but that can be server lag,
> and everyone else gets smokingly fast response times.

good idea!

> This also means that I can continue (more or less) to let Debian users work
> on their config.php files directly if they have to, and switch to config.ini
> when it suits them.  This, of course, pre-supposes that the defines and such
> for 1.3.10 are very close to those of 1.3.7, but I was careful to leave as
> much of it intact as possible.
> 
> Does this sound like a monumentally stupid, or clever, thing?  

clever.

> I haven't been tracking the addition / renaming of config items, which is the big flaw
> in my plan.  Reini, has there been that much modification to the system such
> that 1.3.7 config.php files would have no chance of working in 1.3.10?

yes, I think there were a lot of such minor and dirty changes.
It broke phpwiki.sf.net/demo for a week or so, because we forgot to 
check an important config variable.

We have now config-default values, and the step after reading in the 
options moved from config.php to IniConfig.php:fix_configs().

The names didn't change at all (besides the new global $charset), but 
the logic changed.
So the config.php dumper should check against config-default.ini before, 
do the fix_config() call and then dump it.
-- 
Reini Urban
http://xarch.tu-graz.ac.at/home/rurban/

Re: [Phpwiki-talk] German translation issue

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

Reini Urban schrieb:
> There still exists locale/de/pgsrc/FrischeSeiten for legacy reasons,
> but the links should all show "NeuesteÄnderungen".
> 
> But I stumbled across another bug with such pagenames.

The above mentioned bug only affected PageDump'ing such foreign names, 
which is fixed now.
Wrong arguments to Button()
-- 
Reini Urban
http://xarch.tu-graz.ac.at/home/rurban/

Re: [Phpwiki-talk] German translation issue

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

Matthew Palmer schrieb:
> I'm dealing with the backlog of Debian phpwiki bugs, and I've come across
> one which doesn't appear to have been dealt with  upstream yet.
> 
> The problem is a discrepancy between the po translation of 'RecentChanges'
> and the name of the RecentChanges equivalent in the german pgsrc.  The page
> name is "FrischeSeiten", while the po translation is "NeuesteAnderungen"
> (with an accent over the 'A').
> 
> I don't know German, so I can't comment as to which one is better, but I
> think the two should certainly have the same name.
> 
> For the original bug report, see http://bugs.debian.org/245812.

Sorry, cannot reproduce.
po/de.po has "NeuesteÄnderungen" for "RecentChanges".
Exactly since 1.3.5 (Revision 1.82, Updated translation strings from 
Helmer Pardun.)

There still exists locale/de/pgsrc/FrischeSeiten for legacy reasons,
but the links should all show "NeuesteÄnderungen".

But I stumbled across another bug with such pagenames.
-- 
Reini Urban
http://xarch.tu-graz.ac.at/home/rurban/

[Phpwiki-talk] Automatic config rewriter php -> ini

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

Has anyone made any progress in this area?  The major hold-up for me
updating Debian to 1.3.1[01] is that it'll force every PHPWiki user in
Debian to rewrite their config files, which is unlikely to make them jump
for joy.

I did have one (potential) brain-wave, which would also, as a side-effect,
solve the major cause of complaint against the ini-file system.  Put
together code which parses the INI file and writes a config.php full of
define()s and whatever else takes your fancy, and source *that* instead of
doing an INI parse every invocation.  Then, just have a bit of code that
compares the mtime of config.ini with that of config.php, and rewrite
config.php if it's older than config.ini.  The first user to hit the new
config file gets a 1-2 second slowdown, maybe, but that can be server lag,
and everyone else gets smokingly fast response times.

This also means that I can continue (more or less) to let Debian users work
on their config.php files directly if they have to, and switch to config.ini
when it suits them.  This, of course, pre-supposes that the defines and such
for 1.3.10 are very close to those of 1.3.7, but I was careful to leave as
much of it intact as possible.

Does this sound like a monumentally stupid, or clever, thing?  I haven't
been tracking the addition / renaming of config items, which is the big flaw
in my plan.  Reini, has there been that much modification to the system such
that 1.3.7 config.php files would have no chance of working in 1.3.10?

- Matt

[Phpwiki-talk] German translation issue

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

I'm dealing with the backlog of Debian phpwiki bugs, and I've come across
one which doesn't appear to have been dealt with  upstream yet.

The problem is a discrepancy between the po translation of 'RecentChanges'
and the name of the RecentChanges equivalent in the german pgsrc.  The page
name is "FrischeSeiten", while the po translation is "NeuesteAnderungen"
(with an accent over the 'A').

I don't know German, so I can't comment as to which one is better, but I
think the two should certainly have the same name.

For the original bug report, see http://bugs.debian.org/245812.

- Matt

[Phpwiki-talk] allow_call_time_pass_reference clean

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

Reini Urban schrieb:
> John Cole schrieb:
>> Reini,
>>   I tried to authenticate and I crashed again, so I just deleted my 
>> dev copy and pulled a new one from CVS.
> 
> BTW: All these errors come from allow_call_time_pass_reference = Off in 
> php.ini. allow_call_time_pass_reference = On is a required php setting 
> for some time now, until we fixed it and php5 is there. But even php5 
> allows to set it on.
> 
> I haven't tested against allow_call_time_pass_reference = Off yet, but 
> now that I'm aware of this problem with newer php's, I can reproduce it 
> easily and I am on the way to fix it in all places. There are a lot!
> 
> The real problem is that all these changes have to be tested with older 
> php versions. This will need some time.
> 
> Any reasonable ISP server with php has this On, otherwise 70% of all 
> existing scripts will bark.

I commited now the fixes for allow_call_time_pass_reference = Off in 
php.ini to CVS.

Most problematic pages which require references, and all dumps worked 
fine so far.
I still have to test older php's and php5.

PhpWiki is now allow_call_time_pass_reference = Off clean,
but several external libraries may not.
In detail these libs look to be affected (not tested):
   * Pear_DB odbc
   * adodb oracle

>> [15-Jun-2004 09:18:46] PHP Warning:  Call-time pass-by-reference has been
>> deprecated - argument passed by value;  If you would like to pass it by
>> reference, modify the declaration of [runtime function name]().  If you
>> would like to enable call-time pass-by-reference, you can set
>> allow_call_time_pass_reference to true in your INI file.  However, future
>> versions may not support this any longer.  in C:\Program Files\Apache
>> Group\Apache2\htdocs\phpwiki\lib\plugin\CreateToc.php on line 226
...
-- 
Reini Urban
http://xarch.tu-graz.ac.at/home/rurban/

Re: [Phpwiki-talk] Still have some problems...

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

John Cole schrieb:
> Reini,
>   I tried to authenticate and I crashed again, so I just deleted my dev copy
> and pulled a new one from CVS.

BTW: All these errors come from allow_call_time_pass_reference = Off in 
php.ini. allow_call_time_pass_reference = On is a required php setting 
for some time now, until we fixed it and php5 is there. But even php5 
allows to set it on.

I haven't tested against allow_call_time_pass_reference = Off yet, but 
now that I'm aware of this problem with newer php's, I can reproduce it 
easily and I am on the way to fix it in all places. There are a lot!

The real problem is that all these changes have to be tested with older 
php versions. This will need some time.

Any reasonable ISP server with php has this On, otherwise 70% of all 
existing scripts will bark.

>   Here is one you can fix though :-)  I erased my database and tried loading
> a virgin wiki and it crashed right after loading the HelloWorldPlugin page.
> 
>   I'm going to test the authentication some more and see if I can get some
> more info on that.  Do you know of any settings that I could use to get some
> more info on where this crash is happening?
> 
> Here is the PHP error log from loading the virgin wiki:
> 
> [15-Jun-2004 09:18:46] PHP Warning:  Call-time pass-by-reference has been
> deprecated - argument passed by value;  If you would like to pass it by
> reference, modify the declaration of [runtime function name]().  If you
> would like to enable call-time pass-by-reference, you can set
> allow_call_time_pass_reference to true in your INI file.  However, future
> versions may not support this any longer.  in C:\Program Files\Apache
> Group\Apache2\htdocs\phpwiki\lib\plugin\CreateToc.php on line 226
> [15-Jun-2004 09:18:46] PHP Warning:  Call-time pass-by-reference has been
> deprecated - argument passed by value;  If you would like to pass it by
> reference, modify the declaration of [runtime function name]().  If you
> would like to enable call-time pass-by-reference, you can set
> allow_call_time_pass_reference to true in your INI file.  However, future
> versions may not support this any longer.  in C:\Program Files\Apache
> Group\Apache2\htdocs\phpwiki\lib\plugin\CreateToc.php on line 226
> [15-Jun-2004 09:18:47] PHP Warning:  Call-time pass-by-reference has been
> deprecated - argument passed by value;  If you would like to pass it by
> reference, modify the declaration of [runtime function name]().  If you
> would like to enable call-time pass-by-reference, you can set
> allow_call_time_pass_reference to true in your INI file.  However, future
> versions may not support this any longer.  in C:\Program Files\Apache
> Group\Apache2\htdocs\phpwiki\lib\plugin\InterWikiSearch.php on line 86
-- 
Reini Urban
http://xarch.tu-graz.ac.at/home/rurban/

Re: [Phpwiki-talk] user authentication

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

[CC deleted. we prefer to keep the conversation on the list only. No 
need to send it personally also]

EAG...@RE... schrieb:
> Setting USE_DB_SESSION=true I still have the same problem.
>  
> Setting USE_DB_SESSION=false  I have this error message:
>  
> *Fatal error*: Cannot instantiate non-existent class: file_passwd in 
> */usr/local/apache/htdocs/phpwiki-1.3.10/lib/WikiUserNew.php* on line *2122*
> Any idea ?

This was fixed in CVS.
Add
include_once(dirname(__FILE__)."/pear/File_Passwd.php");
before that
// "__PHP_Incomplete_Class"
line

>     -----Mensaje original-----
>     *De:* php...@li...
>     [mailto:php...@li...]*En nombre de
>     *Barrow H Kwan
>     *Enviado el:* martes, 15 de junio de 2004 12:17
>     *Para:* Reini Urban <rurban
>     *CC:* php...@li...;
>     php...@li...
>     *Asunto:* Re: [Phpwiki-talk] user authentication
> 
> 
>     I have the same problem ( I have posted this few days ago on a
>     different thread but got no answer ).  I use Postgresql to store
>     pages and use file base authentication.   I did try to set
>     USE_DB_SESSION to true ( try to set it to false as well ), but it
>     didn't work ( in fact I got some error when I set it to false ).
> 
>     Does the authentication really work on phpwiki?  I didn't mean it is
>     broken but not work as everyone thought.  ( I don't think login in
>     each page is right ).
> 
> 
> 
> 
>     *Reini Urban <ru...@x-...>*
>     Sent by: php...@li...
> 
>     06/15/2004 07:39 AM
> 
>     	
>     To
>     	
>     cc
>     	php...@li...
>     Subject
>     	Re: [Phpwiki-talk] user authentication
> 
> 
>     	
> 
> 
> 
> 
> 
>     EAG...@RE... schrieb:
>      > I have the same problem using File authentication, (a file like
>     /etc/shadow) ,
>      > I need login in each page.
>      > Is these solution right for my problem ?
> 
>     No, you are experienceing lost sessions.
>     You can try to set USE_DB_SESSION true or false, until you find the
>     real
>     solution to your problem.
> 
>      > -----Mensaje original-----
>      > De: php...@li...
>      > [mailto:php...@li...]En nombre de Reini
>      > Urban
>      > Enviado el: martes, 15 de junio de 2004 4:00
>      > Para: Lisa Glendenning
>      > CC: php...@li...
>      > Asunto: Re: [Phpwiki-talk] user authentication
>      >
>      > Lisa Glendenning schrieb:
>      >>I am trying to use HttpAuth to authenticate through a Kerberos pop-up
>      >>window.  This is working fine - except for anything requiring
>      >>administrative privileges.  It is basically impossible to log on
>     as the
>      >>administrator.  I have tried making the adminstrator an existing
>      >>Kerberos user and a separate WikiWord.  I've also tried many
>      >>combinations of the user authentication options.  No matter what, the
>      >>adminstrative login won't 'stick'.  Every page asks for the admin
>     login,
>      >>and actions done won't actually take effect (such as unlocking a
>     page).
>      >>It will default back to the Kerberos login.  Any thoughts?
>      >
>      >
>      > You are right. This is an overthought with HttpAuth.
>      > I would suggest to setup an Administrators group and add some
>     user (not
>      > ADMIN_USER) to this group. This user will have Admin Permissions
>     then,
>      > but not the special admin login method, which does not work for http
>      > auth (yet).
>      >
>      > I usually create this page:
>      > CategoryGroup
>      >
>      > * [Administrators]
>      >
>      > and this page:
>      > Administrators
>      >
>      > * MyAdminUser
>      >
>      > ----
>      > CategoryGroup
>     -- 
>     Reini Urban
>     http://xarch.tu-graz.ac.at/home/rurban/
> 
> 
> 
>     -------------------------------------------------------
>     This SF.Net email is sponsored by The 2004 JavaOne(SM) Conference
>     Learn from the experts at JavaOne(SM), Sun's Worldwide Java Developer
>     Conference, June 28 - July 1 at the Moscone Center in San Francisco, CA
>     REGISTER AND SAVE! http://java.sun.com/javaone/sf Priority Code NWMGYKND
>     _______________________________________________
>     Phpwiki-talk mailing list
>     Php...@li...
>     https://lists.sourceforge.net/lists/listinfo/phpwiki-talk
> 
> AVISO LEGAL:
> Esta información es privada y confidencial y está dirigida únicamente a 
> su destinatario. Si usted no es el destinatario original de este mensaje 
> y por este medio pudo acceder a dicha información por favor elimine el 
> mensaje. La distribución o copia de este mensaje está estrictamente 
> prohibida. Esta comunicación es sólo para propósitos de información y no 
> debe ser considerada como propuesta, aceptación ni como una declaración 
> de voluntad oficial de REPSOL YPF S.A. y/o subsidiarias y/o afiliadas. 
> La transmisión de e-mails no garantiza que el correo electrónico sea 
> seguro o libre de error. Por consiguiente, no manifestamos que esta 
> información sea completa o precisa. Toda información está sujeta a 
> alterarse sin previo aviso.
> 
> This information is private and confidential and intended for the 
> recipient only. If you are not the intended recipient of this message 
> you are hereby notified that any review, dissemination, distribution or 
> copying of this message is strictly prohibited. This communication is 
> for information purposes only and shall not be regarded neither as a 
> proposal, acceptance nor as a statement of will or official statement 
> from REPSOL YPF S.A. and/or subsidiaries and/or affiliates. Email 
> transmission cannot be guaranteed to be secure or error-free. Therefore, 
> we do not represent that this information is complete or accurate and it 
> should not be relied upon as such. All information is subject to change 
> without notice.
> 


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

Re: [Phpwiki-talk] user authentication

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

Lisa Glendenning schrieb:
> So what authentication method would this admin user be using and how
> would I reflect this in config.ini?

Any.

> 
> On Tue, 2004-06-15 at 01:00, Reini Urban wrote:
> 
>>Lisa Glendenning schrieb:
>>
>>
>>>I am trying to use HttpAuth to authenticate through a Kerberos pop-up
>>>window.  This is working fine - except for anything requiring
>>>administrative privileges.  It is basically impossible to log on as the
>>>administrator.  I have tried making the adminstrator an existing
>>>Kerberos user and a separate WikiWord.  I've also tried many
>>>combinations of the user authentication options.  No matter what, the
>>>adminstrative login won't 'stick'.  Every page asks for the admin login,
>>>and actions done won't actually take effect (such as unlocking a page). 
>>>It will default back to the Kerberos login.  Any thoughts?
>>
>>You are right. This is an overthought with HttpAuth.
>>I would suggest to setup an Administrators group and add some user (not 
>>ADMIN_USER) to this group. This user will have Admin Permissions then, 
>>but not the special admin login method, which does not work for http 
>>auth (yet).
>>
>>I usually create this page:
>>CategoryGroup
>>
>>* [Administrators]
>>
>>and this page:
>>Administrators
>>
>>* MyAdminUser
>>
>>----
>>CategoryGroup
> 
> 
> 
> 


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

Re: [Phpwiki-talk] user authentication

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

I vote for a carefull review of how the new authentication works (Reini=20
would need to help with some info) and then going and fixing the thing. =20
Just going at the source php files is too time consuming.  So, Reini,=20
would you write us a story, with some details on assumptions, classes=20
and methods (at least main ones)?

Reini put a lot of good work into this, I think, and it'd be good to=20
take this as a starting point and move ahead.  Although, I do expect a=20
few bigger fixes/solutions to have to be rewritten there.

Barrow H Kwan wrote:

>
> I think I have the same error like this and still can't figure out=20
> what is going wrong.
>
> I guess we have to look for different wiki implementation that support=20
> authentication.  like tikiwiki but they have more than what I need :(
>
>
>
>
> *<EAG...@RE...>*
> Sent by: php...@li...
>
> 06/15/2004 11:00 AM
>
> =09
> To
> 	<bh...@th...>, <ru...@x-...>
> cc
> 	<php...@li...>,=20
> <php...@li...>
> Subject
> 	RE: [Phpwiki-talk] user authentication
>
>
>
> =09
>
>
>
>
>
> Setting USE_DB_SESSION=3Dtrue I still have the same problem.
> =20
> Setting USE_DB_SESSION=3Dfalse  I have this error message:
> =20
> *Fatal error*: Cannot instantiate non-existent class: file_passwd in=20
> */usr/local/apache/htdocs/phpwiki-1.3.10/lib/WikiUserNew.php* on line=20
> *2122*
> Any idea ?
> -----Mensaje original-----*
> De:* php...@li...=20
> [mailto:php...@li...]*En nombre de *Barrow=20
> H Kwan*
> Enviado el:* martes, 15 de junio de 2004 12:17*
> Para:* Reini Urban <rurban*
> CC:* php...@li...;=20
> php...@li...*
> Asunto:* Re: [Phpwiki-talk] user authentication
>
>
> I have the same problem ( I have posted this few days ago on a=20
> different thread but got no answer ).  I use Postgresql to store pages=20
> and use file base authentication.   I did try to set USE_DB_SESSION to=20
> true ( try to set it to false as well ), but it didn't work ( in fact=20
> I got some error when I set it to false ).
>
> Does the authentication really work on phpwiki?  I didn't mean it is=20
> broken but not work as everyone thought.  ( I don't think login in=20
> each page is right ).
>
>
>
> *Reini Urban <ru...@x-...>*
> Sent by: php...@li...
>
> 06/15/2004 07:39 AM
>
> =09
> To
> =09
> cc
> 	php...@li...
> Subject
> 	Re: [Phpwiki-talk] user authentication
>
>
>
>
> =09
>
>
>
>
>
>
> EAG...@RE... schrieb:
> > I have the same problem using File authentication, (a file like=20
> /etc/shadow) ,
> > I need login in each page.
> > Is these solution right for my problem ?
>
> No, you are experienceing lost sessions.
> You can try to set USE_DB_SESSION true or false, until you find the rea=
l
> solution to your problem.
>
> > -----Mensaje original-----
> > De: php...@li...
> > [mailto:php...@li...]En nombre de Reini
> > Urban
> > Enviado el: martes, 15 de junio de 2004 4:00
> > Para: Lisa Glendenning
> > CC: php...@li...
> > Asunto: Re: [Phpwiki-talk] user authentication
> >
> > Lisa Glendenning schrieb:
> >>I am trying to use HttpAuth to authenticate through a Kerberos pop-up
> >>window.  This is working fine - except for anything requiring
> >>administrative privileges.  It is basically impossible to log on as t=
he
> >>administrator.  I have tried making the adminstrator an existing
> >>Kerberos user and a separate WikiWord.  I've also tried many
> >>combinations of the user authentication options.  No matter what, the
> >>adminstrative login won't 'stick'.  Every page asks for the admin log=
in,
> >>and actions done won't actually take effect (such as unlocking a page=
).
> >>It will default back to the Kerberos login.  Any thoughts?
> >
> >
> > You are right. This is an overthought with HttpAuth.
> > I would suggest to setup an Administrators group and add some user (n=
ot
> > ADMIN_USER) to this group. This user will have Admin Permissions then=
,
> > but not the special admin login method, which does not work for http
> > auth (yet).
> >
> > I usually create this page:
> > CategoryGroup
> >
> > * [Administrators]
> >
> > and this page:
> > Administrators
> >
> > * MyAdminUser
> >
> > ----
> > CategoryGroup
> --=20
> Reini Urban
> http://xarch.tu-graz.ac.at/home/rurban/
>
>
>
> -------------------------------------------------------
> This SF.Net email is sponsored by The 2004 JavaOne(SM) Conference
> Learn from the experts at JavaOne(SM), Sun's Worldwide Java Developer
> Conference, June 28 - July 1 at the Moscone Center in San Francisco, CA
> REGISTER AND SAVE! http://java.sun.com/javaone/sf Priority Code NWMGYKN=
D
> _______________________________________________
> Phpwiki-talk mailing list
> Php...@li...
> https://lists.sourceforge.net/lists/listinfo/phpwiki-talk
>
> AVISO LEGAL:
> Esta informaci=F3n es privada y confidencial y est=E1 dirigida =FAnicam=
ente=20
> a su destinatario. Si usted no es el destinatario original de este=20
> mensaje y por este medio pudo acceder a dicha informaci=F3n por favor=20
> elimine el mensaje. La distribuci=F3n o copia de este mensaje est=E1=20
> estrictamente prohibida. Esta comunicaci=F3n es s=F3lo para prop=F3sito=
s de=20
> informaci=F3n y no debe ser considerada como propuesta, aceptaci=F3n ni=
=20
> como una declaraci=F3n de voluntad oficial de REPSOL YPF S.A. y/o=20
> subsidiarias y/o afiliadas. La transmisi=F3n de e-mails no garantiza qu=
e=20
> el correo electr=F3nico sea seguro o libre de error. Por consiguiente,=20
> no manifestamos que esta informaci=F3n sea completa o precisa. Toda=20
> informaci=F3n est=E1 sujeta a alterarse sin previo aviso.
>
> This information is private and confidential and intended for the=20
> recipient only. If you are not the intended recipient of this message=20
> you are hereby notified that any review, dissemination, distribution=20
> or copying of this message is strictly prohibited. This communication=20
> is for information purposes only and shall not be regarded neither as=20
> a proposal, acceptance nor as a statement of will or official=20
> statement from REPSOL YPF S.A. and/or subsidiaries and/or affiliates.=20
> Email transmission cannot be guaranteed to be secure or error-free.=20
> Therefore, we do not represent that this information is complete or=20
> accurate and it should not be relied upon as such. All information is=20
> subject to change without notice.
>

RE: [Phpwiki-talk] user authentication

[Barrow H K. <bh...@th...>]

I think I have the same error like this and still can't figure out what is =

going wrong.

I guess we have to look for different wiki implementation that support=20
authentication.  like tikiwiki but they have more than what I need :(





<EAG...@RE...>=20
Sent by: php...@li...
06/15/2004 11:00 AM

To
<bh...@th...>, <ru...@x-...>
cc
<php...@li...>,=20
<php...@li...>
Subject
RE: [Phpwiki-talk] user authentication






Setting USE=5FDB=5FSESSION=3Dtrue I still have the same problem.
=20
Setting USE=5FDB=5FSESSION=3Dfalse  I have this error message:
=20
Fatal error: Cannot instantiate non-existent class: file=5Fpasswd in=20
/usr/local/apache/htdocs/phpwiki-1.3.10/lib/WikiUserNew.php on line 2122
Any idea ?
-----Mensaje original-----
De: php...@li...=20
[mailto:php...@li...]En nombre de Barrow H=20
Kwan
Enviado el: martes, 15 de junio de 2004 12:17
Para: Reini Urban <rurban
CC: php...@li...;=20
php...@li...
Asunto: Re: [Phpwiki-talk] user authentication


I have the same problem ( I have posted this few days ago on a different=20
thread but got no answer ).  I use Postgresql to store pages and use file=20
base authentication.   I did try to set USE=5FDB=5FSESSION to true ( try to=
=20
set it to false as well ), but it didn't work ( in fact I got some error=20
when I set it to false ).=20

Does the authentication really work on phpwiki?  I didn't mean it is=20
broken but not work as everyone thought.  ( I don't think login in each=20
page is right ).=20




Reini Urban <ru...@x-...>=20
Sent by: php...@li...=20
06/15/2004 07:39 AM=20


To

cc
php...@li...=20
Subject
Re: [Phpwiki-talk] user authentication








EAG...@RE... schrieb:
> I have the same problem using File authentication, (a file like=20
/etc/shadow) ,=20
> I need login in each page.
> Is these solution right for my problem ?

No, you are experienceing lost sessions.
You can try to set USE=5FDB=5FSESSION true or false, until you find the rea=
l=20
solution to your problem.

> -----Mensaje original-----
> De: php...@li...
> [mailto:php...@li...]En nombre de Reini
> Urban
> Enviado el: martes, 15 de junio de 2004 4:00
> Para: Lisa Glendenning
> CC: php...@li...
> Asunto: Re: [Phpwiki-talk] user authentication
>
> Lisa Glendenning schrieb:
>>I am trying to use HttpAuth to authenticate through a Kerberos pop-up
>>window.  This is working fine - except for anything requiring
>>administrative privileges.  It is basically impossible to log on as the
>>administrator.  I have tried making the adminstrator an existing
>>Kerberos user and a separate WikiWord.  I've also tried many
>>combinations of the user authentication options.  No matter what, the
>>adminstrative login won't 'stick'.  Every page asks for the admin login,
>>and actions done won't actually take effect (such as unlocking a page).=20
>>It will default back to the Kerberos login.  Any thoughts?
>=20
>=20
> You are right. This is an overthought with HttpAuth.
> I would suggest to setup an Administrators group and add some user (not=20
> ADMIN=5FUSER) to this group. This user will have Admin Permissions then, =

> but not the special admin login method, which does not work for http=20
> auth (yet).
>=20
> I usually create this page:
> CategoryGroup
>=20
> * [Administrators]
>=20
> and this page:
> Administrators
>=20
> * MyAdminUser
>=20
> ----
> CategoryGroup
--=20
Reini Urban
http://xarch.tu-graz.ac.at/home/rurban/



-------------------------------------------------------
This SF.Net email is sponsored by The 2004 JavaOne(SM) Conference
Learn from the experts at JavaOne(SM), Sun's Worldwide Java Developer
Conference, June 28 - July 1 at the Moscone Center in San Francisco, CA
REGISTER AND SAVE! http://java.sun.com/javaone/sf Priority Code NWMGYKND
=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=
=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F
Phpwiki-talk mailing list
Php...@li...
https://lists.sourceforge.net/lists/listinfo/phpwiki-talk

AVISO LEGAL:
Esta informaci=F3n es privada y confidencial y est=E1 dirigida =FAnicamente=
 a su=20
destinatario. Si usted no es el destinatario original de este mensaje y=20
por este medio pudo acceder a dicha informaci=F3n por favor elimine el=20
mensaje. La distribuci=F3n o copia de este mensaje est=E1 estrictamente=20
prohibida. Esta comunicaci=F3n es s=F3lo para prop=F3sitos de informaci=F3n=
 y no=20
debe ser considerada como propuesta, aceptaci=F3n ni como una declaraci=F3n=
 de=20
voluntad oficial de REPSOL YPF S.A. y/o subsidiarias y/o afiliadas. La=20
transmisi=F3n de e-mails no garantiza que el correo electr=F3nico sea segur=
o o=20
libre de error. Por consiguiente, no manifestamos que esta informaci=F3n se=
a=20
completa o precisa. Toda informaci=F3n est=E1 sujeta a alterarse sin previo=
=20
aviso.

This information is private and confidential and intended for the=20
recipient only. If you are not the intended recipient of this message you=20
are hereby notified that any review, dissemination, distribution or=20
copying of this message is strictly prohibited. This communication is for=20
information purposes only and shall not be regarded neither as a proposal, =

acceptance nor as a statement of will or official statement from REPSOL=20
YPF S.A. and/or subsidiaries and/or affiliates. Email transmission cannot=20
be guaranteed to be secure or error-free. Therefore, we do not represent=20
that this information is complete or accurate and it should not be relied=20
upon as such. All information is subject to change without notice.

[Phpwiki-talk] CreatePage page for pgsrc

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

This page has to exist for the CreatePage plugin-form to exist, so it 
would be a good idea to put it in pgsrc. Thanks.

Dan

P.S. I'd be happy to do it if I had developer access to the CVS repo.

% cat phpwiki/pgsrc/CreatePage
Date: Sat, 21 Feb 2004 09:10:48 -0600
Mime-Version: 1.0 (Produced by PhpWiki 1.3.9)
Content-Type: application/x-phpwiki;
  pagename=CreatePage;
  flags="";
  author=DanFr;
  version=5;
  lastmodified=1077376248;
  author_id=206.145.140.55;
  markup=2;
  hits=31;
  charset=iso-8859-1
Content-Transfer-Encoding: binary

<?plugin CreatePage ?>

RE: [Phpwiki-talk] user authentication

[<EAG...@RE...>]

Setting USE_DB_SESSION=3Dtrue I still have the same problem.
=20
Setting USE_DB_SESSION=3Dfalse  I have this error message:
=20
Fatal error: Cannot instantiate non-existent class: file_passwd in =
/usr/local/apache/htdocs/phpwiki-1.3.10/lib/WikiUserNew.php on line 2122

Any idea ?

-----Mensaje original-----
De: php...@li... =
[mailto:php...@li...]En nombre de Barrow H =
Kwan
Enviado el: martes, 15 de junio de 2004 12:17
Para: Reini Urban <rurban
CC: php...@li...; =
php...@li...
Asunto: Re: [Phpwiki-talk] user authentication



I have the same problem ( I have posted this few days ago on a different =
thread but got no answer ).  I use Postgresql to store pages and use =
file base authentication.   I did try to set USE_DB_SESSION to true ( =
try to set it to false as well ), but it didn't work ( in fact I got =
some error when I set it to false ).=20

Does the authentication really work on phpwiki?  I didn't mean it is =
broken but not work as everyone thought.  ( I don't think login in each =
page is right ).=20





Reini Urban <ru...@x-...>=20
Sent by: php...@li...=20


06/15/2004 07:39 AM=20


To

cc
php...@li...=20

Subject
Re: [Phpwiki-talk] user authentication

=09




EAG...@RE... schrieb:
> I have the same problem using File authentication, (a file like =
/etc/shadow) ,=20
> I need login in each page.
> Is these solution right for my problem ?

No, you are experienceing lost sessions.
You can try to set USE_DB_SESSION true or false, until you find the real =

solution to your problem.

> -----Mensaje original-----
> De: php...@li...
> [mailto:php...@li...]En nombre de Reini
> Urban
> Enviado el: martes, 15 de junio de 2004 4:00
> Para: Lisa Glendenning
> CC: php...@li...
> Asunto: Re: [Phpwiki-talk] user authentication
>
> Lisa Glendenning schrieb:
>>I am trying to use HttpAuth to authenticate through a Kerberos pop-up
>>window.  This is working fine - except for anything requiring
>>administrative privileges.  It is basically impossible to log on as =
the
>>administrator.  I have tried making the adminstrator an existing
>>Kerberos user and a separate WikiWord.  I've also tried many
>>combinations of the user authentication options.  No matter what, the
>>adminstrative login won't 'stick'.  Every page asks for the admin =
login,
>>and actions done won't actually take effect (such as unlocking a =
page).=20
>>It will default back to the Kerberos login.  Any thoughts?
>=20
>=20
> You are right. This is an overthought with HttpAuth.
> I would suggest to setup an Administrators group and add some user =
(not=20
> ADMIN_USER) to this group. This user will have Admin Permissions then, =

> but not the special admin login method, which does not work for http=20
> auth (yet).
>=20
> I usually create this page:
> CategoryGroup
>=20
> * [Administrators]
>=20
> and this page:
> Administrators
>=20
> * MyAdminUser
>=20
> ----
> CategoryGroup
--=20
Reini Urban
http://xarch.tu-graz.ac.at/home/rurban/



-------------------------------------------------------
This SF.Net email is sponsored by The 2004 JavaOne(SM) Conference
Learn from the experts at JavaOne(SM), Sun's Worldwide Java Developer
Conference, June 28 - July 1 at the Moscone Center in San Francisco, CA
REGISTER AND SAVE! http://java.sun.com/javaone/sf Priority Code NWMGYKND
_______________________________________________
Phpwiki-talk mailing list
Php...@li...
https://lists.sourceforge.net/lists/listinfo/phpwiki-talk





AVISO LEGAL:
Esta informaci=F3n es privada y confidencial y est=E1 dirigida =
=FAnicamente a su destinatario. Si usted no es el destinatario original =
de este mensaje y por este medio pudo acceder a dicha informaci=F3n por =
favor elimine el mensaje. La distribuci=F3n o copia de este mensaje =
est=E1 estrictamente prohibida. Esta comunicaci=F3n es s=F3lo para =
prop=F3sitos de informaci=F3n y no debe ser considerada como propuesta, =
aceptaci=F3n ni como una declaraci=F3n de voluntad oficial de REPSOL YPF =
S.A. y/o subsidiarias y/o afiliadas. La transmisi=F3n de e-mails no =
garantiza que el correo electr=F3nico sea seguro o libre de error. Por =
consiguiente, no manifestamos que esta informaci=F3n sea completa o =
precisa. Toda informaci=F3n est=E1 sujeta a alterarse sin previo aviso.=20

This information is private and confidential and intended for the =
recipient only. If you are not the intended recipient of this message =
you are hereby notified that any review, dissemination, distribution or =
copying of this message is strictly prohibited. This communication is =
for information purposes only and shall not be regarded neither as a =
proposal, acceptance nor as a statement of will or official statement =
from REPSOL YPF S.A. and/or subsidiaries and/or affiliates. Email =
transmission cannot be guaranteed to be secure or error-free. Therefore, =
we do not represent that this information is complete or accurate and it =
should not be relied upon as such. All information is subject to change =
without notice.