phplib-users — A list for users of phplib to talk / discuss phplib

Rp.: Re: [Phplib-users] Sessions where are we going??

[Giancarlo <gia...@na...>]

 Donncha O Caoimh <don...@tr...> a écrit le  1/7/02 14:23:

>Just a thought for an extra 
>layer of protection for the 
>user:
>The first time the user visits 
>the site we set a cookie on 
>their browser with 
>some very random number 
>as the key. Store the value 
>of the key in the 
>session.
>Each time after that modify 
>the key, set the cookie, and 
>store it in the 
>session. 

That would be heavy on the server. Imagine a multi-frame where each tries to lock&write in very rapid sequence... Maybe  ok for terminal like screens, tellers, mono thread slow stuff. 

Gian

Re: [Phplib-users] AND any client with cookies enabled is driven into 'get' mode

[Peter K. <su...@si...>]

Hello Gian,

to prevent the user providing a new session id to phplib in URL while using session cookies of php4 I 
included the following code to function start() of class session (in session4.inc as of v 1.14 2001/08/29 
07:26:44 richardarcher) before the statement
$ok = session_start();

----- additional code begin ----

      # was a value for name provided in URL?
      if(isset($_GET[$this->name])) {
         $lokid = $_GET[$this->name];
         # does a session with this name exist?
         if(!file_exists(session_save_path().'/sess_'.$lokid)) {
	      # no - user wants to give us a certain session id! forbid it:
            unset($_GET[$this->name]);
         }
      }

---- additional code end ----

After that the following session_start() will produce a new session with a new id.

Is this something you are interested in? The code might be extendable to cover similar attacks by using 
cookies. Also your problem stated below doesn't occur any more.

Of course it is impossible (this way) to discover if the user is authorized to provide an existing session id.

Hope this is helpful

Peter Kursawe

On 29 Jun 2002 at 18:23, Giancarlo wrote:

From:           	Giancarlo <gia...@na...>
To:             	php...@li...
Subject:        	[Phplib-users] AND any client with cookies enabled is driven into 'get' mode
Date sent:      	Sat, 29 Jun 2002 18:23:49 +0200

> I forgot.
> Precedence to the URL is given EVEN IF CLIENT HAS COOKEIS ENABLED, provided 
> he has not already received a cookie from that domain (=first_start)
> 
>  
> 
> ----------  Messaggio inoltrato  ----------
> 
> Subject: real meaning of session.use_cookie and fallback_mode=get
> Date: Sat, 29 Jun 2002 18:19:33 +0200
> From: Giancarlo <gia...@na...>
> To: php...@li...
> 
> The real meaning of these two parallel setting, one of PHP4 php.ini and the
> other of phplib, is:
> 
> If no cookie has been left yet (=start_with), use cookies ONLY if there's no
> user-provided sid in the URL ! Give precedence to URL! And create the id the
> user tells you to create via the URL!
> I dunno if it's clear...
> 
> 
> Gian
> 
> -------------------------------------------------------
> 
> 
> -------------------------------------------------------
> This sf.net email is sponsored by:ThinkGeek
> No, I will not fix your computer.
> http://thinkgeek.com/sf
> _______________________________________________
> Phplib-users mailing list
> Php...@li...
> https://lists.sourceforge.net/lists/listinfo/phplib-users

Re: [Phplib-users] Sessions where are we going??

[Tarique S. <ta...@sa...>]

On Mon, 1 Jul 2002, Donncha O Caoimh wrote:

> Ah.. I see the context of that quote now. I don't think Tarique was arguing 
> that we use phplib without php4 sessions, as he wrote a document explaining 
> how to get that working. He meant that if you attempt to use the 

Err... just to clear the facts a bit - I just maintain the documents -
have re-written parts of it and re-organised them BUT definitely cannot
take the claim of writing the piece in question - the email of the
original author is on the said page

Tarique

-- 
=============================================================
PHP Applications for E-Biz: http://www.sanisoft.com

Indian PHP User Group: http://groups.yahoo.com/group/in-phpug
=============================================================

Re: [Phplib-users] Sessions where are we going??

[Michael C. <mdc...@mi...>]

On Mon, Jul 01, 2002 at 10:37:59AM +0100, Donncha O Caoimh wrote:
> Take a look at this site, which I linked to from my howto last week, it should 
> help solve some of the security issues with php4 sessions.
> 
> http://www.webkreator.com/php/configuration/php-session-security.html
> 
> Basically, each vhost gets its own directory, and even session name. That 
> should help to stop people stealing sessions from one vhost to another. If 
> you can chmod 700 and chown nobody:nobody the directory then local users 
> can't inspect those directories (unless they look at them through a script 
> running as nobody of course but the same applies to using a db as a backend, 
> almost)

From the phpauth docs:

php_admin_value safe_mode 1
php_admin_value open_basedir /home/mdchaney
php_admin_value safe_mode_exec_dir /dev/null
php_admin_value safe_mode_allowed_env_vars PHP_
php_admin_value safe_mode_protected_env_vars LD_LIBRARY_PATH
php_admin_value disable_functions system

You can force PHP to confine itself to one directory, so people can't
use it to view files outside their site.  One should be able to make a
site reasonably secure in this way.

Michael
-- 
Michael Darrin Chaney
mdc...@mi...
http://www.michaelchaney.com/

Re: [Phplib-users] Using a template as the content of another template.

[Layne W. <la...@if...>]

> Does the PHPLib template system allow one template to be
> included into another template?

Yes. As long as you parse the inner template file before parsing the outer
template file you'll be just fine.

---- outer.tpl ---
<html>
<body>

{inner}

</body>
</html>

---- inner.tpl ---
<h1>{title}</h1>

<p>{some_text}</p>

---- example.php
<?php
include "template.inc";
$t = new Template;

$t->set_file("outer", "outer.tpl");
$t->set_file("inner", "inner.tpl");

$t->set_var(array("title" => "An Example", "some_text" => "It's really very
simple once you get the hang of it."));

$t->parse("inner", "inner");
$t->parse("outer", "outer");

$t->p("outer");
?>

Layne Weathers
Ifworld Inc.

Re: [Phplib-users] Sessions where are we going??

[Donncha O C. <don...@tr...>]

But I would use "session.save_path" to define a different directory for e=
ach=20
site.
ie.=20
/tmp/siteA
/tmp/siteB

If you use "safe_mode_include_dir" then each site will not get access to =
the=20
other directories.

Just a thought for an extra layer of protection for the user:
The first time the user visits the site we set a cookie on their browser =
with=20
some very random number as the key. Store the value of the key in the=20
session.
Each time after that modify the key, set the cookie, and store it in the=20
session.=20
If at a later date a black-hat finds a URL then they won't be able to loa=
d an=20
authenticated session because they won't have the extra cookie, or their=20
value will be incorrect.
If a black-hat has compromised the system they can simply modify prepend.=
php3=20
and mail that key to themselves and get in, but probably at that stage=20
they'll have access to all the login details on the db anyway. *shrug*

What do you think?

Donncha.


On Monday 01 July 2002 13:28, Giancarlo wrote:
> > > Donncha O Caoimh wrote:
> > > > Take a look at this site, which I linked to from my howto last we=
ek,
> > > > Basically, each vhost gets its own directory, and even session na=
me.
>
> But php4 session_name counts nothing.
> If siteA and siteB store in the same dir, /tmp,
> a session created by siteA with the URL
>
> http://www.siteA.com/i?PHPSESSID=3Dfoo
>
> can be accessed by siteB with, whose seesion name is 'Peppino', with:
>
> http://www.siteB.com/?Peppino=3Dfoo
>
> because 'PHPSESSID' or 'Peppino' count nothing, in PHP4 session parlanc=
e.
>

Re: [Phplib-users] Sessions where are we going??

[Giancarlo <gia...@na...>]

Il 14:31, luned=EC 1 luglio 2002, Donncha O Caoimh ha scritto:
> Great, thanks for clearing that up. There was a small bit of mixed
> communication! The issue with php4 sessions and the URL is a serious on=
e,
> but using cookies doesn't block it, it only makes it harder for an atta=
cker
> to take over a session. (They create a cookie file.. etc etc)

There makes a lot of difference. Stealing a cookie is difficult, offering=
 a=20
'stealable' one is a lot easier.

And also among 'stealable' ones, there is a difference.

If you know that 'any' id can be created (and thogh re-created), you can =
rely=20
that someone, once let's say has it into his bookmarks, will recreate the=
=20
same id (known to the instiller from the beginning).

If arbitrary id creation is not allowed, the 'instiller' has to have phhp=
lib=20
generate one to him every time, and find a way to pass it again, while st=
ill=20
alive, to the victim. So, not allowing the creation of id is also blockin=
g a=20
good deal of social engineering.

The logic that 'a horse with three legs can still walk, so it's no use'  =
is=20
wrong, because the next leg we cut, there will remain only two, and so on=
=2E

Gian

Re: [Phplib-users] Sessions where are we going??

[Giancarlo <gia...@na...>]

> > Donncha O Caoimh wrote:
> > > Take a look at this site, which I linked to from my howto last week, it
...
> > > Basically, each vhost gets its own directory, and even session name.

But php4 session_name counts nothing.
If siteA and siteB store in the same dir, /tmp, 
a session created by siteA with the URL

http://www.siteA.com/i?PHPSESSID=foo

can be accessed by siteB with, whose seesion name is 'Peppino', with:

http://www.siteB.com/?Peppino=foo

because 'PHPSESSID' or 'Peppino' count nothing, in PHP4 session parlance.

> > But any other vhost can run a php a script that browses there
>
> I know, but they can also run a php script that can access the database and
> read the session data from the db. I honestly think there's only so much

Normally every vhost has its db with its passwords... of course, the other 
site can have a script that displays as txt the local.inc of the other site, 
where the pass is written..


Gian

Re: [Phplib-users] Sessions where are we going??

[Donncha O C. <don...@tr...>]

Great, thanks for clearing that up. There was a small bit of mixed=20
communication! The issue with php4 sessions and the URL is a serious one,=
 but=20
using cookies doesn't block it, it only makes it harder for an attacker t=
o=20
take over a session. (They create a cookie file.. etc etc)

This will be an issue for us so I'll look into it too. I remember your th=
read=20
from a short while ago on the propogation issue..

Donncha.

On Monday 01 July 2002 13:05, Giancarlo wrote:
> Donncha O Caoimh wrote:
> > Err.. we're all in favour of using PHP4 sessions to store phplib sess=
ion
>
> data
>
> > aren't we?
>
> I am not so against PHP4 session storage, as I am against PHP4 session
> propagation.
> Unfortunately the two things go together, are bundled,, unless we resum=
e,
> for Max's session_custom class, the release_token, get_id methods etc t=
hat
> are into phplib.
> That is the real weak point of PHP4 session: the propagation.
> URL has precedence,  user-provided ids make their way, there does not e=
xist
> a 'cookie_only' option (which is the choice thas gives the best guarant=
ees
> available) to block the former.
>
> How many people are aware that if they not set an expire for their auth=
, it
> is accessible for 24 H via a simple url?
> How many use fallback_mode=3D'get' with no expire on auth?
> What are the advantages of letting users create sessions with any value
> they provide?
>
>

Re: [Phplib-users] Sessions where are we going??

[Giancarlo <gia...@na...>]

Donncha O Caoimh wrote:

> Err.. we're all in favour of using PHP4 sessions to store phplib session 
data
> aren't we? 

I am not so against PHP4 session storage, as I am against PHP4 session 
propagation.
Unfortunately the two things go together, are bundled,, unless we resume, for 
Max's session_custom class, the release_token, get_id methods etc that are 
into phplib.
That is the real weak point of PHP4 session: the propagation. 
URL has precedence,  user-provided ids make their way, there does not exist a 
'cookie_only' option (which is the choice thas gives the best guarantees 
available) to block the former.

How many people are aware that if they not set an expire for their auth, it 
is accessible for 24 H via a simple url? 
How many use fallback_mode='get' with no expire on auth?
What are the advantages of letting users create sessions with any value they 
provide?


Gian

Re: [Phplib-users] Sessions where are we going??

[Donncha O C. <don...@tr...>]

Ah.. I see the context of that quote now. I don't think Tarique was argui=
ng=20
that we use phplib without php4 sessions, as he wrote a document explaini=
ng=20
how to get that working. He meant that if you attempt to use the=20
session_start() (and associated PHP4 commands) outside of the framework o=
f=20
phplib then the auth, user and perms functions of phplib won't work. To q=
uote=20
his second example:

session_start();
page_open(array("auth" =3D> "Example_Auth",
                         "perm" =3D> "Example_Perm",
                         "user" =3D> "Example_User"));

Obviously here phplib has no way of "connecting" to the PHP4 session to s=
tore=20
the auth, perm and user information.

His final example lists the standard page_open() call using phplib sessio=
ns,=20
with or without PHP4 sessions as a backend/storage container.

Err.. we're all in favour of using PHP4 sessions to store phplib session =
data=20
aren't we? If you follow the advice listed in the previous webkreator art=
icle=20
mentioned in this thread then it should be as secure as using a database=20
backend.

Donncha.

On Monday 01 July 2002 12:06, Giancarlo wrote:
> > > Donncha O Caoimh wrote:
[snip]
> > > It is interesting, and in facts it clearly states that with auth, t=
he
> > > session is better handled by phplib rather than PHP4.
> >
> > I'm not certain what you mean by that.. but I'm satisfied by what he =
says
>
> It was in facts Tarique's  doc, linked from there, that says that, at
> http://www.sanisoft.com/phplib/manual/php4_sessions.php
> and I fully agree.
>
>    << If you want to use phplib's auth, perms or user variables, it is
> better not to use PHP4's session functions, but only phplib's >>
>

Re: [Phplib-users] Sessions where are we going??

[Giancarlo <gia...@na...>]

> > Donncha O Caoimh wrote:
> > > Take a look at this site, which I linked to from my howto last week, it
> >
> > should
> >
> > > help solve some of the security issues with php4 sessions.
> > >
> > > http://www.webkreator.com/php/configuration/php-session-security.html
> >
> > It is interesting, and in facts it clearly states that with auth, the
> > session is better handled by phplib rather than PHP4.
>
> I'm not certain what you mean by that.. but I'm satisfied by what he says

It was in facts Tarique's  doc, linked from there, that says that, at
http://www.sanisoft.com/phplib/manual/php4_sessions.php
and I fully agree.

   << If you want to use phplib's auth, perms or user variables, it is better
        not to use PHP4's session functions, but only phplib's >>


Gian


> that all reasonable measures can be taken to avoid letting a web based user
> take over a session. (BTW - your idea about cloning a session after
> authentication? excellent.. I wonder if hotmail do something similar when
> they reload their pages several times on login?)
>
> > I found there is a workaround to force cookie_only in php4:
> > defining php.ini
> > session.referer_check='someimpossiblestring'
> > or something, which can force cookies all over in php4, but not on links
> > clicked within an email, 'vause they have no referer.
> >
> > > Basically, each vhost gets its own directory, and even session name.
> > > That should help to stop people stealing sessions from one vhost to
> > > another. If you can chmod 700 and chown nobody:nobody the directory
> > > then local users can't inspect those directories (unless they look at
> > > them through a script running as nobody of course but the same applies
> > > to using a db as a backend, almost)
> >
> > But any other vhost can run a php a script that browses there
>
> I know, but they can also run a php script that can access the database and
> read the session data from the db. I honestly think there's only so much
> you can do before the return on investment on time becomes minimal. You
> could probably only guarantee security if you allow each user to run in a
> chrooted environment where they can only see their own db, their own few
> directories.
>
> umm.. d'you want this to go to the list? I'll resend there (without this
> paragraph) if you do.
>
> Donncha.

Re: [Phplib-users] OOHFORMS

[Tarique S. <ta...@sa...>]

On Mon, 1 Jul 2002, Bertram Simon wrote:
Hello Bertram,

If the field is optional that is you have *not* set minsize then
valid_regex will be used only if the user inputs something in the field

HTH

Tarique


> Hi,
> 
> I've (perhaps) a stupid question about oohforms.inc :
> 
> In most cases I build a form, the input fields are allowed to leave free or
> to fill out (i.e. en optinal email field). If a field is left free, I can't
> use regex and minsize. But if the user write any content, I would like to
> verify the input.
> 
> How can I solve this problem?
> 
> 
> Thank you
> 
> Bertram
> 
> 
> 
> -------------------------------------------------------
> This sf.net email is sponsored by:ThinkGeek
> Welcome to geek heaven.
> http://thinkgeek.com/sf
> _______________________________________________
> Phplib-users mailing list
> Php...@li...
> https://lists.sourceforge.net/lists/listinfo/phplib-users
> 

-- 
=============================================================
PHP Applications for E-Biz: http://www.sanisoft.com

Indian PHP User Group: http://groups.yahoo.com/group/in-phpug
=============================================================

[Phplib-users] OOHFORMS

[Bertram S. <ph...@ag...>]

Hi,

I've (perhaps) a stupid question about oohforms.inc :

In most cases I build a form, the input fields are allowed to leave free or
to fill out (i.e. en optinal email field). If a field is left free, I can't
use regex and minsize. But if the user write any content, I would like to
verify the input.

How can I solve this problem?


Thank you

Bertram

[Phplib-users] OOHFORMS

[Bertram S. <b....@ag...>]

Hi,

I've (perhaps) a stupid question about oohforms.inc :

In most cases I build a form, the input fields are allowed to leave free or
to fill out (i.e. en optinal email field). If a field is left free, I can't
use regex and minsize. But if the user write any content, I would like to
verify the input.

How can I solve this problem?


Thank you

Bertram

Re: [Phplib-users] Sessions where are we going??

[Donncha O C. <don...@tr...>]

Take a look at this site, which I linked to from my howto last week, it s=
hould=20
help solve some of the security issues with php4 sessions.

http://www.webkreator.com/php/configuration/php-session-security.html

Basically, each vhost gets its own directory, and even session name. That=
=20
should help to stop people stealing sessions from one vhost to another. I=
f=20
you can chmod 700 and chown nobody:nobody the directory then local users=20
can't inspect those directories (unless they look at them through a scrip=
t=20
running as nobody of course but the same applies to using a db as a backe=
nd,=20
almost)

Is there a phplib-dev mailing list? Hmm, no, scrap that if there is, the=20
number of people interested in developing the library seems to be low.=20
Perhaps the discussion should happen here.=20
The auth->start() stuff is/was scary and I won't pretend to understand al=
l of=20
it but I'd like to help in some way.

Donncha.


On Saturday 29 June 2002 17:02, Giancarlo wrote:
> Il 17:39, sabato 29 giugno 2002, Matt Williams ha scritto:
> > As we are now well into PHP 4 would it not be better to put the full
> > weight of php4 session capabilitiess into phplib?
>
> IMHO PHP4 session is a scam. There is some unknown reason why it has be=
en
> impossible, for almost two years now, to block creation of user-provide=
d
> sids, and most graviuos, to  have any setting that provides a cookie-on=
ly
> session mamagement.
[snip]

Re: [Phplib-users] Ruminations on the Situation

[Giancarlo <gia...@na...>]

Il 20:28, domenica 30 giugno 2002, Bob Bowker ha scritto:

> the very fact that you can fork the library and name it after yourself =
and
> PUBLISH THE WORK WITHIN THE PHPLIB CVS - that's what is very sad to me =
...

Maybe I have not been clear.=20

I CANNOT PUBLISH THE WORK WITHIN THE PHPLIB CVS=20

because I resigned spontaneously my 'write access' a few days ago, becaus=
e=20
there does not exist a discussion on anything and I don'ty want that.

So, please, don't insist on that.

Gian

>
> Please don't miss the point, Gian - your code may be what everyone want=
s in
> the library, it may be tight, and right ... but self-publishing within =
the
> boundaries of an existing project, IMHO, is not the way to go.  Put the
> patches on your own web site, and submit them to the CVS for considerat=
ion
> for inclusion in the next release, yes ... the fact that you didn't (or
> couldn't, or wouldn't) do it this way is a telling symptom of the issue
> that I called "sad" in the first place.
>
> Bob.
>
> At 11:04 PM 6/29/2002 +0200, you wrote:
> >I have to reply, and I am frank.
> >
> >I have recently resigned my 'write access' as a phplib core developer,=
 so
> >I cannot be accused of imposing anything.
> >So there is NO anarchy.
> >
> >I have been following and contributed to phplib since version 4 or 5, =
and
> >please note that the actual structure of the session->start method has
> >been my idea, I let you imagine how comprehensible was before. That ma=
de
> >extending to php4 session pretty easy.
> >
> >Now I have devised a similar rationalization of $auth->start, which is=
 an
> >example doc of spaghetti code. That nobody can maintain.
> >
> >It will make auth a more maneageable class, in line with modern  nuke =
type
> >needs
> >it is a drop replacement, backwards compatible.
> >
> >For the rest there's nothing than better security, because these thing=
s
> >evolve quick, can you imagine? and there constantly lots of new threat=
s. A
> >library whose core functions are session and authentication cannot be
> >static. Sorry.
> >
> >But it is nothing that should worry those who are not interested. And
> >those who are interested should document and participate, please.
> >And if really nobody is interested then it means all this doesn't mind=
=2E
> >
> >So my choice should clearly let you understand that I am on the user s=
ide,
> >if not ours.
> >
> >Gian
> >
> >  Bob Bowker <bo...@iN...> a =E9crit le  29/6/02 11:08:
> > >It's sad to see what used to
> > >be a very stable, usable
> > >library descend into
> > >chaos, confusion and
> > >anarchy ... people heading
> > >off in their own
> > >directions, claiming the
> > >umbrella of phpLib but
> > >naming their rewrites after
> > >themselves, all with
> > >seemingly no coordination or
> > >direction or vision
> > >whatsoever.  No wonder the
> > >need for PEAR was so
> > >immediately obvious to so
> > >many people - not that PEAR
> > >was the best choice (in many
> > >ways worse than
> > >phpLib), but I really do
> > >understand why the core
> > >PHP developers decided on
> > >something other than
> > >phpLib.
> > >
> > >The CVS is in such a mess
> > >that someone has to write a
> > >how-to and post it on
> > >a personal web site!  Then
> > >Giancarlo writes and releases
> > >several scripts
> > >(Nathan - did I miss the
> > >announcement that he is
> > >now a new "committee of 1"
> > >determining the philosophy
> >
> >I made you aware of facts you ignored.
> >
> > >and direction of the
> > >project?) and there goes
> > >Donncha's roadmap again ...
> > >
> > >Giancarlo, before you
> > >immediately flame me, I
> > >appreciate and admire your
> > >work - and this is nowhere
> > >near "personal".  I just don't
> > >think your
> > >unilateral actions
> >
> >Actions?
> >
> >have a
> >
> > >place in the overall scheme
> > >of things.  We
> > >desperately need someone,
> > >or a group of "someones",
> > >who will coordinate
> > >this project.
> > >
> > >I say this knowing full well
> > >that the immediate
> > >response is "Why don't you
> > >do it, Bob?" and that my
> > >answer is the same as
> > >everyone else's - "I don't
> > >have the time" ... which, I
> > >suppose, in many people's
> > >minds, removes my
> > >right to complain.  But that's
> > >why the subject is
> > >"Ruminations" and not
> > >"Problems" ...
> > >
> > >KK has moved on to other
> > >projects, but his hand on the
> > >tiller and his
> > >vision are sorely missed,
> > >imho.  We've been using
> > >phpLib in our work here
> > >for almost 4 years now, and
> > >in spite of the lack of
> > >"official" progress and
> > >register_globals and PHP4
> > >and all the meanderings of
> > >this past 18 months or
> > >so, we still rely on the library
> > >-- but on our own very
> > >highly modified
> > >version of 7.2 -- on every
> > >site we do ... regardless of
> > >the installation,
> > >regardless of the OS, and
> > >regardless of all the latest
> > >and greatest
> > >MyCodeIsBetter streams
> > >that are cropping up.
> > >
> > >A lot of people have spent
> > >long hours on this library,
> >
> >I have been one of them.
> >
> > >and for their code
> > >(as well as the learning
> > >experience that they've
> > >provided me), I'm very
> > >grateful.  But my company
> > >can't afford to base our
> > >work on something that
> > >is no longer predictably
> > >(please note that I said
> > >"predictably") reliable ...
> >
> >Security is an evolving process.
> >
> > >Above all, after all, and with
> > >personal appreciation --
> > >thanks, KK ...
> > >
> > >Bob.

Re: [Phplib-users] Ruminations on the Situation

[Bob B. <bo...@iN...>]

Gian --

Don't be so defensive ...!  As I said, I appreciate the work EVERYONE has=20
done on phpLib, and that certainly includes you.

My point was not personal - it was rather directed at the situation as it=20
now exists, where anyone (it seems) can re-invent basic parts of the=20
library, name it after themselves, and post it in the CVS - without review=
=20
by anyone as to its compliance with the rest of the code, its suitability=20
to purpose, its stability, or even its concurrence with any "master=20
plan".  This now happens because, sadly, no one is running the show any=
 more.

Your auth scheme is quite possibly the way to go ... but has anyone (as KK=
=20
et al used to do in the "old days") actually spelled out what the "way to=20
go" really is?  Has anyone thought through the near- and long-term goals=20
...?  You've patched the library for yourself and published the work ...=20
the very fact that you can fork the library and name it after yourself and=
=20
PUBLISH THE WORK WITHIN THE PHPLIB CVS - that's what is very sad to me ...

Please don't miss the point, Gian - your code may be what everyone wants in=
=20
the library, it may be tight, and right ... but self-publishing within the=
=20
boundaries of an existing project, IMHO, is not the way to go.  Put the=20
patches on your own web site, and submit them to the CVS for consideration=
=20
for inclusion in the next release, yes ... the fact that you didn't (or=20
couldn't, or wouldn't) do it this way is a telling symptom of the issue=20
that I called "sad" in the first place.

Bob.

At 11:04 PM 6/29/2002 +0200, you wrote:
>I have to reply, and I am frank.
>
>I have recently resigned my 'write access' as a phplib core developer, so=
=20
>I cannot be accused of imposing anything.
>So there is NO anarchy.
>
>I have been following and contributed to phplib since version 4 or 5, and=
=20
>please note that the actual structure of the session->start method has=20
>been my idea, I let you imagine how comprehensible was before. That made=20
>extending to php4 session pretty easy.
>
>Now I have devised a similar rationalization of $auth->start, which is an=
=20
>example doc of spaghetti code. That nobody can maintain.
>
>It will make auth a more maneageable class, in line with modern  nuke type=
=20
>needs
>it is a drop replacement, backwards compatible.
>
>For the rest there's nothing than better security, because these things=20
>evolve quick, can you imagine? and there constantly lots of new threats. A=
=20
>library whose core functions are session and authentication cannot be=20
>static. Sorry.
>
>But it is nothing that should worry those who are not interested. And=20
>those who are interested should document and participate, please.
>And if really nobody is interested then it means all this doesn't mind.
>
>So my choice should clearly let you understand that I am on the user side,=
=20
>if not ours.
>
>Gian
>
>
>  Bob Bowker <bo...@iN...> a =E9crit le  29/6/02 11:08:
>
> >It's sad to see what used to
> >be a very stable, usable
> >library descend into
> >chaos, confusion and
> >anarchy ... people heading
> >off in their own
> >directions, claiming the
> >umbrella of phpLib but
> >naming their rewrites after
> >themselves, all with
> >seemingly no coordination or
> >direction or vision
> >whatsoever.  No wonder the
> >need for PEAR was so
> >immediately obvious to so
> >many people - not that PEAR
> >was the best choice (in many
> >ways worse than
> >phpLib), but I really do
> >understand why the core
> >PHP developers decided on
> >something other than
> >phpLib.
> >
> >The CVS is in such a mess
> >that someone has to write a
> >how-to and post it on
> >a personal web site!  Then
> >Giancarlo writes and releases
> >several scripts
> >(Nathan - did I miss the
> >announcement that he is
> >now a new "committee of 1"
> >determining the philosophy
>
>I made you aware of facts you ignored.
>
> >and direction of the
> >project?) and there goes
> >Donncha's roadmap again ...
> >
> >Giancarlo, before you
> >immediately flame me, I
> >appreciate and admire your
> >work - and this is nowhere
> >near "personal".  I just don't
> >think your
> >unilateral actions
>
>Actions?
>
>have a
> >place in the overall scheme
> >of things.  We
> >desperately need someone,
> >or a group of "someones",
> >who will coordinate
> >this project.
> >
> >I say this knowing full well
> >that the immediate
> >response is "Why don't you
> >do it, Bob?" and that my
> >answer is the same as
> >everyone else's - "I don't
> >have the time" ... which, I
> >suppose, in many people's
> >minds, removes my
> >right to complain.  But that's
> >why the subject is
> >"Ruminations" and not
> >"Problems" ...
> >
> >KK has moved on to other
> >projects, but his hand on the
> >tiller and his
> >vision are sorely missed,
> >imho.  We've been using
> >phpLib in our work here
> >for almost 4 years now, and
> >in spite of the lack of
> >"official" progress and
> >register_globals and PHP4
> >and all the meanderings of
> >this past 18 months or
> >so, we still rely on the library
> >-- but on our own very
> >highly modified
> >version of 7.2 -- on every
> >site we do ... regardless of
> >the installation,
> >regardless of the OS, and
> >regardless of all the latest
> >and greatest
> >MyCodeIsBetter streams
> >that are cropping up.
> >
> >A lot of people have spent
> >long hours on this library,
>
>I have been one of them.
>
> >and for their code
> >(as well as the learning
> >experience that they've
> >provided me), I'm very
> >grateful.  But my company
> >can't afford to base our
> >work on something that
> >is no longer predictably
> >(please note that I said
> >"predictably") reliable ...
>
>Security is an evolving process.
>
> >
> >Above all, after all, and with
> >personal appreciation --
> >thanks, KK ...
> >
> >Bob.

[Phplib-users] Using a template as the content of another template.

[Joe C. <jco...@co...>]

Hello,

I just started using PHPLib about a week ago. I really like the template 
feature, it definitely works as advertised. I do however have one question 
that was not immediately evident from the documentation or mailing list 
archives.

Does the PHPLib template system allow one template to be included into 
another template? For example, I have defined an overall site template that 
creates the general layout of my page. The only variable defined is 
{Content}. The idea then is to have Content filled out by information from 
a database or some separate file. This works great, but now I want to add a 
form to the site. Can I replace {Content} with the contents of another 
template that defined the page form or would it be better to generate the 
form programmatically from PHP?

Thanks in advance,
Joe Cotellese

[Phplib-users] Ruminations on the Situation

[Bob B. <bo...@iN...>]

It's sad to see what used to be a very stable, usable library descend into 
chaos, confusion and anarchy ... people heading off in their own 
directions, claiming the umbrella of phpLib but naming their rewrites after 
themselves, all with seemingly no coordination or direction or vision 
whatsoever.  No wonder the need for PEAR was so immediately obvious to so 
many people - not that PEAR was the best choice (in many ways worse than 
phpLib), but I really do understand why the core PHP developers decided on 
something other than phpLib.

The CVS is in such a mess that someone has to write a how-to and post it on 
a personal web site!  Then Giancarlo writes and releases several scripts 
(Nathan - did I miss the announcement that he is now a new "committee of 1" 
determining the philosophy and direction of the project?) and there goes 
Donncha's roadmap again ...

Giancarlo, before you immediately flame me, I appreciate and admire your 
work - and this is nowhere near "personal".  I just don't think your 
unilateral actions have a place in the overall scheme of things.  We 
desperately need someone, or a group of "someones", who will coordinate 
this project.

I say this knowing full well that the immediate response is "Why don't you 
do it, Bob?" and that my answer is the same as everyone else's - "I don't 
have the time" ... which, I suppose, in many people's minds, removes my 
right to complain.  But that's why the subject is "Ruminations" and not 
"Problems" ...

KK has moved on to other projects, but his hand on the tiller and his 
vision are sorely missed, imho.  We've been using phpLib in our work here 
for almost 4 years now, and in spite of the lack of "official" progress and 
register_globals and PHP4 and all the meanderings of this past 18 months or 
so, we still rely on the library -- but on our own very highly modified 
version of 7.2 -- on every site we do ... regardless of the installation, 
regardless of the OS, and regardless of all the latest and greatest 
MyCodeIsBetter streams that are cropping up.

A lot of people have spent long hours on this library, and for their code 
(as well as the learning experience that they've provided me), I'm very 
grateful.  But my company can't afford to base our work on something that 
is no longer predictably (please note that I said "predictably") reliable ...

Above all, after all, and with personal appreciation -- thanks, KK ...

Bob.

[Phplib-users] AND any client with cookies enabled is driven into 'get' mode

[Giancarlo <gia...@na...>]

I forgot.
Precedence to the URL is given EVEN IF CLIENT HAS COOKEIS ENABLED, provided 
he has not already received a cookie from that domain (=first_start)

 

----------  Messaggio inoltrato  ----------

Subject: real meaning of session.use_cookie and fallback_mode=get
Date: Sat, 29 Jun 2002 18:19:33 +0200
From: Giancarlo <gia...@na...>
To: php...@li...

The real meaning of these two parallel setting, one of PHP4 php.ini and the
other of phplib, is:

If no cookie has been left yet (=start_with), use cookies ONLY if there's no
user-provided sid in the URL ! Give precedence to URL! And create the id the
user tells you to create via the URL!
I dunno if it's clear...


Gian

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

[Phplib-users] real meaning of session.use_cookie and fallback_mode=get

[Giancarlo <gia...@na...>]

The real meaning of these two parallel setting, one of PHP4 php.ini and the 
other of phplib, is:

If no cookie has been left yet (=start_with), use cookies ONLY if there's no 
user-provided sid in the URL ! Give precedence to URL! And create the id the 
user tells you to create via the URL!
I dunno if it's clear...


Gian

Re: [Phplib-users] Sessions where are we going??

[Giancarlo <gia...@na...>]

Il 17:39, sabato 29 giugno 2002, Matt Williams ha scritto:

> As we are now well into PHP 4 would it not be better to put the full weight
> of php4 session capabilitiess into phplib?

IMHO PHP4 session is a scam. There is some unknown reason why it has been 
impossible, for almost two years now, to block creation of user-provided 
sids, and most graviuos, to  have any setting that provides a cookie-only 
session mamagement.
Add to that the fact that sessions among virtualhost are not differentiated, 
not even by the session_name.
So if it happens that another virtualhost runs the same app, it will be able 
to open another's vhost sessions, if he knows the id, maybe because he 
succeeded to inject it to someone. And everything will go into HIS logs.

Whith the result that PHP4 session is fully spoofable and it does not exist, 
and in fact it cannot exist, a php4 session implementation that wouldn't give 
full priority to any user-defined session passed via URL.  

Because of the potentially very malicious combination of the surmentioned 
elements, until they improve that, I don't trust php4 session anymore, except 
of course if you use a custom_handler for the session too. Then you are back 
to phplib

Gian

>
> Max has done a very good job of implementing custom sessions with the
> session4 class, but why are these still in the unstable tree and haven't
> been touched for months?
>
> Would it not be better for the future of phplib to embrace the tools that
> php4 has given us to work with sessions in our applications?
>
> Are there plans to move forward with the lib to implement fully php4
> sessions especially with register_globals off, given the security
> implications of having this on.
>
> I don't really contribute to CVS but I am working through trying to get
> phplib going with php4.0.6 with php4 sessions and register_globals off,
> when I get somewhere where I feel I can move on it I will post to the list.
> Unless of course this has already been done, in which case I would really
> like to hear from you :)
>
> I think the fact that the current distro still aims itself at php3 would be
> a major turn off to any new users/contributors.
>
> just my 2p
>
> Matt
>
>
> -------------------------------------------------------
> This sf.net email is sponsored by:ThinkGeek
> No, I will not fix your computer.
> http://thinkgeek.com/sf
> _______________________________________________
> Phplib-users mailing list
> Php...@li...
> https://lists.sourceforge.net/lists/listinfo/phplib-users

[Phplib-users] Sessions where are we going??

[Matt W. <li...@ye...>]

This is NOT meant to sound ungrateful or be an attempt to undermine any of 
the good work that all the people who contribute to phplib have dopne and 
still do so please don't flame me for it it's just my opinion and observation.

As we are now well into PHP 4 would it not be better to put the full weight 
of php4 session capabilitiess into phplib?

Max has done a very good job of implementing custom sessions with the 
session4 class, but why are these still in the unstable tree and haven't been 
touched for months? 

Would it not be better for the future of phplib to embrace the tools that 
php4 has given us to work with sessions in our applications?

Are there plans to move forward with the lib to implement fully php4 sessions 
especially with register_globals off, given the security implications of 
having this on.

I don't really contribute to CVS but I am working through trying to get 
phplib going with php4.0.6 with php4 sessions and register_globals off, when 
I get somewhere where I feel I can move on it I will post to the list. Unless 
of course this has already been done, in which case I would really like to 
hear from you :)

I think the fact that the current distro still aims itself at php3 would be a 
major turn off to any new users/contributors.

just my 2p

Matt

Re: [Phplib-users] a more secure session class

[Giancarlo <gia...@na...>]

I have uploaded the whole as a patch to sf, named 'Giancarlo's suite'.
As I said, I bapplied the auth modifications to my 'rationalized auth->start' 
method.
But essentially $sess->clone() has to be called after any auth_validatelogin 
or auth_doregister, somewhere in that unmaintainable auth->start method.

I am curious to hear from you.


Gian


Il 15:18, sabato 29 giugno 2002, Joe Stewart ha scritto:
> Hello,
>
> The changes sound reasonable and needed, I'd like to test and check them
> out.  Can you send a patch?
>
>
> thanks,
>
> Joe
>
> On Sat, Jun 29, 2002 at 01:50:05PM +0200, Giancarlo wrote:
> > Hi
> > I've finished writing and testing a new session and auth classes whose
> > major changes are:
> >
> > -upon login, the session content will be cloned into a NEW session, which
> > will then become THE session in use. It works for both cookie and get
> > mode, included fallback_mode=get
> >
> > This will stop cookie poisoning and takeovers, because the second session
> > will be unknown to an attacker or a snooper, and the initial session will
> > not hold any authentication.
> >
> > The modified auth class is based on my 'simplified auth->start' patch
> > (see patches at phplib on sf), as I refuse to put my hands into the old
> > auth->start crappy method.
> >
> > -That new auth class provides for easy management of login/reg forms
> > within fancy boxes, and has all the client interaction moved out to
> > page.inc (mode=reg/log, auth[uid]='form/nobody' etc) for easy
> > manipulation. No more cancel_login , auth[uid]=nobody, hardcoded mode/reg
> > mode, auth[uid]=form intermediate state.
> > This simple auth can be dropped into any phplib and work as before
> > (splash the login form), except the cancel_login, which no more exists
> > ;-))). It can also be used, with a particuler page.inc provided, to
> > handle login forms in a 'deferred' way (defer the output of the login
> > form), displayed within fancy boxes later in the page, without blocking
> > any other browser instance of auth.
> >
> > If anyone is interested I'll produce a patch of it all.
> >
> > Giancarlo
> >
> >
> >
> >
> >
> > -------------------------------------------------------
> > This sf.net email is sponsored by:ThinkGeek
> > No, I will not fix your computer.
> > http://thinkgeek.com/sf
> > _______________________________________________
> > Phplib-users mailing list
> > Php...@li...
> > https://lists.sourceforge.net/lists/listinfo/phplib-users