Idea for PHP Enhancement: register_globals_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)craznar.com@ verisign-sux-klj.com
EMail:<01100011 001011100110001 001110101011100 10011010110
110010101000000 011000110111001 001100001011110 10011011100
110000101110010 001011100110001 101101111011011 0100100000>

[Tom Lee]

Re: Idea for PHP Enhancement: register_global s_manual

This sounds like syntactic sugar for something like:

$user_id = $_GET['user_id'];
$credit_card = $_POST['credit_card'];
$really_importa nt_stuff = $_SESSION['really_importa nt_stuff'];

Admittedly, the last example is a bit long, but is that often a problem?

Is there some way to explode elements of an array into the local
namespace of a method?

Still, with all due respect, I can't see the reasoning to this other
than saving a few key strokes.

What's the rationale to this idea? What problem does it solve? Is it
really a problem?

Kind Regards,
Tom L

127.0.0.1 wrote:
[color=blue]
> 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.
>
>
>[/color]

[127.0.0.1]

Re: Idea for PHP Enhancement: register_global s_manual

Tom Lee wrote:
[color=blue]
> This sounds like syntactic sugar for something like:
>
> $really_importa nt_stuff = $_SESSION['really_importa nt_stuff'];[/color]

Not quite, it also adds the

$_SESSION['really_importa nt_stuff'] = $really_importa nt_stuff;

at the appropriate point in an exit routine which no longer needs to be
written.

Someone obviously thought register_global s was a good idea - and it is,
get rid of the carte-blanche approach and it is a great idea.

And anything above machine language is all syntactic sugar anyhow ...
why is that a problem ?

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

[Justin Koivisto]

Re: Idea for PHP Enhancement: register_global s_manual

127.0.0.1 wrote:[color=blue]
> 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.[/color]

IMHO, get rid of regist_globals altogether. ;P

--
Justin Koivisto - spam@koivi.com
PHP POSTERS: Please use comp.lang.php for PHP related questions,
alt.php* groups are not recommended.

[Paulus Magnus]

Re: Idea for PHP Enhancement: register_global s_manual


"127.0.0.1" <newsgroup(at)c raznar.com@veri sign-sux-ijlkl.com> wrote in
message news:s3hgb.1391 03$bo1.72128@ne ws-server.bigpond. net.au...[color=blue]
> 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.[/color]

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. A
programming language often provides shortcuts for programmers and they
partly attract us to that language due to the speed at which we can develop
our applications. However, over time these shortcuts often lead to security
issues or lead us into bad programming style. If the tools to write bad,
insecure code are not there we're less likely to do it.

Paulus

[Tom Lee]

Re: Idea for PHP Enhancement: register_global s_manual

127.0.0.1 wrote:[color=blue]
> Tom Lee wrote:
>
>[color=green]
>>This sounds like syntactic sugar for something like:
>>
>>$really_impor tant_stuff = $_SESSION['really_importa nt_stuff'];[/color]
>
>
> Not quite, it also adds the
>
> $_SESSION['really_importa nt_stuff'] = $really_importa nt_stuff;
>
> at the appropriate point in an exit routine which no longer needs to be
> written.
>[/color]

References?

$really_importa nt_stuff =& $_SESSION['really_importa nt_stuff'];

Should accomplish the same thing.
[color=blue]
> Someone obviously thought register_global s was a good idea - and it is,
> get rid of the carte-blanche approach and it is a great idea.
>[/color]

I think a better approach would be namespace based - ala something like:
httpsession::re ally_important_ stuff;

The current PHP way of doing it is rather similar: it's a hack using
arrays to emulate namespaces.

And PHP 5 won't change the fact that there's no real namespaces in PHP.
How sad.

But I digress.
[color=blue]
> And anything above machine language is all syntactic sugar anyhow ...
> why is that a problem ?
>[/color]

It's not so much about why it's a problem as it is about why it's necessary.

IMO, it's not. At least, not for a minor version upgrade. Maybe PHP 5,
but that feature set is largely set in stone afaik.

And even then I think namespaces are a better way to go about it.
There's a greatly reduced chance of variable naming getting in the way.
And as I said, PHP currently (sorta) implements this approach with arrays.

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? I'd rather
take my chances avoiding namespace collisions, thanks.

[127.0.0.1]

Re: Idea for PHP Enhancement: register_global s_manual

Justin Koivisto wrote:
[color=blue]
> IMHO, get rid of regist_globals altogether. ;P[/color]

Why ?

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

[127.0.0.1]

Re: Idea for PHP Enhancement: register_global s_manual

Paulus Magnus wrote:
[color=blue]
> 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.[/color]

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

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

[Justin Koivisto]

Re: Idea for PHP Enhancement: register_global s_manual

127.0.0.1 wrote:
[color=blue]
> Justin Koivisto wrote:
>
>[color=green]
>>IMHO, get rid of regist_globals altogether. ;P[/color]
>
>
> Why ?[/color]

Then the facility to be sloppy isn't available. Force everyone to be a
little better coder. Besides, if you _really_ waned to, you can alwas do
something like extract($_REQUE ST) to have (I think) the same effect.
Therefore, in order to be sloppy, you have to go out and try to do it. :P

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. Add that in with having the
variable also stored with COOKIES and a database, and you can see why it
causes more problems - you are never quite sure where the value came from.

My $.02

--
Justin Koivisto - spam@koivi.com
PHP POSTERS: Please use comp.lang.php for PHP related questions,
alt.php* groups are not recommended.

[127.0.0.1]

Re: Idea for PHP Enhancement: register_global s_manual

Tom Lee wrote:
[color=blue]
>
> I think a better approach would be namespace based - ala something
> like: httpsession::re ally_important_ stuff;[/color]

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...

[color=blue][color=green]
> > And anything above machine language is all syntactic sugar anyhow
> > ... why is that a problem ?
> >[/color]
> It's not so much about why it's a problem as it is about why it's
> necessary.
>
> IMO, it's not.[/color]

Well - after 7 years of web programming Delphi/IIS, I'm finding PHP
session handling in conjunction with templating a real problem.
[color=blue]
>
> 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?[/color]

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



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

[127.0.0.1]

Re: Idea for PHP Enhancement: register_global s_manual

Justin Koivisto wrote:
[color=blue]
> Then the facility to be sloppy isn't available.[/color]

My suggestion removes the sloppy factor - but keeps the functionality.
[color=blue]
> 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.[/color]

Which is got around by the concept I suggested.



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

[André Næss]

Re: Idea for PHP Enhancement: register_global s_manual

127.0.0.1:
[color=blue]
> 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.[/color]

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]

Re: Idea for PHP Enhancement: register_global s_manual

André Næss wrote:
[color=blue]
> 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'];[/color]

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)craznar.com@ verisign-sux-klj.com
EMail:<01100011 001011100110001 001110101011100 10011010110
110010101000000 011000110111001 001100001011110 10011011100
110000101110010 001011100110001 101101111011011 0100100000>

[Paulus Magnus]

Re: Idea for PHP Enhancement: register_global s_manual


"127.0.0.1" <newsgroup(at)c raznar.com@veri sign-sux-ijlkl.com> wrote in
message news:0nlgb.1391 78$bo1.20224@ne ws-server.bigpond. net.au...[color=blue]
> Paulus Magnus wrote:
>[color=green]
> > 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.[/color]
>
> So - any comments on the concept of a modified register_global s ability
> ?[/color]

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]

Re: Idea for PHP Enhancement: register_global s_manual

"127.0.0.1" <newsgroup(at)c raznar.com@veri sign-sux-ijlkl.com> wrote in
message news:Xqlgb.1391 80$bo1.59147@ne ws-server.bigpond. net.au...[color=blue]
> Tom Lee wrote:
>[color=green]
> >
> > I think a better approach would be namespace based - ala something
> > like: httpsession::re ally_important_ stuff;[/color]
>
> 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...[/color]

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.
[color=blue]
> Well - after 7 years of web programming Delphi/IIS, I'm finding PHP
> session handling in conjunction with templating a real problem.[/color]

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.
[color=blue][color=green]
> > 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?[/color]
>
> It isn't about saving keystrokes - it is about enabling some
> functionality.. .[/color]

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