On Wed, January 16, 2008 2:17 pm, Stefan Esser wrote:
> It would have been a good idea to have such a configuration option
> that
> allows to specify what is in _REQUEST and what not...
Perhaps it would be wise to add yet another php.ini setting?
[Yeah, I know the usual response to that. Just thi
On Wed, January 16, 2008 1:45 am, Stefan Esser wrote:
> Stefan Priebsch schrieb:
>> Richard Lynch schrieb:
>>> If a web service really doesn't care whether it is responding to
>>> GET
>>> or POST or even forged COOKIES to product its output, why would it
>>> not
>>> just use REQUEST?
>>>
>>> It's n
On Wed, January 16, 2008 12:54 am, Stefan Priebsch wrote:
> Richard Lynch schrieb:
>> If a web service really doesn't care whether it is responding to GET
>> or POST or even forged COOKIES to product its output, why would it
>> not
>> just use REQUEST?
>>
>> It's not as if it's any harder to forge
On Thu, Jan 17, 2008 at 10:17:18AM +0100, Stefan Esser wrote:
> So you see that you nearly NEVER ever want the cookie in _REQUEST. And
> even if you can think up a theoretical situation where you don't care
> the problem is that everyone else uses _REQUEST in unsafe places...
> Therefore my recomm
On Jan 17, 2008, at 10:17 , Stefan Esser wrote:
When someone injects you a cookie like +++action=logout through an
XSS or through a feature like foobar.co.kr can set cookies for
*.co.kr
(in FF atleast).
Ok, you are assuming one security issue here, that is not related to
the topic.
Hello Lukas,
> Ah ok .. sorry for having missed that point. Of course I was assuming
> that the feature worked as advertised. I guess I was thrown off by the
> fact that Stefan initially made it sound like the concept in general
> is flawed and would automatically make an application insecure.
> O
On Jan 16, 2008, at 11:55 , Stanislav Malyshev wrote:
I dont understand the problem. You use request if you do not care
where a parameter is set and you use the other superglobals when
you do care.
The problem is that variables_order should specify what gets into
_REQUEST (as documented
I dont understand the problem. You use request if you do not care where
a parameter is set and you use the other superglobals when you do care.
The problem is that variables_order should specify what gets into
_REQUEST (as documented in the manual) and as Stefan reports it doesn't
exactly do
On Jan 16, 2008, at 9:17 , Stefan Esser wrote:
Stanislav Malyshev schrieb:
@Richard: You don't understand the Problem with _REQUEST. It is not
about the fact that someone can forge GET, POST; COOKIE variables.
It is about the fact that COOKIEs will overwrite GET and POST data
in
REQUEST.
Changing the variables_order to CGP is not a good idea either, because
then applications that use cookies through _REQUEST could be tricked by
I can imagine why one would use _REQUEST to work with GET and POST
alike. However I can not imagine what would be the reason to use REQUEST
if you need
Stanislav Malyshev schrieb:
>> @Richard: You don't understand the Problem with _REQUEST. It is not
>> about the fact that someone can forge GET, POST; COOKIE variables.
>> It is about the fact that COOKIEs will overwrite GET and POST data in
>> REQUEST.
>
> Isn't it solved by setting variables_orde
Stanislav Malyshev wrote:
@Richard: You don't understand the Problem with _REQUEST. It is not
about the fact that someone can forge GET, POST; COOKIE variables.
It is about the fact that COOKIEs will overwrite GET and POST data in
REQUEST.
Isn't it solved by setting variables_order to correct v
@Richard: You don't understand the Problem with _REQUEST. It is not
about the fact that someone can forge GET, POST; COOKIE variables.
It is about the fact that COOKIEs will overwrite GET and POST data in
REQUEST.
Isn't it solved by setting variables_order to correct value, at least
partially?
Stefan Priebsch schrieb:
> Richard Lynch schrieb:
>> If a web service really doesn't care whether it is responding to GET
>> or POST or even forged COOKIES to product its output, why would it not
>> just use REQUEST?
>>
>> It's not as if it's any harder to forge GET vs. POST vs. COOKIE data,
>> rea
Richard Lynch schrieb:
If a web service really doesn't care whether it is responding to GET
or POST or even forged COOKIES to product its output, why would it not
just use REQUEST?
It's not as if it's any harder to forge GET vs. POST vs. COOKIE data,
really.
You can easily have sombeody inadve
On Sat, January 5, 2008 2:48 pm, Stefan Esser wrote:
> Hello,
>>> typing into PHP, even if it is optional. Passing $_REQUEST['age']
>>> to a
>>>
>> that $_REQUEST['age'] has been checked for numeric before the
>> functio
>
> would you please not use $_REQUEST in any of your examples? $_REQUEST
> i
On Jan 6, 2008 5:06 AM, Stefan Esser <[EMAIL PROTECTED]> wrote:
> Hello Daniel,
> > It may be off-topic for the initial post, but I disagree
> > wholeheartedly with the above statement, Stefan. There are
> > innumerable reasons where $_REQUEST would be much more economic than
> > writing out a
Hello Daniel,
> It may be off-topic for the initial post, but I disagree
> wholeheartedly with the above statement, Stefan. There are
> innumerable reasons where $_REQUEST would be much more economic than
> writing out all conditions for $_POST, $_GET, $_SESSION, $_COOKIE
>
it doesn't m
Mike Lively wrote:
> That being said I still do agree with Stefan that changing the type of a
> variable would be aweful. I do know that for any purpose I have for
> additional type hinting would actually be solved by just introducing
> type hints for 'scalar' (read string or int) and 'resource'.
On Sat, 2008-01-05 at 21:35 -0500, Sam Barrow wrote:
> On Sat, 2008-01-05 at 15:59 -0800, Mike Lively wrote:
> > > Because type hinting is supposed to limit what kind of variable type
> > > is
> > > allowed for a parameter. When you magically convert you kill the whole
> > > idea of type hints and
On Sat, 2008-01-05 at 15:59 -0800, Mike Lively wrote:
> > Because type hinting is supposed to limit what kind of variable type
> > is
> > allowed for a parameter. When you magically convert you kill the whole
> > idea of type hints and replace it with some magical function parameter
> > auto type c
On Sun, 2008-01-06 at 01:11 +0200, Vlad Bosinceanu wrote:
> Also,
>
> function foo(SomeClass $obj) would error out if passed something other
> than a SomeClass instance, while
> function foo(int $number) would just cast $number to int.
>
> Not really intuitive and not really consistent.
My patc
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Hi,
Mike Lively wrote:
| in the neck to use effectively. If you start using 'int' type checks for
| functions you are going to want to be passing data from _GET, _POST, etc
| to, you will have to do is_numeric checks or something similar, so
| instea
> Because type hinting is supposed to limit what kind of variable type
> is
> allowed for a parameter. When you magically convert you kill the whole
> idea of type hints and replace it with some magical function parameter
> auto type conversion, which would be another hard to understand magic
> fea
On Jan 5, 2008 3:48 PM, Stefan Esser <[EMAIL PROTECTED]> wrote:
> Hello,
> >> typing into PHP, even if it is optional. Passing $_REQUEST['age'] to a
> >>
> > that $_REQUEST['age'] has been checked for numeric before the functio
>
> would you please not use $_REQUEST in any of your examples? $_REQU
Also,
function foo(SomeClass $obj) would error out if passed something other
than a SomeClass instance, while
function foo(int $number) would just cast $number to int.
Not really intuitive and not really consistent.
Regards,
Vlad Bosinceanu
Stefan Esser wrote:
Hello,
typing into PHP, eve
On Sat, Jan 05, 2008 at 10:13:29PM +0100, Stefan Esser wrote:
>
> >> opinion) reason why type hinting should NOT be introduced. BTW accepting
> >> the string '1' where an (int) type hint is placed would be the next
> >> stupid design decision.
> >>
> >
> > Why
> Because type hinting is suppo
>> opinion) reason why type hinting should NOT be introduced. BTW accepting
>> the string '1' where an (int) type hint is placed would be the next
>> stupid design decision.
>>
>
> Why
Because type hinting is supposed to limit what kind of variable type is
allowed for a parameter. When you m
On Sat, Jan 05, 2008 at 09:48:37PM +0100, Stefan Esser wrote:
> Hello,
> >> typing into PHP, even if it is optional. Passing $_REQUEST['age'] to a
> >>
> > that $_REQUEST['age'] has been checked for numeric before the functio
>
> would you please not use $_REQUEST in any of your examples? $
Hello,
>> typing into PHP, even if it is optional. Passing $_REQUEST['age'] to a
>>
> that $_REQUEST['age'] has been checked for numeric before the functio
would you please not use $_REQUEST in any of your examples? $_REQUEST is
one of the biggest design weaknesses in PHP. Every application
30 matches
Mail list logo
