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 their
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($_REQUEST)
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 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-order
--
[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
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
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.
--
/Daniel P. Brown
Dedicated Servers
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
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 session
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 the
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.
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
--
/Daniel P. Brown
Dedicated Servers - Intel 2.4GHz w/2TB bandwidth/mo. starting at just
$59.99/mo. with no
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
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
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 want
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 application. You say
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
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 it was
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
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
security risk, but
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 not an
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
-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/7/08, Daniel Brown [EMAIL PROTECTED]
*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 other white
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 with the rules
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 folks
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 a real
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
28 matches
Mail list logo
