Idea for PHP Enhancement: register_global s_manual

[127.0.0.1]

With all the problems with having register_global s = on, I propose the
following idea:

We define register_global s_manual = on as a new configuration default.

What this does is enable 3 new explicit variable declaration mechanisms
with the same syntax as the existing static and global mechanisms.

They would be httpget, httppost and session, so for example:

httpget $user_id;
httppost $credit_card;
session $really_importa nt_stuff;

Each of these declaration lines would effectively enable
register_global s for one specific variable in one particular method
(GET, POST or session).

Creative suggestions, comments would be welcome.

--
Spam:newsgroup( at)cr*********@ verisign-sux-klj.com
EMail:<01100011 001011100110001 001110101011100 10011010110
110010101000000 011000110111001 001100001011110 10011011100
110000101110010 001011100110001 101101111011011 0100100000>

[127.0.0.1]

Justin Koivisto wrote:

Then the facility to be sloppy isn't available.
My suggestion removes the sloppy factor - but keeps the functionality.
I used to do everything with register_global s on, and quickly learned
that it's a nightmare to debug when you happen to be using the same
variable name via POST and GET requests.

Which is got around by the concept I suggested.

--
Spam:newsgroup( at)cr*********@ verisign-sux-klj.com
EMail:<01100011 001011100110001 001110101011100 10011010110
110010101000000 011000110111001 001100001011110 10011011100
110000101110010 001011100110001 101101111011011 0100100000>

[André Næss]

127.0.0.1:

With all the problems with having register_global s = on, I propose the
following idea:

We define register_global s_manual = on as a new configuration default.

What this does is enable 3 new explicit variable declaration mechanisms
with the same syntax as the existing static and global mechanisms.

They would be httpget, httppost and session, so for example:

httpget $user_id;
httppost $credit_card;
session $really_importa nt_stuff;

Each of these declaration lines would effectively enable
register_global s for one specific variable in one particular method
(GET, POST or session).

Creative suggestions, comments would be welcome.

I can't see what you gain. I'm perfectly happy using $_GET, $_POST etc.
directly. Polluting the global namespace with variables simply isn't a good
idea.

Why do you think it's easier to write
httpget $user_id;
than
$_GET['user_id'];

?

André Næss

[127.0.0.1]

André Næss wrote:

I can't see what you gain. I'm perfectly happy using $_GET, $_POST
etc. directly. Polluting the global namespace with variables simply
isn't a good idea.

Why do you think it's easier to write
httpget $user_id;
than
$_GET['user_id'];

It is far easier to write

session $blah;

than to write

$blah = $_SESSION['blah'];
register exit routine;
..
..
..
..
..

exit_routine
$_SESSION['blah'] = $blah
etc

--
Spam:newsgroup( at)cr*********@ verisign-sux-klj.com
EMail:<01100011 001011100110001 001110101011100 10011010110
110010101000000 011000110111001 001100001011110 10011011100
110000101110010 001011100110001 101101111011011 0100100000>

[Paulus Magnus]

"127.0.0.1" <newsgroup(at)c r*********@veri sign-sux-ijlkl.com> wrote in
message news:0n******** ************@ne ws-server.bigpond. net.au...

Paulus Magnus wrote:

As much inconvenience as register_global s has caused me personally, I
do believe the world is a safer place because of it being changed.

So - any comments on the concept of a modified register_global s ability
?

I couldn't see a benefit from allowing specified variables to be global.
It's very similar to my own bit of code...

$user_id = (isset ($_GET['user_id'])) ? $_GET['user_id'] : "";

....that I've used to kludge code that was written pre-register_global s=off.
You could use the $_REQUEST array if you wanted but I think that's another
sloppy mechanism that should be removed as well.

All my new scripts tend to read/write to the superglobal arrays as I need to
as I prefer to use arrays of variables anyhow. It's almost a way of
categorising them. For example I don't use $host, $database, $username and
$password for MySQL. I use $mysql['host'], $mysql['database'],
$mysql['username'] and $mysql['password']. As long as my code is readable I
don't mind.

$_GET['u'] isn't readable, $_GET['user_id'] is, $user_id is more readable
but it's another variable I have to initialise. Therefore, if I'm using GET
to pass variables I tend to use single letter variable names and then swap
them using a little isset initialisation above to make them more readable.
If I'm passing variables via COOKIE, SESSION or POST I use meaningful names
as the user can't see them and it saves me doing a
quasi-register_global s_manually.

Paulus

[Paulus Magnus]

"127.0.0.1" <newsgroup(at)c r*********@veri sign-sux-ijlkl.com> wrote in
message news:Xq******** ************@ne ws-server.bigpond. net.au...

Tom Lee wrote:

I think a better approach would be namespace based - ala something
like: httpsession::re ally_important_ stuff;
Then it would be pointless ... if we have to use XXXX<varname>XX XX,
then XXXX might as well be $_SESSION, as httpsession:: ... i'm trying
to come up with a secure version of register_global s...

I don't think the security hole is that large from register_global s. It's
how that posted data is validated before processing it that is the problem.
PHP can help to close this security by turning off register globals, the
other 90% of the job is down to the programmer.
Well - after 7 years of web programming Delphi/IIS, I'm finding PHP
session handling in conjunction with templating a real problem.

It depends on your templating solution. I have no problem with it and find
the use of templating to be a major assistance to my application
development. I don't have to clutter my code with bits of HTML any more and
that makes my algorithm and flow of processing incredibly easy. However, I
do know that many of the template systems out there are a language all to
themselves. I've seen them being used, seen code written with them and
thought I'm not going there. I'm not learning a template pseudo-code, it's
just not necessary.

I agree that there's probably nicer ways to go about it
syntactically, but on the level that it's merely saving a few key
strokes?

It isn't about saving keystrokes - it is about enabling some
functionality.. .

I think anything that translates posted data to processing without making
the developer think is bad. Security is not something you can teach or list
in a 10 step plan as each script has its weak points. If you're manipulating
data based on the input provided by a user, you really need to think "what
if?". Register globals is just a small part of the security issue and you
can move variables to normal pretty variables in one line using the isset()
and ternary operator as I've shown on another post in this thread.

Paulus

[jack]

127.0.0.1 wrote:

With all the problems with having register_global s = on, I propose the
following idea:

We define register_global s_manual = on as a new configuration
default.
Creative suggestions, comments would be welcome.

Function "import_request _variables()" is not enough for you? :))

--
--- --- --- --- --- --- ---
ja**@croatiabiz .com

[Phil Roberts]

With total disregard for any kind of safety measures "127.0.0.1"
<newsgroup(at)c r*********@veri sign-sux-ijlkl.com> leapt forth and
uttered:

Justin Koivisto wrote:

Then the facility to be sloppy isn't available.

My suggestion removes the sloppy factor - but keeps the
functionality.

I used to do everything with register_global s on, and quickly
learned that it's a nightmare to debug when you happen to be
using the same variable name via POST and GET requests.

Which is got around by the concept I suggested.

But what is the POINT of your method when PHP has plenty of non-
register_global s reliant methods already?

You just seem to be trying to come up with a way to reverse-
engineer what was a bad idea in the first place.

--
There is no signature.....

[Phil Roberts]

With total disregard for any kind of safety measures "127.0.0.1"
<newsgroup(at)c r*********@veri sign-sux-ijlkl.com> leapt forth and
uttered:

André Næss wrote:

I can't see what you gain. I'm perfectly happy using $_GET,
$_POST etc. directly. Polluting the global namespace with
variables simply isn't a good idea.

Why do you think it's easier to write
httpget $user_id;
than
$_GET['user_id'];

It is far easier to write

session $blah;

than to write

$blah = $_SESSION['blah'];
register exit routine;
.
.
.
.
.

exit_routine
$_SESSION['blah'] = $blah
etc

So don't do $blah = $_SESSION['blah']; then, just use
$_SESSION['blah'] directly.

I cannot understand why you put more importance on code aesthetics
than efficient design.

--
There is no signature.....

[127.0.0.1]

Phil Roberts wrote:

But what is the POINT of your method when PHP has plenty of non-
register_global s reliant methods already?

It doesn't have one for SESSION variables yet ....

--
Spam:newsgroup( at)cr*********@ verisign-sux-klj.com
EMail:<01100011 001011100110001 001110101011100 10011010110
110010101000000 011000110111001 001100001011110 10011011100
110000101110010 001011100110001 101101111011011 0100100000>

[127.0.0.1]

Phil Roberts wrote:

So don't do $blah = $_SESSION['blah']; then, just use
$_SESSION['blah'] directly.
I can't...

I cannot understand why you put more importance on code aesthetics
than efficient design.

I don't...

--
Spam:newsgroup( at)cr*********@ verisign-sux-klj.com
EMail:<01100011 001011100110001 001110101011100 10011010110
110010101000000 011000110111001 001100001011110 10011011100
110000101110010 001011100110001 101101111011011 0100100000>