Re: [PHP-DEV] request data filter

[Rasmus Lerdorf]

>I cannot agree more. There is only so much you can do outside
>the PHP (as I do in mod_security).

I've finished the code.  I'll run it through its paces here and commit it 
soon.

-Rasmus


-- 
PHP Development Mailing List 
To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP-DEV] request data filter

[Ivan Ristic]

I suppose I could munge with the apache tables directly in a hook before
the data is read by the standard treat_data hook, although for post data I
am not sure I have any way to get in there before the
ap_get_client_block() call and change what data ap_get_client_block() is
going to see.


  I don't think there's a way to do that with Apache 1.x. Would
  mod_security (http://www.webkreator.com/mod_security/) solve
  your problem? It is an Apache module that sits between the
  browser and the script, watching the data flowing by (I patch
  the core Apache engine to get to the POST data). I am not changing
  the data at the moment, but was planning to introduce the feature
  some time in the future.



The main goal here, in case it wasn't obvious, is to prevent
cross-site-scripting problems by forcing all user-originating data to be
cleaned automatically and providing a hoop to jump through in case the
developer really does want the raw uncleaned data.  It isn't something
that belongs in PHP directly as every site that would be interested in
this would likely have different security policies, but I do think a 
general hook is something that would be useful to all of PHP.

  I cannot agree more. There is only so much you can do outside
  the PHP (as I do in mod_security).


Bye,
Ivan


--
PHP Development Mailing List 
To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP-DEV] request data filter

[Zeev Suraski]

At 02:52 16/01/2003, Rasmus Lerdorf wrote:

In trying to implement a security policy I need to pass all user-supplied
data (GET/POST/Cookie) through a filter function which implements this
security.  This isn't all that hard to implement as an extension through
new 4.3 treat_data and post_handler hooks, however it gets messy when you
throw mbstring into the mix as that extension also uses those hooks.

The cleanest way I can think of doing this is to add a function pointer to
SAPI for the filtering function that will be run right before the
php_register_variable_safe() call.  Currently we are always calling
php_url_decode() on the data before registering the variable, so I propose
that we make php_url_decode() the default that an extension can then
override.

Anybody see any reason not to make this simple change?  Without that I
will need to somehow detect whether mbstring is present and then filter
the data after it has already been registered by mbstring's
treat_data/post_handler hooks.  That's a big mess!


Sounds good to me.

Zeev


--
PHP Development Mailing List 
To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP-DEV] request data filter

[Moriyoshi Koizumi]

It looks like a mess indeed, and there seems a thought that
encoding conversion and variable registration should be separated
into two phases. However doing so doesn't make sense because
some of multibyte characters contains "[", "]", or "=" and they cannot
be handled properly in the ordinary query parser. Therefore Rasmus's
sugestion sounds quite logical to me.

Moriyoshi 


On Wed, Jan 15, 2003 at 04:52:58PM -0800, Rasmus Lerdorf wrote:
> In trying to implement a security policy I need to pass all user-supplied
> data (GET/POST/Cookie) through a filter function which implements this
> security.  This isn't all that hard to implement as an extension through
> new 4.3 treat_data and post_handler hooks, however it gets messy when you
> throw mbstring into the mix as that extension also uses those hooks.
> 
> The cleanest way I can think of doing this is to add a function pointer to 
> SAPI for the filtering function that will be run right before the 
> php_register_variable_safe() call.  Currently we are always calling 
> php_url_decode() on the data before registering the variable, so I propose 
> that we make php_url_decode() the default that an extension can then 
> override.
> 
> Anybody see any reason not to make this simple change?  Without that I 
> will need to somehow detect whether mbstring is present and then filter 
> the data after it has already been registered by mbstring's 
> treat_data/post_handler hooks.  That's a big mess!
> 
> -Rasmus
> 
> 
> -- 
> PHP Development Mailing List 
> To unsubscribe, visit: http://www.php.net/unsub.php
> 
> 

-- 
PHP Development Mailing List 
To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP-DEV] request data filter

[Maxim Maletsky]

Rasmus Lerdorf <[EMAIL PROTECTED]> wrote... :

> this would likely have different security policies, but I do think a 
> general hook is something that would be useful to all of PHP.
> 
> A huge number of web apps today are extremely vulnerable to
> cross-site-scripting attacks.  Occasionally developers remember to clean
> their data before displaying it, but for the most part they don't.  Take
> half and hour and find yourself a collection of sites where you can enter
> data that is somehow displayed back to you.  Shopping carts that ask for
> your name and phone number, or half of php.net's own stuff.  Stick a bit
> of javascript in your phone number and watch.


Just a little note here.

The government project I am working on was attacked on New Year's night
with XSS. Therefore, after we fixed it we decided to see what else is
vulnerable oiut there.

During the last two weeks I have played with a variaty of
sites/portals/apps trying to hack them to see how far I can go. I ended
up stealing the sessions of any  installations, changing the
passwords on  main website and could see the list of passwords in
pain user:pass format assigned as a cookie to anyone who sees my message
on ***.

Now, every *** was notified by me and, till they all will fix these, I
will try not to reveal their names.

What I think PHP should have is a function of a whole extension which
parses the output in various ways cleaning XSS in it.

Also, having such functionality in PHP would help it looking more secure
as XSS affects any programming language and not namy have such
protections.



--
Maxim Maletsky
[EMAIL PROTECTED]



-- 
PHP Development Mailing List 
To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP-DEV] request data filter

[Rasmus Lerdorf]

> You could have your custom C extension be called as one of the hooks.

I suppose I could munge with the apache tables directly in a hook before
the data is read by the standard treat_data hook, although for post data I
am not sure I have any way to get in there before the
ap_get_client_block() call and change what data ap_get_client_block() is
going to see.  I also need to make the raw data available via either a
special superglobal or an access function.  This doesn't seem 
straightforward to do through an apache_hook and it would tie something 
that is not inherently Apache-specific to Apache.  A general-purpose 
user-data filter hook would work across all sapi modules.

The main goal here, in case it wasn't obvious, is to prevent
cross-site-scripting problems by forcing all user-originating data to be
cleaned automatically and providing a hoop to jump through in case the
developer really does want the raw uncleaned data.  It isn't something
that belongs in PHP directly as every site that would be interested in
this would likely have different security policies, but I do think a 
general hook is something that would be useful to all of PHP.

A huge number of web apps today are extremely vulnerable to
cross-site-scripting attacks.  Occasionally developers remember to clean
their data before displaying it, but for the most part they don't.  Take
half and hour and find yourself a collection of sites where you can enter
data that is somehow displayed back to you.  Shopping carts that ask for
your name and phone number, or half of php.net's own stuff.  Stick a bit
of javascript in your phone number and watch.

-Rasmus


-- 
PHP Development Mailing List 
To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP-DEV] request data filter

[George Schlossnagle]

You could have your custom C extension be called as one of the hooks.

On Wednesday, January 15, 2003, at 09:42  PM, Rasmus Lerdorf wrote:


On Wed, 15 Jan 2003, George Schlossnagle wrote:


You consider running the apache_hooks code?  This should be simple
there.


You mean do the filtering straight from a PHP script that gets called 
from
a hook?  That's a lot of looping through a bunch of arrays.  This has 
to
happen on every request on the busiest site in the world; it needs to 
be
written in C.

You could have your custom C extension be called as one of the hooks.

Shouldn't be any slower than what you proposed.



-Rasmus


--
PHP Development Mailing List 
To unsubscribe, visit: http://www.php.net/unsub.php




--
PHP Development Mailing List 
To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP-DEV] request data filter

[Rasmus Lerdorf]

On Wed, 15 Jan 2003, George Schlossnagle wrote:

> You consider running the apache_hooks code?  This should be simple 
> there.

You mean do the filtering straight from a PHP script that gets called from 
a hook?  That's a lot of looping through a bunch of arrays.  This has to 
happen on every request on the busiest site in the world; it needs to be 
written in C.  

-Rasmus


-- 
PHP Development Mailing List 
To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP-DEV] request data filter

[George Schlossnagle]

You consider running the apache_hooks code?  This should be simple 
there.


--
PHP Development Mailing List 
To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP-DEV] request

[Boian Bonev]

> > You could have two classes both defining an innocent method toString(),
> > for example, and with your suggestion, inheriting from those classes
> > would cause a hard error? Why would "first encountered" definition
> > change?
> If anything that affected how classes were ordered changed, if the classes
were
> renamed, if the class definitions changed...

first occurence means the first occurence in the inheritance list. then it
is important how you order the class names when you inherit them, not when
they got defined.

b.


-- 
PHP Development Mailing List 
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
To contact the list administrators, e-mail: [EMAIL PROTECTED]

Re: [PHP-DEV] request

[Stanislav Malyshev]

AZ>> Ok, do you suggest just throwing an error if the symbol is
AZ>> ambiguous? Then you need to way to specify which of the parent
AZ>> classes' method to use, C++ does it like this:
AZ>>
AZ>> obj->B::a(); // calls method a() defined in parent class B

Yes, but in PHP it would be run-time error. I don't know if it would be
possible to implement this in efficient way, though.
-- 
Stanislav Malyshev, Zend Products Engineer
[EMAIL PROTECTED]  http://www.zend.com/ +972-3-6139665 ext.115



-- 
PHP Development Mailing List 
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
To contact the list administrators, e-mail: [EMAIL PROTECTED]

Re: [PHP-DEV] request

[Stanislav Malyshev]

AZ>> If that were so, then I'd expect a lot of Python people
AZ>> complaining about it, which they are not.. Are they smarter?

They probably see no point in complaining, since there's really not much
chance it would be changed. Could be Stockholm syndrome too...
-- 
Stanislav Malyshev, Zend Products Engineer
[EMAIL PROTECTED]  http://www.zend.com/ +972-3-6139665 ext.115



-- 
PHP Development Mailing List 
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
To contact the list administrators, e-mail: [EMAIL PROTECTED]

Re: [PHP-DEV] request

[Andrei Zmievski]

At 12:54 PM 4/22/01 +0300, Stanislav Malyshev wrote:
>Sure this is a hard error. And double sure using first method is wrong.
>Why the first one is better than the second? The third? The 42th? The
>toString function should or be overriden in inherited object, which
>resolves the conflict, or uniquely qualified each time. Choosing random
>(and first _is_ random, because you have no control on the order of
>definitions in foreign code) implementaion is not going to bring any good.

Ok, do you suggest just throwing an error if the symbol is ambiguous? Then 
you need to way to specify which of the parent classes' method to use, C++ 
does it like this:

obj->B::a(); // calls method a() defined in parent class B

-Andrei


-- 
PHP Development Mailing List 
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
To contact the list administrators, e-mail: [EMAIL PROTECTED]

Re: [PHP-DEV] request

[Andrei Zmievski]

At 12:44 PM 4/22/01 +0300, Stanislav Malyshev wrote:
>That would be what I call weirdness and would raise WTF factor
>significantly. Changing some class declaration is some unrelated module
>could then make all your code inside out and you have absolutely no
>control on it and no means to prevent this or even know what happened.

If that were so, then I'd expect a lot of Python people complaining about 
it, which they are not.. Are they smarter?

-Andrei


-- 
PHP Development Mailing List 
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
To contact the list administrators, e-mail: [EMAIL PROTECTED]

Re: [PHP-DEV] request

[Stanislav Malyshev]

AZ>> You could have two classes both defining an innocent method
AZ>> toString(), for example, and with your suggestion, inheriting
AZ>> from those classes would cause a hard error? Why would "first

Sure this is a hard error. And double sure using first method is wrong.
Why the first one is better than the second? The third? The 42th? The
toString function should or be overriden in inherited object, which
resolves the conflict, or uniquely qualified each time. Choosing random
(and first _is_ random, because you have no control on the order of
definitions in foreign code) implementaion is not going to bring any good.
-- 
Stanislav Malyshev, Zend Products Engineer
[EMAIL PROTECTED]  http://www.zend.com/ +972-3-6139665 ext.115



-- 
PHP Development Mailing List 
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
To contact the list administrators, e-mail: [EMAIL PROTECTED]

Re: [PHP-DEV] request

[Stanislav Malyshev]

AZ>> Alternatively, we could do the Python way: the base classes are
AZ>> searched in depth-first order, and if the base classes define
AZ>> the same symbol, the first encountered definition is used.

That would be what I call weirdness and would raise WTF factor
significantly. Changing some class declaration is some unrelated module
could then make all your code inside out and you have absolutely no
control on it and no means to prevent this or even know what happened.
-- 
Stanislav Malyshev, Zend Products Engineer
[EMAIL PROTECTED]  http://www.zend.com/ +972-3-6139665 ext.115



-- 
PHP Development Mailing List 
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
To contact the list administrators, e-mail: [EMAIL PROTECTED]

Re: [PHP-DEV] request

[Andrei Zmievski]

At 06:36 PM 4/21/01 -0400, Stig Sæther Bakken wrote:
>Okay, what about this one:
>
>If two inherited classes define the same method, the inheriting class
>has to redefine it.  This way the inheriting class can be explicit in
>how to combine or override the inherited methods.

This would work if the number of such methods is low, and if these methods 
are defined in the immediate ancestors of the class. If it's further up the 
hierarchy, then the user writing the class has to know which classes its 
parent classes inherit from and so on.

>We'd need a way of
>referring to any inherited class's methods though.

Yes, of course.

-Andrei


--
PHP Development Mailing List 
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
To contact the list administrators, e-mail: [EMAIL PROTECTED]

Re: [PHP-DEV] request

[Stig Sæther Bakken]

[Andrei Zmievski <[EMAIL PROTECTED]>]
> On Sat, 21 Apr 2001, Chuck Hagenbuch wrote:
> > This could result in really confusing and unpredictable behavior if "the first 
> > encountered definition" changed under any circumstances. I'd vote for making 
> > any name conflicts an error.
> 
> You could have two classes both defining an innocent method toString(),
> for example, and with your suggestion, inheriting from those classes
> would cause a hard error? Why would "first encountered" definition
> change?

Okay, what about this one:

If two inherited classes define the same method, the inheriting class
has to redefine it.  This way the inheriting class can be explicit in
how to combine or override the inherited methods.  We'd need a way of
referring to any inherited class's methods though.

 - Stig
-- 
  Stig Sæther Bakken <[EMAIL PROTECTED]>
  Fast Search & Transfer ASA, Trondheim, Norway

-- 
PHP Development Mailing List 
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
To contact the list administrators, e-mail: [EMAIL PROTECTED]

Re: [PHP-DEV] request

[Chuck Hagenbuch]

Quoting Andrei Zmievski <[EMAIL PROTECTED]>:

> You could have two classes both defining an innocent method toString(),
> for example, and with your suggestion, inheriting from those classes
> would cause a hard error? Why would "first encountered" definition
> change?

If anything that affected how classes were ordered changed, if the classes were 
renamed, if the class definitions changed...

-chuck

--
Charles Hagenbuch, <[EMAIL PROTECTED]>

Taurus:
You will receive an urgent transmission from the Martian government informing 
you that Mars does not, in fact, need women, so please stop sending them.

-- 
PHP Development Mailing List 
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
To contact the list administrators, e-mail: [EMAIL PROTECTED]

Re: [PHP-DEV] request

[Andrei Zmievski]

On Sat, 21 Apr 2001, Chuck Hagenbuch wrote:
> This could result in really confusing and unpredictable behavior if "the first 
> encountered definition" changed under any circumstances. I'd vote for making 
> any name conflicts an error.

You could have two classes both defining an innocent method toString(),
for example, and with your suggestion, inheriting from those classes
would cause a hard error? Why would "first encountered" definition
change?

-Andrei

It is commonly the case with technologies that you can get
the best insight about how they work by watching them fail.
-- Neal Stephenson

-- 
PHP Development Mailing List 
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
To contact the list administrators, e-mail: [EMAIL PROTECTED]

Re: [PHP-DEV] request

[Chuck Hagenbuch]

Quoting Andrei Zmievski <[EMAIL PROTECTED]>:

> Alternatively, we could do the Python way: the base classes are searched in
> depth-first order, and if the base classes define the same symbol, the 
> first encountered definition is used.

This could result in really confusing and unpredictable behavior if "the first 
encountered definition" changed under any circumstances. I'd vote for making 
any name conflicts an error.

-chuck

--
Charles Hagenbuch, <[EMAIL PROTECTED]>

Taurus:
You will receive an urgent transmission from the Martian government informing 
you that Mars does not, in fact, need women, so please stop sending them.

-- 
PHP Development Mailing List 
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
To contact the list administrators, e-mail: [EMAIL PROTECTED]

Re: [PHP-DEV] request

[Andrei Zmievski]

At 09:41 PM 4/20/01 -0400, Stig Sæther Bakken wrote:
>The idea is starting to grow on me.  But I think name clashes should
>be defined as errors, that is more consistent with the way function
>and class declarations are done.

Alternatively, we could do the Python way: the base classes are searched in 
depth-first order, and if the base classes define the same symbol, the 
first encountered definition is used.

-Andrei


--
PHP Development Mailing List 
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
To contact the list administrators, e-mail: [EMAIL PROTECTED]

Re: [PHP-DEV] request

[Stig Sæther Bakken]

[Andrei Zmievski <[EMAIL PROTECTED]>]
> On Tue, 17 Apr 2001, Stanislav Malyshev wrote:
> > Generally, since PHP is not a strongly typed language, it's not too hard
> > to implement multiple inheritance, I guess. Question is - is it worth the
> > effort? Does it need to be done?
> 
> With multiple inheritance you have a way to implement interfaces and
> mixins. Very nice.

The idea is starting to grow on me.  But I think name clashes should
be defined as errors, that is more consistent with the way function
and class declarations are done.

 - Stig

-- 
  Stig Sæther Bakken <[EMAIL PROTECTED]>
  Fast Search & Transfer ASA, Trondheim, Norway

-- 
PHP Development Mailing List 
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
To contact the list administrators, e-mail: [EMAIL PROTECTED]

Re: [PHP-DEV] request

[Andrei Zmievski]

On Tue, 17 Apr 2001, Stanislav Malyshev wrote:
> Generally, since PHP is not a strongly typed language, it's not too hard
> to implement multiple inheritance, I guess. Question is - is it worth the
> effort? Does it need to be done?

With multiple inheritance you have a way to implement interfaces and
mixins. Very nice.

-Andrei

Nobody tried to design Windows - it just grew in random
directions without any kind of thought behind it.

-- 
PHP Development Mailing List 
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
To contact the list administrators, e-mail: [EMAIL PROTECTED]

Re: [PHP-DEV] Request : Surface Userland version of zend_is_callable

[Andrei Zmievski]

On Tue, 17 Apr 2001, clayton collie wrote:
> 
> Title says it. It seems like it would be a useful way of preventing certain
> runtime errors with callbacks.

It could be a pretty simple userland function.. but can be written in C
as well.

-Andrei

When we eliminate the impossible, whatever remains,
however improbable, must be true. -- Sherlock Holmes

-- 
PHP Development Mailing List 
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
To contact the list administrators, e-mail: [EMAIL PROTECTED]

Re: [PHP-DEV] request

[Chuck Hagenbuch]

Quoting Stanislav Malyshev <[EMAIL PROTECTED]>:

> I don't know why very these ones are the "biggest", but it's possible to
> "resolve" them, taking into account that every resolution would be
> necessarily imperfect, since the situation itself is no good.

Okay, I've gone and refreshed my memory a bit. There's a pretty good article on 
the topic here:

http://www.elj.com/eiffel/feature/inheritance/mi/review/

> There can be a number of strategies, e.g.:
> 1. Requiring exact qualification on each call
> 2. Choosing one of them (fits for variables, worse for methods)
> 3. Declaring the situation to be an error
> etc., etc.

Going with my own instincts and the opinions of the above article, 1 or 3 would 
be acceptable solutions. And 2 doesn't _always_ work for variables, in the case 
that you're encapsulating two objects with distinct states.

That said, I'm still against it because of the complexity that it adds and the 
misuse that it encourages. I'd rather see interfaces (and namespaces! - though 
that's not a solution for the same problem).

-chuck

--
Charles Hagenbuch, <[EMAIL PROTECTED]>

Taurus:
You will receive an urgent transmission from the Martian government informing 
you that Mars does not, in fact, need women, so please stop sending them.

-- 
PHP Development Mailing List 
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
To contact the list administrators, e-mail: [EMAIL PROTECTED]

Re: [PHP-DEV] request

[Stanislav Malyshev]

CH>> Admittedly, it's been a bit since my languages class, but I
CH>> don't see how loose typing resolves the biggest problems with
CH>> multiple inheritance:

I don't know why very these ones are the "biggest", but it's possible to
"resolve" them, taking into account that every resolution would be
necessarily imperfect, since the situation itself is no good.

CH>> 1. What do you do if two parent classes have methods with the
CH>> same name? 2. What do you do if two parent classes have class
CH>> variables with the same name?

There can be a number of strategies, e.g.:
1. Requiring exact qualification on each call
2. Choosing one of them (fits for variables, worse for methods)
3. Declaring the situation to be an error
etc., etc.

-- 
Stanislav Malyshev, Zend Products Engineer
[EMAIL PROTECTED]  http://www.zend.com/ +972-3-6139665 ext.115



-- 
PHP Development Mailing List 
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
To contact the list administrators, e-mail: [EMAIL PROTECTED]

Re: [PHP-DEV] request

[Chuck Hagenbuch]

Quoting Stanislav Malyshev <[EMAIL PROTECTED]>:

> Generally, since PHP is not a strongly typed language, it's not too hard
> to implement multiple inheritance, I guess.

Admittedly, it's been a bit since my languages class, but I don't see how loose 
typing resolves the biggest problems with multiple inheritance:

1. What do you do if two parent classes have methods with the same name?
2. What do you do if two parent classes have class variables with the same name?

I'm willing to be persuaded by good answers to those questions, but I don't 
know if they exist. So for now, I'm against it, as a feature extremely likely 
to cause confusion and weirdness, and one that's probably not really needed or 
understood by most people who think they need it.

-chuck

--
Charles Hagenbuch, <[EMAIL PROTECTED]>

Taurus:
You will receive an urgent transmission from the Martian government informing 
you that Mars does not, in fact, need women, so please stop sending them.

-- 
PHP Development Mailing List 
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
To contact the list administrators, e-mail: [EMAIL PROTECTED]

Re: [PHP-DEV] request

[Stig Sæther Bakken]

[David Guerizec <[EMAIL PROTECTED]>]
> "Peter \"[DiSAStA]\" Petermann" <[EMAIL PROTECTED]> wrote:
> > Hi stas,
> > 
> > > JT>> >  Ah, that's another way to say "When Andi and Zeev implement it" :-)
> > > JT>>
> > > JT>> Like..never? :)
> > > Generally, since PHP is not a strongly typed language, it's not too hard
> > > to implement multiple inheritance, I guess. Question is - is it worth the
> > > effort? Does it need to be done?
> > mh.. would be real great for some things...
> > well, the typical PHP-Coder doesnt need it,
> > but, in some cases it could be usefull...
> 
> IMHO, a more usful thing to see before multiple inheritance would be
> proper constructor (and eventually destructor) callings...

How do you define "proper" in this case? :-)

 - Stig

-- 
  Stig Sæther Bakken <[EMAIL PROTECTED]>
  Fast Search & Transfer ASA, Trondheim, Norway

-- 
PHP Development Mailing List 
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
To contact the list administrators, e-mail: [EMAIL PROTECTED]

Re: [PHP-DEV] request

[David Guerizec]

"Peter \"[DiSAStA]\" Petermann" <[EMAIL PROTECTED]> wrote:
> Hi stas,
> 
> > JT>> >  Ah, that's another way to say "When Andi and Zeev implement it" :-)
> > JT>>
> > JT>> Like..never? :)
> > Generally, since PHP is not a strongly typed language, it's not too hard
> > to implement multiple inheritance, I guess. Question is - is it worth the
> > effort? Does it need to be done?
> mh.. would be real great for some things...
> well, the typical PHP-Coder doesnt need it,
> but, in some cases it could be usefull...

IMHO, a more usful thing to see before multiple inheritance would be proper 
constructor (and eventually destructor) callings...
 
> Peter Petermann
> 
> --
> /* ZIMT - where PHP meets needs*
>  * [EMAIL PROTECTED] - www.phpug.de
>  * [EMAIL PROTECTED] - www.cyberfly.net 
> */

-- 
Best regards,
David Guerizec

-- 
PHP Development Mailing List 
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
To contact the list administrators, e-mail: [EMAIL PROTECTED]

Re: [PHP-DEV] request

[Jani Taskinen]

On Tue, 17 Apr 2001, Stanislav Malyshev wrote:

>JT>> >  Ah, that's another way to say "When Andi and Zeev implement it" :-)
>JT>>
>JT>> Like..never? :)
>
>Generally, since PHP is not a strongly typed language, it's not too hard
>to implement multiple inheritance, I guess. Question is - is it worth the
>effort? Does it need to be done?

Well..I know a couple of people who would like to have it. :)
And IIRC there are couple of requests for it in the bug db too.

--Jani



-- 
PHP Development Mailing List 
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
To contact the list administrators, e-mail: [EMAIL PROTECTED]

Re: [PHP-DEV] request

[Peter \"[DiSAStA]\" Petermann]

Hi stas,

> JT>> >  Ah, that's another way to say "When Andi and Zeev implement it" :-)
> JT>>
> JT>> Like..never? :)
> Generally, since PHP is not a strongly typed language, it's not too hard
> to implement multiple inheritance, I guess. Question is - is it worth the
> effort? Does it need to be done?
mh.. would be real great for some things...
well, the typical PHP-Coder doesnt need it,
but, in some cases it could be usefull...


Peter Petermann

--
/* ZIMT - where PHP meets needs*
 * [EMAIL PROTECTED] - www.phpug.de
 * [EMAIL PROTECTED] - www.cyberfly.net 
*/



-- 
PHP Development Mailing List 
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
To contact the list administrators, e-mail: [EMAIL PROTECTED]

Re: [PHP-DEV] request

[Stanislav Malyshev]

JT>> >  Ah, that's another way to say "When Andi and Zeev implement it" :-)
JT>>
JT>> Like..never? :)

Generally, since PHP is not a strongly typed language, it's not too hard
to implement multiple inheritance, I guess. Question is - is it worth the
effort? Does it need to be done?

-- 
Stanislav Malyshev, Zend Products Engineer
[EMAIL PROTECTED]  http://www.zend.com/ +972-3-6139665 ext.115



-- 
PHP Development Mailing List 
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
To contact the list administrators, e-mail: [EMAIL PROTECTED]

Re: [PHP-DEV] request

[Jani Taskinen]

On Tue, 17 Apr 2001, Sebastian Bergmann wrote:

>Stig Sæther Bakken wrote:
>> > About classes and objects, will PHP have multiple inheritance
>> > support?
>>
>> When there's peace in Jerusalem.
>
>  Ah, that's another way to say "When Andi and Zeev implement it" :-)

Like..never? :)

--Jani



--
PHP Development Mailing List 
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
To contact the list administrators, e-mail: [EMAIL PROTECTED]

Re: [PHP-DEV] request

[Sebastian Bergmann]

Stig Sæther Bakken wrote:
> > About classes and objects, will PHP have multiple inheritance 
> > support?
> 
> When there's peace in Jerusalem.

  Ah, that's another way to say "When Andi and Zeev implement it" :-)

-- 
 sebastian bergmann[EMAIL PROTECTED]
   http://www.sebastian-bergmann.de

 bonn.phpug.de | www.php.net | www.phpOpenTracker.de | www.titanchat.de

-- 
PHP Development Mailing List 
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
To contact the list administrators, e-mail: [EMAIL PROTECTED]

Re: [PHP-DEV] request

[Stig Sæther Bakken]

["Alberto" <[EMAIL PROTECTED]>]
> About classes and objects, will PHP have multiple inheritance support ?

When there's peace in Jerusalem.

 - Stig

-- 
  Stig Sæther Bakken <[EMAIL PROTECTED]>
  Fast Search & Transfer ASA, Trondheim, Norway

-- 
PHP Development Mailing List 
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
To contact the list administrators, e-mail: [EMAIL PROTECTED]

Re: [PHP-DEV] Request for new feature: $HTTP_SESSION_VARS whenregister_globals = on

[Carsten Gehling]

From: "Carsten Gehling" <[EMAIL PROTECTED]>
Sent: Monday, April 09, 2001 9:31 AM
Subject: Re: [PHP-DEV] Request for new feature: $HTTP_SESSION_VARS
whenregister_globals = on


> From: "Alexander Feldman" <[EMAIL PROTECTED]>
> Sent: Friday, April 06, 2001 10:46 PM
>
> > Hm, very strange. You are absolutely right - I do not see any problems
as
> > well. Not only with the current cvs but with the older phps also... But
I
> > am sure I have seen some time ago exactly what was described by Carsten
> > Gehling. Maybe it is kind of group hallucination ;)
>
> Try this:



Or this, which is slightly more interesting:


";
$HTTP_SESSION_VARS["c"] = $HTTP_SESSION_VARS["c"] + 1;
var_dump($HTTP_SESSION_VARS);
?>



On the first run, SID is displayed in the browser, but when reloading the
page, SID is empty.

As a side note: I run PHP 4.0.4pl1 as CGI on Win2k IIS5.

- Carsten



-- 
PHP Development Mailing List <http://www.php.net/>
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
To contact the list administrators, e-mail: [EMAIL PROTECTED]

Re: [PHP-DEV] Request for new feature: $HTTP_SESSION_VARS whenregister_globals = on

[Carsten Gehling]

From: "Alexander Feldman" <[EMAIL PROTECTED]>
Sent: Friday, April 06, 2001 10:46 PM


> Hm, very strange. You are absolutely right - I do not see any problems as
> well. Not only with the current cvs but with the older phps also... But I
> am sure I have seen some time ago exactly what was described by Carsten
> Gehling. Maybe it is kind of group hallucination ;)

Try this:

===


===

And try reloading the page a couple of times. With register_globals = Off,
the session variable "c" will be incrementing by one on each reload. With
register_globals = On, it will always be 1 (thereby showing, that it does
not exist when reloading).

- Carsten



-- 
PHP Development Mailing List 
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
To contact the list administrators, e-mail: [EMAIL PROTECTED]

Re: [PHP-DEV] Request for new feature: $HTTP_SESSION_VARS whenregister_globals = on

[Alexander Feldman]

On Fri, 6 Apr 2001, Sascha Schumann wrote:

> > It is simpler.
>
> Chuck is talking about another problem which I agree has not
> been addressed yet properly.
>
> > We should just leave the array $HTTP_SESSION_VARS in the
> > case when register_globals is on. Currently when the variables are registered
> > they *are* removed from the $HTTP_SESSION_VARS array. I do not think this is
> > the intended behaviour.
>
> That is not the behaviour I see.  The following script
> displays the correctly setup $HTTP_SESSION_VARS array when
> run multiple times with the current CVS.

Hm, very strange. You are absolutely right - I do not see any problems as
well. Not only with the current cvs but with the older phps also... But I
am sure I have seen some time ago exactly what was described by Carsten
Gehling. Maybe it is kind of group hallucination ;)

-- alex

>
>  session_id("test");
> session_register("c");
> $c++;
> var_dump($HTTP_SESSION_VARS);
>
> - Sascha Experience IRCG
>   http://schumann.cx/http://schumann.cx/ircg
>
>
> --
> PHP Development Mailing List 
> To unsubscribe, e-mail: [EMAIL PROTECTED]
> For additional commands, e-mail: [EMAIL PROTECTED]
> To contact the list administrators, e-mail: [EMAIL PROTECTED]
>


-- 
PHP Development Mailing List 
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
To contact the list administrators, e-mail: [EMAIL PROTECTED]

Re: [PHP-DEV] Request for new feature: $HTTP_SESSION_VARS whenregister_globals = on

[Sascha Schumann]

> It is simpler.

Chuck is talking about another problem which I agree has not
been addressed yet properly.

> We should just leave the array $HTTP_SESSION_VARS in the
> case when register_globals is on. Currently when the variables are registered
> they *are* removed from the $HTTP_SESSION_VARS array. I do not think this is
> the intended behaviour.

That is not the behaviour I see.  The following script
displays the correctly setup $HTTP_SESSION_VARS array when
run multiple times with the current CVS.

http://schumann.cx/http://schumann.cx/ircg


-- 
PHP Development Mailing List 
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
To contact the list administrators, e-mail: [EMAIL PROTECTED]

Re: [PHP-DEV] Request for new feature: $HTTP_SESSION_VARS whenregister_globals = on

[Alexander Feldman]

On Fri, 6 Apr 2001, Chuck Hagenbuch wrote:

> Quoting Sascha Schumann <[EMAIL PROTECTED]>:
>
> > >- but that does make it really
> > > messy to write code that works with either setting.
> >
> > Yes.  Feel free to propose a solution which solves your
> > problem and which is compatible to existing scripts.
>
> What about adding session_set_var (and session_get_var, for symmetry) functions
> to set and access session variables regardless of scope?

It is simpler. We should just leave the array $HTTP_SESSION_VARS in the
case when register_globals is on. Currently when the variables are registered
they *are* removed from the $HTTP_SESSION_VARS array. I do not think this is
the intended behaviour.

The chance of breaking the existing scripts by having the session
variables both as global and in the $HTTP_SESSION_VARS array are minimal.

I do not think this is a new feature and just a bugfix...

-- alex

>
> -chuck
>
> --
> Charles Hagenbuch, <[EMAIL PROTECTED]>
> Number of U.S. nuclear bombs lost in accidents and never recovered: 11
>
> --
> PHP Development Mailing List 
> To unsubscribe, e-mail: [EMAIL PROTECTED]
> For additional commands, e-mail: [EMAIL PROTECTED]
> To contact the list administrators, e-mail: [EMAIL PROTECTED]
>


-- 
PHP Development Mailing List 
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
To contact the list administrators, e-mail: [EMAIL PROTECTED]

Re: [PHP-DEV] Request for new feature: $HTTP_SESSION_VARS when register_globals = on

[Chuck Hagenbuch]

Quoting Sascha Schumann <[EMAIL PROTECTED]>:

> >- but that does make it really
> > messy to write code that works with either setting.
> 
> Yes.  Feel free to propose a solution which solves your
> problem and which is compatible to existing scripts.

What about adding session_set_var (and session_get_var, for symmetry) functions 
to set and access session variables regardless of scope?

-chuck

--
Charles Hagenbuch, <[EMAIL PROTECTED]>
Number of U.S. nuclear bombs lost in accidents and never recovered: 11

-- 
PHP Development Mailing List 
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
To contact the list administrators, e-mail: [EMAIL PROTECTED]

Re: [PHP-DEV] Request for new feature: $HTTP_SESSION_VARS whenregister_globals = on

[Sascha Schumann]

> Possibly not - can the original poster comment?

He wrote

If register_globals is set to on, you cannot access $HTTP_SESSION_VARS any
longer. Instead you can get the values through implicit created variables or
through the $GLOBALS array.

'access' and 'get' sound like read operations to me.

>- but that does make it really
> messy to write code that works with either setting.

Yes.  Feel free to propose a solution which solves your
problem and which is compatible to existing scripts.

- Sascha Experience IRCG
  http://schumann.cx/http://schumann.cx/ircg


-- 
PHP Development Mailing List 
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
To contact the list administrators, e-mail: [EMAIL PROTECTED]

Re: [PHP-DEV] Request for new feature: $HTTP_SESSION_VARS when register_globals = on

[Chuck Hagenbuch]

Quoting Sascha Schumann <[EMAIL PROTECTED]>:

> On Fri, 6 Apr 2001, Chuck Hagenbuch wrote:
> 
> > Quoting Sascha Schumann <[EMAIL PROTECTED]>:
> >
> > > Unless a bug has slipped in, HTTP_SESSION_VARS get always
> > > created.  If you enable register_globals, variables with
> > > global scope will be additionally created.
> >
> > They are always created; the problem is that if register_globals is on, you
> > can't manipulate them and have the changes stick.
> 
> Right, but that is not what the original request was about
> (as far as I understood it).

Possibly not - can the original poster comment? - but that does make it really 
messy to write code that works with either setting.

-chuck

--
Charles Hagenbuch, <[EMAIL PROTECTED]>
Number of U.S. nuclear bombs lost in accidents and never recovered: 11

-- 
PHP Development Mailing List 
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
To contact the list administrators, e-mail: [EMAIL PROTECTED]

Re: [PHP-DEV] Request for new feature: $HTTP_SESSION_VARS whenregister_globals = on

[Sascha Schumann]

> If register_globals is set to on, you cannot access $HTTP_SESSION_VARS any
> longer. Instead you can get the values through implicit created variables or
> through the $GLOBALS array.

Unless a bug has slipped in, HTTP_SESSION_VARS get always
created.  If you enable register_globals, variables with
global scope will be additionally created.

(refer to session.c:238)

- Sascha Experience IRCG
  http://schumann.cx/http://schumann.cx/ircg


-- 
PHP Development Mailing List 
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
To contact the list administrators, e-mail: [EMAIL PROTECTED]

Re: [PHP-DEV] Request for new feature: $HTTP_SESSION_VARS when register_globals = on

[Andi Gutmans]

Yes, what you're saying definitely makes sense and I think it should be fixed.

Andi

At 09:20 PM 4/5/2001 +0200, Carsten Gehling wrote:
>One of the IMHO stranger behaviors in PHP is what happens to the
>$HTTP_SESSION_VARS array when changing register_globals from off to on.
>
>If register_globals is set to on, you cannot access $HTTP_SESSION_VARS any
>longer. Instead you can get the values through implicit created variables or
>through the $GLOBALS array.
>
>Now compare this to $HTTP_GET_VARS and $HTTP_POST_VARS. Both of these arrays
>are available regardless of what register_globals is set to.
>
>Shouldn't it be the same for $HTTP_SESSION_VARS ?
>
>- Carsten
>
>
>
>--
>PHP Development Mailing List 
>To unsubscribe, e-mail: [EMAIL PROTECTED]
>For additional commands, e-mail: [EMAIL PROTECTED]
>To contact the list administrators, e-mail: [EMAIL PROTECTED]


-- 
PHP Development Mailing List 
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
To contact the list administrators, e-mail: [EMAIL PROTECTED]

RE: [PHP-DEV] Request for new feature: $HTTP_SESSION_VARS when register_globals = on

[Chris Newbill]

+1

-Chris

-Original Message-
From: Alexander Feldman [mailto:[EMAIL PROTECTED]]
Sent: Thursday, 05 April, 2001 1-44 pM
To: Carsten Gehling
Cc: [EMAIL PROTECTED]
Subject: Re: [PHP-DEV] Request for new feature: $HTTP_SESSION_VARS when
register_globals = on


This makes sense. The behaviour quoted below creates difficulties when
writing portable scripts (not to depend on the value of register_globals).

Rgds:

-- Alex

On Thu, 5 Apr 2001, Carsten Gehling wrote:

> One of the IMHO stranger behaviors in PHP is what happens to the
> $HTTP_SESSION_VARS array when changing register_globals from off to on.
>
> If register_globals is set to on, you cannot access $HTTP_SESSION_VARS any
> longer. Instead you can get the values through implicit created variables
or
> through the $GLOBALS array.
>
> Now compare this to $HTTP_GET_VARS and $HTTP_POST_VARS. Both of these
arrays
> are available regardless of what register_globals is set to.
>
> Shouldn't it be the same for $HTTP_SESSION_VARS ?
>
> - Carsten
>
>
>
> --
> PHP Development Mailing List <http://www.php.net/>
> To unsubscribe, e-mail: [EMAIL PROTECTED]
> For additional commands, e-mail: [EMAIL PROTECTED]
> To contact the list administrators, e-mail: [EMAIL PROTECTED]
>


--
PHP Development Mailing List <http://www.php.net/>
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
To contact the list administrators, e-mail: [EMAIL PROTECTED]


-- 
PHP Development Mailing List <http://www.php.net/>
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
To contact the list administrators, e-mail: [EMAIL PROTECTED]

Re: [PHP-DEV] Request for new feature: $HTTP_SESSION_VARS whenregister_globals = on

[Alexander Feldman]

This makes sense. The behaviour quoted below creates difficulties when
writing portable scripts (not to depend on the value of register_globals).

Rgds:

-- Alex

On Thu, 5 Apr 2001, Carsten Gehling wrote:

> One of the IMHO stranger behaviors in PHP is what happens to the
> $HTTP_SESSION_VARS array when changing register_globals from off to on.
>
> If register_globals is set to on, you cannot access $HTTP_SESSION_VARS any
> longer. Instead you can get the values through implicit created variables or
> through the $GLOBALS array.
>
> Now compare this to $HTTP_GET_VARS and $HTTP_POST_VARS. Both of these arrays
> are available regardless of what register_globals is set to.
>
> Shouldn't it be the same for $HTTP_SESSION_VARS ?
>
> - Carsten
>
>
>
> --
> PHP Development Mailing List 
> To unsubscribe, e-mail: [EMAIL PROTECTED]
> For additional commands, e-mail: [EMAIL PROTECTED]
> To contact the list administrators, e-mail: [EMAIL PROTECTED]
>


-- 
PHP Development Mailing List 
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
To contact the list administrators, e-mail: [EMAIL PROTECTED]