On Jul 7, 2008, at 2:19 PM, Eric Butera wrote:
On Mon, Jul 7, 2008 at 2:47 PM, mike <[EMAIL PROTECTED]> wrote:
On 7/7/08, Eric Butera <[EMAIL PROTECTED]> wrote:
Laziness/convenience.
I always get my data from the exact source I want. If someone
chooses
to use REQUEST it shouldn't break th
Daniel Brown schreef:
On Mon, Jul 7, 2008 at 2:47 PM, mike <[EMAIL PROTECTED]> wrote:
I don't see why if you -know- you need $_COOKIE['username'] someone
would be lazy and use $_REQUEST['username']
That's the point --- it's intended as a fallback where you *don't*
know the method that will
On Mon, Jul 7, 2008 at 8:08 PM, mike <[EMAIL PROTECTED]> wrote:
>
> The problem is, the cat's out of the bag now and a lot of people are
> just being lazy (in my mind) especially those who are used to ASP's
> Request.Value() which unfortunately is a lot of our developers at
> work. They don't have
On 7/7/08, Eric Butera <[EMAIL PROTECTED]> wrote:
> You asked for an explanation. I was just stating that is how I've
> seen some people write apps. I've also stated that isn't how I write
> them either. I use something along these lines:
This is true. I really wanted to ask the internals folk
On Mon, Jul 7, 2008 at 3:28 PM, mike <[EMAIL PROTECTED]> wrote:
> On 7/7/08, Eric Butera <[EMAIL PROTECTED]> wrote:
>
>> If your app is
>> written correctly it doesn't matter what is thrown at it, it should
>> always work. Even if a variable gets overridden it should still be
>> forced to play wit
>
> *cough* ... Request.Value? That seems like lazy VB.NET/ASP.NET code to me.
> :) It can be split into either Request.QueryString (for GET) or Request.Form
> (for POST). Anyway, a bit OT...
>
>
> Todd Boyd
> Web Programmer
>
>
> ASP is the best *hack hack* :-P
--
Bastien
Cat, the other othe
> -Original Message-
> From: mike [mailto:[EMAIL PROTECTED]
> Sent: Monday, July 07, 2008 2:09 PM
> To: Daniel Brown
> Cc: Eric Butera; php-general@lists.php.net
> Subject: Re: [PHP] Looking for a reasonable explanation as to why
> $_REQUEST exists
>
> On 7
At 3:00 PM -0400 7/7/08, Bastien Koert wrote:
Where I see this used a lot is in searching/pagination type scenarios...for
the submission, the form is POSTED and then on subsequent pages, the data is
stored in the url and posted back to the same script. Using $_REQUEST means
that you won't really
On 7/7/08, Eric Butera <[EMAIL PROTECTED]> wrote:
> If your app is
> written correctly it doesn't matter what is thrown at it, it should
> always work. Even if a variable gets overridden it should still be
> forced to play with the rules of the app and work like a valid request
> does.
That is n
On Mon, Jul 7, 2008 at 2:47 PM, mike <[EMAIL PROTECTED]> wrote:
> On 7/7/08, Eric Butera <[EMAIL PROTECTED]> wrote:
>
>> Laziness/convenience.
>>
>> I always get my data from the exact source I want. If someone chooses
>> to use REQUEST it shouldn't break their application. You say it is a
>> sec
mike wrote:
On 7/7/08, Eric Butera <[EMAIL PROTECTED]> wrote:
Laziness/convenience.
I always get my data from the exact source I want. If someone chooses
to use REQUEST it shouldn't break their application. You say it is a
security risk, but not really. As long as everything is
filtered/esc
On Mon, Jul 7, 2008 at 3:08 PM, mike <[EMAIL PROTECTED]> wrote:
>
> Then code for it :P I understand the idea, I don't see the need to
> create a dedicated construct in PHP for it. Part of PHP's power to me
> was finally getting away from the lazy ASP (VB-based)
> Request.Value('foo') or whatever i
On 7/7/08, Daniel Brown <[EMAIL PROTECTED]> wrote:
> That's the point --- it's intended as a fallback where you *don't*
> know the method that will be used, or if you want to be lackadaisical
> with your code (which, as we all know, is HIGHLY unrecommended).
Then you should code for that, not fal
On Mon, Jul 7, 2008 at 2:55 PM, Shawn McKenzie <[EMAIL PROTECTED]> wrote:
> mike wrote:
>
>> On 7/7/08, Eric Butera <[EMAIL PROTECTED]> wrote:
>>
>> Laziness/convenience.
>>>
>>> I always get my data from the exact source I want. If someone chooses
>>> to use REQUEST it shouldn't break their app
On Mon, Jul 7, 2008 at 2:47 PM, mike <[EMAIL PROTECTED]> wrote:
>
> I don't see why if you -know- you need $_COOKIE['username'] someone
> would be lazy and use $_REQUEST['username']
That's the point --- it's intended as a fallback where you *don't*
know the method that will be used, or if you
mike wrote:
On 7/7/08, Eric Butera <[EMAIL PROTECTED]> wrote:
Laziness/convenience.
I always get my data from the exact source I want. If someone chooses
to use REQUEST it shouldn't break their application. You say it is a
security risk, but not really. As long as everything is
filtered/esc
On 7/7/08, Eric Butera <[EMAIL PROTECTED]> wrote:
> Laziness/convenience.
>
> I always get my data from the exact source I want. If someone chooses
> to use REQUEST it shouldn't break their application. You say it is a
> security risk, but not really. As long as everything is
> filtered/escaped
On Mon, Jul 7, 2008 at 12:33 PM, metastable
<[EMAIL PROTECTED]> wrote:
>
> Cliff, is that you ? Cliff Clavin ?
Very astute of you, but I consider myself more of a Norm Peterson. ;-P
--
Dedicated Servers - Intel 2.4GHz w/2TB bandwidth/mo. starting at just
$59.99/mo. with no contract!
Dedica
Daniel Brown wrote:
On Mon, Jul 7, 2008 at 11:43 AM, Shawn McKenzie <[EMAIL PROTECTED]> wrote:
They can be what? I was wrong, the S is $_SERVER not $_SESSION.
Sorry, Shawn. That message was meant for the OP, but I clipped
your message to send a response to you as well.
Disre
On Mon, Jul 7, 2008 at 11:43 AM, Shawn McKenzie <[EMAIL PROTECTED]> wrote:
> They can be what? I was wrong, the S is $_SERVER not $_SESSION.
Sorry, Shawn. That message was meant for the OP, but I clipped
your message to send a response to you as well.
Disregard. The body is here, but t
They can be what? I was wrong, the S is $_SERVER not $_SESSION.
-Shawn
Daniel Brown wrote:
On Mon, Jul 7, 2008 at 11:23 AM, Shawn McKenzie <[EMAIL PROTECTED]> wrote:
When you use register_globals it extracts the vars from get, post, cookie
and session, or used to. But, I don't think sessio
On Mon, Jul 7, 2008 at 11:36 AM, Shawn McKenzie <[EMAIL PROTECTED]> wrote:
> So I was 50% correct. That's better than my normal 0%-33%.
Haha ;)
--
PHP General Mailing List (http://www.php.net/)
To unsubscribe, visit: http://www.php.net/unsub.php
On Mon, Jul 7, 2008 at 11:23 AM, Shawn McKenzie <[EMAIL PROTECTED]> wrote:
>
> When you use register_globals it extracts the vars from get, post, cookie
> and session, or used to. But, I don't think session vars are in $_REQUEST.
They can be. Google "EGPCS".
--
Dedicated Servers - Intel 2.
Eric Butera wrote:
On Mon, Jul 7, 2008 at 11:23 AM, Shawn McKenzie <[EMAIL PROTECTED]> wrote:
When you use register_globals it extracts the vars from get, post, cookie
and session, or used to. But, I don't think session vars are in $_REQUEST.
-Shawn
http://us2.php.net/manual/en/ini.core.php#
[snip]
When you use register_globals it extracts the vars from get, post,
cookie and session, or used to. But, I don't think session vars are in
$_REQUEST.
[/snip]
$_REQUEST is no different than $_POST or $_GET from a security
standpoint. And using register_globals did not carry a security risk
On Mon, Jul 7, 2008 at 11:23 AM, Shawn McKenzie <[EMAIL PROTECTED]> wrote:
> When you use register_globals it extracts the vars from get, post, cookie
> and session, or used to. But, I don't think session vars are in $_REQUEST.
>
> -Shawn
http://us2.php.net/manual/en/ini.core.php#ini.request-orde
Eric Butera wrote:
On Mon, Jul 7, 2008 at 3:10 AM, mike <[EMAIL PROTECTED]> wrote:
I have never had a use for this feature. To me it introduces another
register_globals style atttack vector. I see no need why people need
to combine post/get/etc variables into the same superglobal. I
actually run
On Mon, Jul 7, 2008 at 3:10 AM, mike <[EMAIL PROTECTED]> wrote:
> I have never had a use for this feature. To me it introduces another
> register_globals style atttack vector. I see no need why people need
> to combine post/get/etc variables into the same superglobal. I
> actually run unset($_REQUE
I have never had a use for this feature. To me it introduces another
register_globals style atttack vector. I see no need why people need
to combine post/get/etc variables into the same superglobal. I
actually run unset($_REQUEST) on it at the top of my library to
discourage its use.
For third par
29 matches
Mail list logo
