phpwiki-talk

[Phpwiki-talk] How to deal with "Warning: SAFE MODE Restriction in effect"

[Peter <li...@gm...>]

Hi,


safemode allows to include files only if the user is same for the
including and the inlcluded file.

you can read about php safe mode in the php manual .

>lib/FileFinder.php:161: Warning[2]: SAFE MODE Restriction in effect. =20
>The script whose uid is 2615 is not allowed to access=20
>/home/httpd/cgi-bin/php4/lib/php owned by uid 0

chown all the files in that directory might help, but if you are not
root on that server, this might me not possible.

maybe you can change the include_path.

[Phpwiki-talk] Problems with Backslashes in Pages like this: href="\/themes/

[Peter <li...@gm...>]

Hi,

I am playing around with phpwiki on a windows 2000 with apache2.

I have a problem with all links in pages have a backslash prefixed,
e.g.:

<link rel=3D"stylesheet" title=3D"PhpWiki" type=3D"text/css"
charset=3D"iso-8859-1" href=3D"\/themes/default/phpwiki.css" />

How can i change this? I guess this is only a configuration mistake?=20

What can i do to change this?


THANK you very much!

Peter

Re: [Phpwiki-talk] Username instead of ip address!?

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

Fredrik Linderoth schrieb:
> We have just installed phpwiki 1.3.6 on a Red Hat 7.3 
> system with mysql. 
> 
> We are using htpasswd to give the users access to the 
> site. It seems to work fine but when a user make a 
> change in a file, the ip address is logged as the author. 
> Is it possible to log the username that you are using 
> when you log on (that you have created with htpasswd)?
> 
> Earlier we used phpwiki 1.2.0 and it worked great!     

yes, then we did HTTP auth.

as workaround simply add

if (!empty($_SERVER['PHP_AUTH_USER']))
   $request->_signIn($_SERVER['PHP_AUTH_USER']);

to main() in main.php, after the $request = new WikiRequest(); line.
not tested, but worked in previous wikis of mine.
-- 
Reini Urban
http://xarch.tu-graz.ac.at/home/rurban/

Re: [Phpwiki-talk] copypage functionnality

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

please attach your patch to an email or post it at sf.net.
we will review it and add it to the current CVS.

very good idea indeed!


Jérôme WAGNER schrieb:
> I added a small patch to the sources in order to have a "copypage"
> functionality :
> 
> When doing an action=Edit&copypage=MyPage,
> 
> The resulting textarea is prefilled with the content of MyPage
> 
> This allows, via a patched Calendar plugin for example, to have a single
> prefilled template every time you want to add an entry in the calendar.
> 
> I'd like to know if there already is such a functionality in the wiki, if it
> interests anyone, and how we could to do add such a thing in the code base.
-- 
Reini Urban
http://xarch.tu-graz.ac.at/home/rurban/

Re: [Phpwiki-talk] Username instead of ip address!?

[Bishop <bi...@pl...>]

Hi Fredrik,

> We have just installed phpwiki 1.3.6 on a Red Hat 7.3
> system with mysql.

So far so good...

> We are using htpasswd to give the users access to the
> site. It seems to work fine but when a user make a
> change in a file, the ip address is logged as the author.

First off:  why use htpasswd to access the site when you already have
mysql running?  It would seem that mod_auth_mysql (which I've used in RH73
and RH9, and it works great!) would be a better access control method than
the file-based htpasswd file.

The reason I suggest this is that it would likely also work better for
wiki auth.  Wiki does mysql auth, right?  [checks wiki]  Yeah, sure it
does:

http://phpwiki.sourceforge.net/phpwiki/ExternalAuthentication

I'll be the same table can be used for both auth schemes.  Why not just
unlimit the /phpwiki/ directory with apache, and let phpwiki control the
auth?

> Is it possible to log the username that you are using
> when you log on (that you have created with htpasswd)?

It's an hour of reading and ten minutes of work, but I think that this
problem should be no longer relevant.

> Earlier we used phpwiki 1.2.0 and it worked great!

I'll bet 1.2.0 uses the older method of getting the remote user name - now
I'll bet it's all looking in $_SERVER , seeing nothing, and bailing out
with  using the IP instead.

 - bish

[Phpwiki-talk] Username instead of ip address!?

[Fredrik L. <fre...@el...>]

Hello phpwiki-talk,


We have just installed phpwiki 1.3.6 on a Red Hat 7.3 
system with mysql. 

We are using htpasswd to give the users access to the 
site. It seems to work fine but when a user make a 
change in a file, the ip address is logged as the author. 
Is it possible to log the username that you are using 
when you log on (that you have created with htpasswd)?

Earlier we used phpwiki 1.2.0 and it worked great!     


-- 
Best regards,
 Fredrik                          mailto:fre...@el...

Re: [Phpwiki-talk] Configuration of this list: Reply-To:, acceptance

[John K. <jo...@ke...>]

At 8:44 am +0100 17/12/03, Oliver Betz wrote:
>The important argument is IMHO what you cited from the Mailman docs:
>"...that some posters depend on their own Reply-To: settings to
>convey their valid return address." although I don't know the
>circumstances why one can't set the From: accordingly.

I can think of one that applies directly to mailing lists. Someone 
may subscribe to the list using one address, but want replies to go 
to another address, because:

a) they subscribed address is an old one and they can't be 
bothered/don't wish to subscribe with their new address, but still 
have to POST (From) using the old address

b) they subscribed using a dummy/spamproofed address but want mail to 
go to their real address

c) they post from their work address but want replies to go to their 
home address

d) they use a webmail app such as mali2web, which puts their real POP 
address in the From and their desired 'who I am known as' address in 
the Reply-To

OTOH I hit 'Reply' to your message, spotted it was going to you not 
the list, closed the message, hit cmd-opt-R to Reply-To-All, then had 
to tab back into the 'To' field to remove Oliver Betz so you wouldn't 
get two copies. That's 7 key presses and a whole lot of thinking 
compared to the one brainless key press that I need for all the other 
lists to which I'm subscribed. I have enough thinking to do without 
adding more :(

And I'm not convinced by the 'reply to the sender and let them 
summarise back to the list' argument. Very often a post will go to 
the list, be replied to by several persons and those replies spark 
further replies. Those replies *then* generate further posts, which 
might not have happened if the first round of posts had gone just to 
the original sender. I thought mailing lists were about pooling the 
experience & knowledge of everyone? I'm person A is having a problem, 
person B has probably already solved it, person C is stuck with the 
same problem but has some insight/situation that bears on the matter 
and person D will encounter it in the future. If C posts directly to 
A, and so does B, B doesn't see C's post and can't comment on it, 
answering only A's direct point, not creating a generalised solution 
for when D hits the snag.

John.
-- 
-------------------------------------------
    01274 581519  / 07944 755613
jo...@ke... / http://www.kershaw.org
  AOL johnkershaw / Y! & MSN john_m_kershaw

[Phpwiki-talk] copypage functionnality

[<jw...@fi...>]

Hello,

I added a small patch to the sources in order to have a "copypage"
functionality :

When doing an action=3DEdit&copypage=3DMyPage,

The resulting textarea is prefilled with the content of MyPage

This allows, via a patched Calendar plugin for example, to have a single
prefilled template every time you want to add an entry in the calendar.

I'd like to know if there already is such a functionality in the wiki, =
if it
interests anyone, and how we could to do add such a thing in the code =
base.

Thanx
J=E9r=F4me
-----Message d'origine-----
De=A0: php...@li...
[mailto:php...@li...] De la part de Oliver =
Betz
Envoy=E9=A0: mercredi 17 d=E9cembre 2003 08:44
=C0=A0: php...@li...
Objet=A0: Re: [Phpwiki-talk] Configuration of this list: Reply-To:, =
acceptance

Carsten Klapp wrote:

[...]

> I prefer not to force a Repy-To address. Just remember to hit=20
> "Reply-all" in your email software when replying to a list posting =
(and=20

most people will forget (or even ignore) to delete the poster's=20
address and the poster receives the answer twice.

[...]

> "Reply-To" Munging Considered Harmful
> http://www.unicom.com/pw/reply-to-harmful.html

interestig reading (thanks!), although very elm-centric. Many mail=20
readers don't support an easy way to reply _only_ to the To: address.=20
Pegasus does (if configured correctly), but I simply forget it. Since=20
most replies (should) go to the list, I am still convinced that the=20
list address should be the default offered by the mail reader.

The important argument is IMHO what you cited from the Mailman docs:=20
"...that some posters depend on their own Reply-To: settings to=20
convey their valid return address." although I don't know the=20
circumstances why one can't set the From: accordingly.

Oliver


-------------------------------------------------------
This SF.net email is sponsored by: IBM Linux Tutorials.
Become an expert in LINUX or just sharpen your skills.  Sign up for =
IBM's
Free Linux Tutorials.  Learn everything from the bash shell to sys =
admin.
Click now! http://ads.osdn.com/?ad_id=3D1278&alloc_id=3D3371&op=3Dclick
_______________________________________________
Phpwiki-talk mailing list
Php...@li...
https://lists.sourceforge.net/lists/listinfo/phpwiki-talk

Re: [Phpwiki-talk] Configuration of this list: Reply-To:, acceptance

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

Carsten Klapp wrote:

[...]

> I prefer not to force a Repy-To address. Just remember to hit 
> "Reply-all" in your email software when replying to a list posting (and 

most people will forget (or even ignore) to delete the poster's 
address and the poster receives the answer twice.

[...]

> "Reply-To" Munging Considered Harmful
> http://www.unicom.com/pw/reply-to-harmful.html

interestig reading (thanks!), although very elm-centric. Many mail 
readers don't support an easy way to reply _only_ to the To: address. 
Pegasus does (if configured correctly), but I simply forget it. Since 
most replies (should) go to the list, I am still convinced that the 
list address should be the default offered by the mail reader.

The important argument is IMHO what you cited from the Mailman docs: 
"...that some posters depend on their own Reply-To: settings to 
convey their valid return address." although I don't know the 
circumstances why one can't set the From: accordingly.

Oliver

[Phpwiki-talk] Checkins list replies to talk list - was Re: [Phpwiki-talk] Configuration of this list: Reply-To:, acceptance

[Bishop <bi...@pl...>]

> However I *would* like to add a Reply-To header for only the
> phpwiki-checkins list to make sure followups don't get posted to the
> checkins list, rather to phpwiki-talk instead.

> Carsten

Carsten,

That's a good exception to my normal opinion on it.  I'm totally in
agreement - FWIW - that it's a Good Thing.  The commits lists should be
admin-only-posting as well as replies directed to another list, so that
only the commits will ever be on the commits list.

Hmm.  Now I'll have to toss something into my procmail recipe (package) so
that I can turn OFF the reply-to-munging on incoming mail from the commits
list...

 - bish

Re: [Phpwiki-talk] Configuration of this list: Reply-To:, acceptance

[Carsten K. <car...@us...>]

On Monday, December 15, 2003, at 01:34  am, Bishop wrote:

>> Hello All,
>>
>> wouldn't it be nice if this list would set the Reply-To: to the list
>> address? Many times I forget to correct the address when answering to
>> the list, and the reply goes to the poster instead of the list.
>
> -1
>
> I don't usually write so much mail to so many people, just so that my 
> mail
> isn't soon seen as 'spam.'  Likewise, although I have procmail weeding 
> out
> these reply-to addresses, my preference is also that lists DON'T force
> replies back to the list.  Replying only to the author of a message -
> unless the message specifically should be one addressed to the entire 
> list
> - and having the author of the original messages assemble a follow-up 
> to
> his/her original post in order summarise the responses, helps keep mail
> traffic down while still keeping the information high.  Signal/noise 
> and
> all that.
>
>> And I would also set the list to accept mail only from subscribers
>> due to two reasons: spammers send mail to this list *), and I don't
>> want to send (successfully) by accident with the mail address of my
>> employer.
>
> +1
>
> While that one's a bit of a hassle to force posters to subscribe, it
> avoids a lot of crap posting from spammers who may be wanting to 
> harvest
> brain dead 'away'/'vacation' messages.  A product of the times, setting
> member-only to posts on a list is now almost a required thing.
>
> In short, I'm all about signal-noise ratios.


I prefer not to force a Repy-To address. Just remember to hit 
"Reply-all" in your email software when replying to a list posting (and 
if needed, then delete either the poster's name from the CC, or the 
list name from CC).

However I *would* like to add a Reply-To header for only the 
phpwiki-checkins list to make sure followups don't get posted to the 
checkins list, rather to phpwiki-talk instead.

Further reading:

Quote from Mailman docs on SF:
> There are many reasons not to introduce or override the Reply-To: 
> header.  One is that some posters depend on their own Reply-To: 
> settings to convey their valid return address.  Another is that 
> modifying Reply-To: makes it much more difficult to send private 
> replies.  See 'Reply-To' Munging Considered Harmful for a general 
> discussion of this issue.  See 'Reply-To Munging Considered Useful' 
> for a dissenting opinion.

Reply-To Munging Considered Useful
http://www.metasystema.net/essays/reply-to.mhtml

"Reply-To" Munging Considered Harmful
http://www.unicom.com/pw/reply-to-harmful.html

Carsten

Re: [Phpwiki-talk] Re: [phpwiki-checkins] CVS: phpwiki/lib WikiUserNew.php,NONE,1.1

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

Reini Urban wrote:
> Joby Walker schrieb:
> 
> Well, I'm not so concerned about security with this password issue, 
> since it's only a wiki. nothing serious.

The wiki that I manage is quite critical and contains a lot of data we don't 
want to fall into hostile hands...

 > If I store sensitive data in cookies I do a symeteric encryption with a
 > secret key at the host, generated at install time.
> but it's true that certain pref data shouldn't be stored in cookies: 
> passwd (for security), email (. just the basic prefs for username and 
> layout.
> otherwise the user has to create a homepage.
> okay?

I still wouldn't do it this way.  I would:

Cookie:
Contents = a 64 character hex number [md5(random data1) . md5(random data2)]
SSL = configurable yes/no
Expire = configurable

Server Session Validation:
Cookie Content ID
Browser Used
IP#
Expiration Time

If the cookie points to a valid session then the user is logged into as the 
saved (as a part of the session) username and given the associated saved 
preferences.

This will allow for a more secure "auto-login" process -- if a cookie is 
compromised then it will contain no hard data (encrypted or not) with a fairly 
limited vulnerability window.  And once the session attached to that cookie 
contents has expired -- the data is completely useless.  And allows admins to 
dynamically set the expiration time of sessions (from never to very short times) 
  even after the cookie has been set on the user's computer.

> 
> but then we'll have to fix the login procedure also.
> 
>> On a better note the classes look good.  Having different classes with 
>> common methods will be very helpful for the future of phpwiki.

I absolutely agree.  My quibble is with an implimentation detail not the general 
architecture.  These classes will make things MUCH easier.

jbw

Re: [Phpwiki-talk] Configuration of this list: Reply-To:, acceptance

[Bishop <bi...@pl...>]

> Hello All,
>
> wouldn't it be nice if this list would set the Reply-To: to the list
> address? Many times I forget to correct the address when answering to
> the list, and the reply goes to the poster instead of the list.

-1

I don't usually write so much mail to so many people, just so that my mail
isn't soon seen as 'spam.'  Likewise, although I have procmail weeding out
these reply-to addresses, my preference is also that lists DON'T force
replies back to the list.  Replying only to the author of a message -
unless the message specifically should be one addressed to the entire list
- and having the author of the original messages assemble a follow-up to
his/her original post in order summarise the responses, helps keep mail
traffic down while still keeping the information high.  Signal/noise and
all that.

> And I would also set the list to accept mail only from subscribers
> due to two reasons: spammers send mail to this list *), and I don't
> want to send (successfully) by accident with the mail address of my
> employer.

+1

While that one's a bit of a hassle to force posters to subscribe, it
avoids a lot of crap posting from spammers who may be wanting to harvest
brain dead 'away'/'vacation' messages.  A product of the times, setting
member-only to posts on a list is now almost a required thing.

In short, I'm all about signal-noise ratios.

Re: [Phpwiki-talk] Re: [phpwiki-checkins] CVS: phpwiki/lib WikiUserNew.php,NONE,1.1

[Bishop <bi...@pl...>]

> Bishop schrieb:
>>>Joby Walker schrieb:
>>>>If I am mistaken about what you are storing in the cookie ... then
>>>>ignore.  But I am quite worried about this development.
>>>
>>>Well, I'm not so concerned about security with this password issue,
>>>since it's only a wiki. nothing serious.
>>
>> I've just read the section of code allowing me to use the imap
>> authentication feature, which means my wiki passwords will be the same
>> as
>> my users' imap passwords - therefore the same as their account
>> passwordson
>> my mail server.  The risk of having those passwords stored remotely or
>> passed over an insecure connection is a bit of a concern.
>
> in case of external auth no passwords are stored anywhere.
> it just checks for the correctness of the given username/password.
>
> in case of external prefs (customizable with external auth also), also
> the other prefs are not stored in any page or cookie.

Okay.  as long as the cookie (can be set so that it) doesn't contain any
auth info that can be grabbed from a sniffed HTTP:80 connection, that's
fine.

> in case of loose PagePermissions and homepage stored prefs one could
> look at prefs of other users, with the metadata viewer plugin.

So we know we shouldn't do that.

>> PHPWiki runs well over an SSL connection, right?
>
> PHPWiki runs well over an HTTPS connection, if the images are also on
> HTTPS (no external img src). otherwise you get lot of warnings.

Excellent.  An admin who wants to secure the wiki from shenanigans, then,
should
 - run ssl
 - use imapssl for auth (with that path o' mine)
 - not set loose pagePermissions

> I never did an IMAP connection over a secured connection (SSL, TLS, ...)

That works.  I'm auth'ing to my demo server with usernames/passwords on a
remote imaps server (and tethereal shows it's only accessing port 993; 
not 143).  The patch is tiny, and I'm glad phpwiki uses the standard
imap_open stuff like it should - passing in 993/imaps/noverify or whatnot
(see the patch) works like a dream.

> yet. imap_open does support TLS/SSL if compiled against OpenSSL.
> stunnel is the other possibility:
>    see http://security.fi.infn.it/tools/stunnel/index-en.html
> If this is not possible or the imap server does not support TLS/SSL, the
> given password is passed cleartext to the IMAP server (AUTH=PLAIN), same
> as with every unsecured mail client connection.

Yeah, that's to be expected.  I'm also thankful that the UW people made an
IMAP daemon that the RH people could package into something I can secure
easily, and I'm am doing my part to campaign for only imapS (and pop3S)
among the users on the mail server I use.  8-)

>>>If I store sensitive data in cookies I do a symeteric encryption with a
>>>secret key at the host, generated at install time.
>>
>> Where's that part of the code?  I want to make sure it's being run like
>> it
>> should on %post in the RPM as well.
>
> in other projects of mine. in my tep addons (oscommerce.org) for
> example. not in phpwiki yet.

Okay.  I'll check back if I hear of anything generated at install time, so
that it's generated on installation of the package instead of make-install
portion of the package-building bit, so the keys are all randomly
different.

Re: [Phpwiki-talk] Re: [phpwiki-checkins] CVS: phpwiki/lib WikiUserNew.php,NONE,1.1

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

Bishop schrieb:
>>Joby Walker schrieb:
>>>If I am mistaken about what you are storing in the cookie ... then
>>>ignore.  But I am quite worried about this development.
>>
>>Well, I'm not so concerned about security with this password issue,
>>since it's only a wiki. nothing serious.
> 
> I've just read the section of code allowing me to use the imap
> authentication feature, which means my wiki passwords will be the same as
> my users' imap passwords - therefore the same as their account passwordson
> my mail server.  The risk of having those passwords stored remotely or
> passed over an insecure connection is a bit of a concern.

in case of external auth no passwords are stored anywhere.
it just checks for the correctness of the given username/password.

in case of external prefs (customizable with external auth also), also 
the other prefs are not stored in any page or cookie.

in case of loose PagePermissions and homepage stored prefs one could 
look at prefs of other users, with the metadata viewer plugin.

> PHPWiki runs well over an SSL connection, right?

PHPWiki runs well over an HTTPS connection, if the images are also on 
HTTPS (no external img src). otherwise you get lot of warnings.

I never did an IMAP connection over a secured connection (SSL, TLS, ...) 
yet. imap_open does support TLS/SSL if compiled against OpenSSL.
stunnel is the other possibility:
   see http://security.fi.infn.it/tools/stunnel/index-en.html
If this is not possible or the imap server does not support TLS/SSL, the 
given password is passed cleartext to the IMAP server (AUTH=PLAIN), same 
as with every unsecured mail client connection.

>>If I store sensitive data in cookies I do a symeteric encryption with a
>>secret key at the host, generated at install time.
> 
> Where's that part of the code?  I want to make sure it's being run like it
> should on %post in the RPM as well.

in other projects of mine. in my tep addons (oscommerce.org) for 
example. not in phpwiki yet.

>>but it's true that certain pref data shouldn't be stored in cookies:
>>passwd (for security), email (. just the basic prefs for username and
>>layout.
>>otherwise the user has to create a homepage.
>>okay?

> Okay.  Phew.  Thanks.

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

Re: [Phpwiki-talk] Re: [phpwiki-checkins] CVS: phpwiki/lib WikiUserNew.php,NONE,1.1

[Bishop <bi...@pl...>]

> Joby Walker schrieb:
>> If I am mistaken about what you are storing in the cookie ... then
>> ignore.  But I am quite worried about this development.
>
> Well, I'm not so concerned about security with this password issue,
> since it's only a wiki. nothing serious.

I've just read the section of code allowing me to use the imap
authentication feature, which means my wiki passwords will be the same as
my users' imap passwords - therefore the same as their account passwordson
my mail server.  The risk of having those passwords stored remotely or
passed over an insecure connection is a bit of a concern.

PHPWiki runs well over an SSL connection, right?

> If I store sensitive data in cookies I do a symeteric encryption with a
> secret key at the host, generated at install time.

Where's that part of the code?  I want to make sure it's being run like it
should on %post in the RPM as well.

> but it's true that certain pref data shouldn't be stored in cookies:
> passwd (for security), email (. just the basic prefs for username and
> layout.
> otherwise the user has to create a homepage.
> okay?

Okay.  Phew.  Thanks.

[Phpwiki-talk] Re: [phpwiki-checkins] CVS: phpwiki/lib WikiUserNew.php,NONE,1.1

[Carsten K. <car...@us...>]

On Friday, December 12, 2003, at 10:52  am, Joby Walker wrote:

> Carsten,
>
> This looks good, but as I read this you are storing the 
> username&password (in human readable form) in the contents of a cookie 
> on the end-user's machine. This seems quite bad to me.  SOP, for web 
> sites is to store a cookie with a unique id (UID).  The cookie id plus 
> some unique features of the client (IP, browser, time, etc) are then 
> checked by the server against it's session database and if verified 
> the user is logged in (very similar to Kerberos).  But by storing the 
> username & password in the cookie, it someone reads the cookie they 
> will have complete access to that account.
>
> A quick review of the cookies currently in my broswer shows:
>
> 1) UID's are primarily used -- especially with commercial sites.
> 2) Passwords are not stored in cookies.
> 3) Userid's, if used instead of a UID, are encrypted.
> 4) Very little data is in human readable form -- and none of it is 
> critical info.
>
> If I am mistaken about what you are storing in the cookie ... then 
> ignore.  But I am quite worried about this development.
>
> On a better note the classes look good.  Having different classes with 
> common methods will be very helpful for the future of phpwiki.
>
> jbw
>
> Carsten Klapp wrote:
>
>> Update of /cvsroot/phpwiki/phpwiki/lib
>> In directory sc8-pr-cvs1:/tmp/cvs-serv19754
>> Added Files:
>> 	WikiUserNew.php Log Message:
>> Complete rewrite of WikiUser.php.


Hi Joby,

Thank you for the feedback, I always appreciate it! I finally got my 
own wiki up and running again (see 
http://phpwiki.sourceforge.net/phpwiki/KnownBugs, search for 
OldTextFormattingRules) so the good news is I'll be able to do 
extensive testing on the WikiUserNew stuff before deploying it into 
PhpWiki CVS.

Rest assured, it's always been my intention to make sure the password 
will be stored encrypted, whether in a cookie or within the homepage, 
so long as the PHP module is compiled to allow the function crypt(). 
I'm sure the WikiUserNew.php doesn't completely reflect all this yet in 
its current state, but I'll make sure it does in upcoming versions. :)

As far as storing the password itself (encrypted or not) within a 
cookie for auto-login, I'm not too concerned at the moment, especially 
about encrypting WikiUserIds. As Reini said, "it's only a wiki." It's 
pretty commonly known that UserIds on a wiki are just the UserName.

But if a user were to enable (the upcoming feature) "auto-login", I 
believe for now it should be sufficient enough upon enabling AutoLogin 
to just give the user a quick reminder message that, "anyone could 
potentially log in from that machine when auto-login is enabled" or 
something similar. (Joby, please do remind me later if I somehow forget 
to do this(:). Once banks or other financial institutions decide to 
start using PhpWiki ;) there's no reason why we can't (hopefully, be 
paid to) revisit the code. In that case those sites would definitely be 
using TSL/SSL too; not that it would *completely* alleviate the need 
for internally encrypted passwords but it makes coding some other 
things a little easier.

So rereading your message, I think it would indeed be best to continue 
to use the PHPSESSION cookie stuff wherever possible as you suggest, 
like PhpWiki 1.3.6/7pre currently does, to keep the cookie-passing to a 
minimum until such time as a user actually changes and saves his/her 
UserPreferences. Where the prefs & passwd are stored of course will 
depend on the type of user (AnonUser, BogoUser, PassUser, AdminUser, 
etc.) A little more work to the new code will be needed for all that 
but I think that's the way I'm going to go. And as the NewWikiUser code 
evolves too please continue to let me know if there's anything that 
might need changing or more thought.

Since we're talking about security here, naturally any follow-ups or 
concerns are welcome from anyone: I don't mean to imply 
IKnowEverything/ISeeAll here...

Cheers,
Carsten

[Phpwiki-talk] Re: [phpwiki-checkins] CVS: phpwiki/lib WikiUserNew.php,NONE,1.1

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

Joby Walker schrieb:
> This looks good, but as I read this you are storing the 
> username&password (in human readable form) in the contents of a cookie 
> on the end-user's machine. This seems quite bad to me.  SOP, for web 
> sites is to store a cookie with a unique id (UID).  The cookie id plus 
> some unique features of the client (IP, browser, time, etc) are then 
> checked by the server against it's session database and if verified the 
> user is logged in (very similar to Kerberos).  But by storing the 
> username & password in the cookie, it someone reads the cookie they will 
> have complete access to that account.
> 
> A quick review of the cookies currently in my broswer shows:
> 
> 1) UID's are primarily used -- especially with commercial sites.
> 2) Passwords are not stored in cookies.
> 3) Userid's, if used instead of a UID, are encrypted.
> 4) Very little data is in human readable form -- and none of it is 
> critical info.
> 
> If I am mistaken about what you are storing in the cookie ... then 
> ignore.  But I am quite worried about this development.

Well, I'm not so concerned about security with this password issue, 
since it's only a wiki. nothing serious.
If I store sensitive data in cookies I do a symeteric encryption with a 
secret key at the host, generated at install time.

but it's true that certain pref data shouldn't be stored in cookies: 
passwd (for security), email (. just the basic prefs for username and 
layout.
otherwise the user has to create a homepage.
okay?

but then we'll have to fix the login procedure also.

> On a better note the classes look good.  Having different classes with 
> common methods will be very helpful for the future of phpwiki.
-- 
Reini Urban
http://xarch.tu-graz.ac.at/home/rurban/

[Phpwiki-talk] Boost Your Car's Gas Mileage 27%+.....dunn

[Wendi M. <n7...@ya...>]

FUEL SAVER PRO

This revolutionary device Boosts Gas Mileage 27%+ by helping fuel burn bet=
ter using three patented processes from General Motors.
www.iqkm.org?axel=3D49

PROVEN TECHNOLOGY
A certified U.S. Environmental Protection Agency (EPA) laboratory recently=
 completed tests on the new Fuel Saver. The results were astounding! Maste=
r Service, a subsidiary of Ford Motor Company, also conducted extensive em=
issions testing and obtained similar, unheard of results. The achievements=
 of the Fuel Saver is so noteworthy to the environmental community, that C=
ommercial News has featured it as their cover story in their June, 2000 ed=
ition.

Take a test drive Today - www.iqkm.org?axel=3D49






No more advertisements, thanks - http://www.evkm.org/out5s/pre-rem2e.asp






























mnesmevw 
wfffrjgbtziuqka nieswgsoi

Re: [Phpwiki-talk] non breaking spaces added at the top of the pages ...

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

Le jeu 11/12/2003 =E0 21:51, Carsten Klapp a =E9crit :
> I already found the bug in lib/diff.php but there are a few other =20
> changes I would like make in there before I commit a proper repair to =20
> CVS. Here's a patch as a temporary workaround:
>=20
> Index: diff.php
> =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
> RCS file: /cvsroot/phpwiki/phpwiki/lib/diff.php,v
> retrieving revision 1.44
> diff -U2 -r1.44 diff.php
> --- diff.php    17 Feb 2003 02:17:31 -0000      1.44
> +++ diff.php    11 Dec 2003 20:46:39 -0000
> @@ -49,5 +49,5 @@
>                   continue;
>               if ($word[0] =3D=3D "\n") {
> -                $this->_group .=3D PrintXML(HTML::raw(' '));
> +                $this->_group .=3D " "; //new RawXml(' '); //FIXME:=
 =20
> asXML(HTML::raw(' ')) ???
>                   $this->_flushLine($tag);
>                   $word =3D substr($word, 1);

It seems to work.
I just didn't understand why this happened there in the code ... ;)

And maybe you're aware of the second big bug of all versions post 1.3.4:
RSS is working strangely.
If I try to open the RecentChanges rss feed, I got an empty doc in
mozilla (or any geko based browser).
Straw got also an empty document when fetching the rss.
But wget got a valid rss document ...
(oh ... it doesn't come from the theme. And I have the Fr_fr locale set.
I tried with a dba based wiki and a mysql based wiki)

I wrote a rss reader plugin for phpwiki. When I check the rss feed, it
works but the modified date seems buggy ...
The rss also works in Evolution.

The first time I talked about this bug on the list, someone sent me to
his own wiki running the same version as me : the rss was working fine.

Strange behaviour.

--=20
Arnaud Fontaine
Jabber: sh...@ra...
ICQ: 3504789

Re: [Phpwiki-talk] non breaking spaces added at the top of the pages ...

[Carsten K. <car...@us...>]

On Thursday, December 11, 2003, at 03:15  pm, Arnaud Fontaine wrote:

> Le lun 08/12/2003 =E0 10:57, Arnaud Fontaine a =E9crit :
>> On a wiki running PhpWiki 1.3.6, I've a nice little bug :
>>
>> On some nodes (not all) the diff action adds some nbsp at the very
>> beginning of the generated html page.
>>
>> I first thought it was a problem with the theme I write but it's the
>> same with "default".
>>
>> More : the number of nbsp is not always the same depending of the =20
>> page.
>>
>> Have a look at =20
>> http://innovation.crao.net/index.php/Accueil?action=3Ddiff
>
> It seems no one is interested in this bug ... bug when I check the
> source code of this page, it starts by :
>
> =
           &nbsp=20=

> ;&nbsp;&nbsp;<?xml version=3D"1.0" encoding=3D"iso-8859-1"?>
>
> This makes the page not a valid xml page ... and breaks some browsers.
> --=20
> Arnaud Fontaine
> Jabber: sh...@ra...
> ICQ: 3504789

Hi,
I already found the bug in lib/diff.php but there are a few other =20
changes I would like make in there before I commit a proper repair to =20=

CVS. Here's a patch as a temporary workaround:

Index: diff.php
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
RCS file: /cvsroot/phpwiki/phpwiki/lib/diff.php,v
retrieving revision 1.44
diff -U2 -r1.44 diff.php
--- diff.php    17 Feb 2003 02:17:31 -0000      1.44
+++ diff.php    11 Dec 2003 20:46:39 -0000
@@ -49,5 +49,5 @@
                  continue;
              if ($word[0] =3D=3D "\n") {
-                $this->_group .=3D PrintXML(HTML::raw('&nbsp;'));
+                $this->_group .=3D " "; //new RawXml('&nbsp;'); =
//FIXME: =20
asXML(HTML::raw('&nbsp;')) ???
                  $this->_flushLine($tag);
                  $word =3D substr($word, 1);

Re: [Phpwiki-talk] non breaking spaces added at the top of the pages ...

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

Le lun 08/12/2003 =E0 10:57, Arnaud Fontaine a =E9crit :
> On a wiki running PhpWiki 1.3.6, I've a nice little bug :
>=20
> On some nodes (not all) the diff action adds some nbsp at the very
> beginning of the generated html page.
>=20
> I first thought it was a problem with the theme I write but it's the
> same with "default".
>=20
> More : the number of nbsp is not always the same depending of the page.
>=20
> Have a look at http://innovation.crao.net/index.php/Accueil?action=3Ddiff

It seems no one is interested in this bug ... bug when I check the
source code of this page, it starts by :

            &nb=
sp;&nbsp;<?xml version=3D"1.0" encoding=3D"iso-8859-1"?>

This makes the page not a valid xml page ... and breaks some browsers.
--=20
Arnaud Fontaine
Jabber: sh...@ra...
ICQ: 3504789

[Phpwiki-talk] phpwiki error on Home Page ??

[Dan S. <dan...@ea...>]

All,

Phpwiki has an error on the Home Page. How can a page be repaired? How 
can the Home Page be repaired??

The change history yields:

lib/WikiDB.php(In template 'browse'?)(In template 'body'?)(In template 
'html'?):1377: Fatal[0]: <br 
/>/usr/local/plesk/apache/vhosts/bs-cg.com/httpdocs/cgwiki/lib/WikiDB.php:1377: 
: Assertion failed <br />

The detail view yields:

lib/plugin/_BackendInfo.php(In template 'browse'?)(In template 
'body'?)(In template 'html'?):93: Warning[2]: Invalid argument supplied 
for foreach()

lib/plugin/_BackendInfo.php(In template 'browse'?)(In template 
'body'?)(In template 'html'?):140: Warning[2]: Wrong datatype in ksort() 
call

lib/plugin/_BackendInfo.php(In template 'browse'?)(In template 
'body'?)(In template 'html'?):141: Warning[2]: Invalid argument supplied 
for foreach()

lib/plugin/_BackendInfo.php(In template 'browse'?)(In template 
'body'?)(In template 'html'?):93: Warning[2]: Invalid argument supplied 
for foreach()

lib/plugin/_BackendInfo.php(In template 'browse'?)(In template 
'body'?)(In template 'html'?):140: Warning[2]: Wrong datatype in ksort() 
call

lib/plugin/_BackendInfo.php(In template 'browse'?)(In template 
'body'?)(In template 'html'?):141: Warning[2]: Invalid argument supplied 
for foreach()

Re: [Phpwiki-talk] how to do mysql user authentication with phpwiki 1.3.6?

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

Doncho N. Gunchev schrieb:
>   Hello, I just installed (this morning, now it's 22:00) phpwiki 1.3.6 and am
> trying to figure out how to use mysql authentication.
> I used the AllUsers (?pagename=AllUsers) plugin to check if it sees my users.
> The 'root' user got visible after creating a page named 'root' and changing
> root's preferences. I see no change to wiki 'user' and 'member' tables so I
> added some users by hand, created their 'home pages', tryed diferent
> 'auth_crypt_method's and so on with no luck - users can not login with or
> without separate DB User Authentication.

It's not yet enabled in the CVS version, but we are currently working on it.
-- 
Reini Urban
http://xarch.tu-graz.ac.at/home/rurban/

[Phpwiki-talk] =?GB2312?B?s8/Qxbf+zvGjrMirufrK17zSzcaz9r/J0tTD4rfRz8jX9s341b6joQ==?=

[<xm...@to...>]

尊敬的新老客户：

　　您好，很高兴能为您服务！
   
　　如果您或您的企业想做网站，给我们个机会，绝对让您满意！！！

我司服务项目：网页制作、域名注册、虚拟主机、网站推广、通用网址等；

服务优势：域名注册只收取手续费，虚拟主机租用特惠价；
　　　　　企业及个人均可申请成为我们的代理，获取更大优惠；
          专业网站优惠价制作，精诚打造实力网站，为您节省每一分钱；

特别说明：对于信誉好的企业需要做网站的我司可以不收一分钱先给予做好，
　　　　　满意后再收费。

"高速、稳定、安全、24小时专业服务"是全体恒速达人的服务宗旨，我们郑重承诺：
     1、恒速达主机全部采用最新原装Dell PowerApp互联网应用服务器；
     2、光纤直接接入，主机独享 100M 带宽，同时托管于网通与电信；
     3、恒速达主机全部安装正版Turbolinux或Microsoft操作系统；
     4、采用世界标准的SNMP进行24x7x365 系统监测；
     5、恒速达主机客户一个月内可无条件全额退款；其它按实际余额退款。

虚拟主机我司所推出的套餐组合有以下几种优惠：
  
 1、100M（纯HTML空间）+ 送一国际域名，仅售150元/年
 2、50M空间+50M企业邮局 + 功能全面支持并送一国际域名，仅售248元/年
 3、100MP空间+100M企业邮局 + 功能全面支持并送一国际域名，仅售280元/年 
 4、200MP空间+200M企业邮局 + 功能全面支持并送一国际域名，仅售330元/年

我们承诺24小时为您服务！
  咨询电话:　0592-6026652　/　8667174 / 8345012 / 8919334　/　8375020
      传真:  0592-6026652
  　QQ专线:　40327558 /　13531412　/　33925614
　咨询邮箱:　zz...@to...　
  　
祝: 好运天天有、幸运常伴随!!!
                         
　　　　　　　　　　　　　　　　　　　　　　　　　　　
　　　　　　　　　　　　　　　　　　　　　　　　　　　　恒速达网络