By using this site, you agree to our updated Privacy Policy and our Terms of Use. Manage your Cookies Settings.
458,110 Members | 1,537 Online
Bytes IT Community
+ Ask a Question
Need help? Post your question and get tips & solutions from a community of 458,110 IT Pros & Developers. It's quick & easy.

Idea for PHP Enhancement: register_globals_manual

P: n/a
With all the problems with having register_globals = on, I propose the
following idea:

We define register_globals_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_important_stuff;

Each of these declaration lines would effectively enable
register_globals 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:<0110001100101110011000100111010101110010011 010110
11001010100000001100011011100100110000101111010011 011100
11000010111001000101110011000110110111101101101001 00000>
Jul 17 '05 #1
Share this Question
Share on Google+
50 Replies


P: n/a
This sounds like syntactic sugar for something like:

$user_id = $_GET['user_id'];
$credit_card = $_POST['credit_card'];
$really_important_stuff = $_SESSION['really_important_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:
With all the problems with having register_globals = on, I propose the
following idea:

We define register_globals_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_important_stuff;

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

Creative suggestions, comments would be welcome.


Jul 17 '05 #2

P: n/a
Tom Lee wrote:
This sounds like syntactic sugar for something like:

$really_important_stuff = $_SESSION['really_important_stuff'];


Not quite, it also adds the

$_SESSION['really_important_stuff'] = $really_important_stuff;

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

Someone obviously thought register_globals 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)cr*********@verisign-sux-klj.com
EMail:<0110001100101110011000100111010101110010011 010110
11001010100000001100011011100100110000101111010011 011100
11000010111001000101110011000110110111101101101001 00000>
Jul 17 '05 #3

P: n/a
127.0.0.1 wrote:
With all the problems with having register_globals = on, I propose the
following idea:

We define register_globals_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_important_stuff;

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

Creative suggestions, comments would be welcome.


IMHO, get rid of regist_globals altogether. ;P

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

Jul 17 '05 #4

P: n/a

"127.0.0.1" <newsgroup(at)cr*********@verisign-sux-ijlkl.com> wrote in
message news:s3********************@news-server.bigpond.net.au...
With all the problems with having register_globals = on, I propose the
following idea:

We define register_globals_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_important_stuff;

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

Creative suggestions, comments would be welcome.


As much inconvenience as register_globals 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
Jul 17 '05 #5

P: n/a
127.0.0.1 wrote:
Tom Lee wrote:

This sounds like syntactic sugar for something like:

$really_important_stuff = $_SESSION['really_important_stuff'];

Not quite, it also adds the

$_SESSION['really_important_stuff'] = $really_important_stuff;

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


References?

$really_important_stuff =& $_SESSION['really_important_stuff'];

Should accomplish the same thing.
Someone obviously thought register_globals was a good idea - and it is,
get rid of the carte-blanche approach and it is a great idea.

I think a better approach would be namespace based - ala something like:
httpsession::really_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.
And anything above machine language is all syntactic sugar anyhow ...
why is that a problem ?


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.

Jul 17 '05 #6

P: n/a
Justin Koivisto wrote:
IMHO, get rid of regist_globals altogether. ;P


Why ?

--
Spam:newsgroup(at)cr*********@verisign-sux-klj.com
EMail:<0110001100101110011000100111010101110010011 010110
11001010100000001100011011100100110000101111010011 011100
11000010111001000101110011000110110111101101101001 00000>
Jul 17 '05 #7

P: n/a
Paulus Magnus wrote:
As much inconvenience as register_globals 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_globals ability
?

--
Spam:newsgroup(at)cr*********@verisign-sux-klj.com
EMail:<0110001100101110011000100111010101110010011 010110
11001010100000001100011011100100110000101111010011 011100
11000010111001000101110011000110110111101101101001 00000>
Jul 17 '05 #8

P: n/a
127.0.0.1 wrote:
Justin Koivisto wrote:

IMHO, get rid of regist_globals altogether. ;P

Why ?


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($_REQUEST) 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_globals 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 - sp**@koivi.com
PHP POSTERS: Please use comp.lang.php for PHP related questions,
alt.php* groups are not recommended.

Jul 17 '05 #9

P: n/a
Tom Lee wrote:

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

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

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

IMO, it's not.


Well - after 7 years of web programming Delphi/IIS, I'm finding PHP
session handling in conjunction with templating a real problem.

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

--
Spam:newsgroup(at)cr*********@verisign-sux-klj.com
EMail:<0110001100101110011000100111010101110010011 010110
11001010100000001100011011100100110000101111010011 011100
11000010111001000101110011000110110111101101101001 00000>
Jul 17 '05 #10

P: n/a
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_globals 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:<0110001100101110011000100111010101110010011 010110
11001010100000001100011011100100110000101111010011 011100
11000010111001000101110011000110110111101101101001 00000>
Jul 17 '05 #11

P: n/a
127.0.0.1:
With all the problems with having register_globals = on, I propose the
following idea:

We define register_globals_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_important_stuff;

Each of these declaration lines would effectively enable
register_globals 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
Jul 17 '05 #12

P: n/a
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:<0110001100101110011000100111010101110010011 010110
11001010100000001100011011100100110000101111010011 011100
11000010111001000101110011000110110111101101101001 00000>
Jul 17 '05 #13

P: n/a

"127.0.0.1" <newsgroup(at)cr*********@verisign-sux-ijlkl.com> wrote in
message news:0n********************@news-server.bigpond.net.au...
Paulus Magnus wrote:
As much inconvenience as register_globals 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_globals 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_globals=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_globals_manually.

Paulus
Jul 17 '05 #14

P: n/a
"127.0.0.1" <newsgroup(at)cr*********@verisign-sux-ijlkl.com> wrote in
message news:Xq********************@news-server.bigpond.net.au...
Tom Lee wrote:

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


I don't think the security hole is that large from register_globals. 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
Jul 17 '05 #15

P: n/a
127.0.0.1 wrote:
With all the problems with having register_globals = on, I propose the
following idea:

We define register_globals_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
Jul 17 '05 #16

P: n/a
With total disregard for any kind of safety measures "127.0.0.1"
<newsgroup(at)cr*********@verisign-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_globals 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_globals 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.....
Jul 17 '05 #17

P: n/a
With total disregard for any kind of safety measures "127.0.0.1"
<newsgroup(at)cr*********@verisign-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.....
Jul 17 '05 #18

P: n/a
Phil Roberts wrote:
But what is the POINT of your method when PHP has plenty of non-
register_globals reliant methods already?


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

--
Spam:newsgroup(at)cr*********@verisign-sux-klj.com
EMail:<0110001100101110011000100111010101110010011 010110
11001010100000001100011011100100110000101111010011 011100
11000010111001000101110011000110110111101101101001 00000>
Jul 17 '05 #19

P: n/a
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:<0110001100101110011000100111010101110010011 010110
11001010100000001100011011100100110000101111010011 011100
11000010111001000101110011000110110111101101101001 00000>
Jul 17 '05 #20

P: n/a
127.0.0.1 <newsgroup(at)cr*********@verisign-sux-ijlkl.com> wrote:
Phil Roberts wrote:
But what is the POINT of your method when PHP has plenty of non-
register_globals reliant methods already?


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


extract($_SESSION);

JOn
Jul 17 '05 #21

P: n/a
Jon Kraft wrote:
But what is the POINT of your method when PHP has plenty of non-
register_globals reliant methods already?


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


extract($_SESSION);


How does that get a session variable 'X' into and out of $X ?

--
Spam:newsgroup(at)cr*********@verisign-sux-klj.com
EMail:<0110001100101110011000100111010101110010011 010110
11001010100000001100011011100100110000101111010011 011100
11000010111001000101110011000110110111101101101001 00000>
Jul 17 '05 #22

P: n/a
127.0.0.1 <newsgroup(at)cr*********@verisign-sux-ijlkl.com> wrote:
Jon Kraft wrote:
>> But what is the POINT of your method when PHP has plenty of non-
>> register_globals reliant methods already?
>
> It doesn't have one for SESSION variables yet ....


extract($_SESSION);


How does that get a session variable 'X' into and out of $X ?


extract() attempts to create variables (names = keys) from an associative
array.
The advantage of extract() is that it provides a high level of control
through the parameter "extract_type", which a simple register_global
variant wouldn't.

JOn
Jul 17 '05 #23

P: n/a
Jon Kraft wrote:

extract($_SESSION);


How does that get a session variable 'X' into and out of $X ?


extract() attempts to create variables (names = keys) from an
associative array.


SO - how does that get session variable 'x' into and out of $x ?

--
Spam:newsgroup(at)cr*********@verisign-sux-klj.com
EMail:<0110001100101110011000100111010101110010011 010110
11001010100000001100011011100100110000101111010011 011100
11000010111001000101110011000110110111101101101001 00000>
Jul 17 '05 #24

P: n/a
127.0.0.1 <newsgroup(at)cr*********@verisign-sux-ijlkl.com> wrote:
Jon Kraft wrote:
>>
>> extract($_SESSION);
>
> How does that get a session variable 'X' into and out of $X ?


extract() attempts to create variables (names = keys) from an
associative array.


SO - how does that get session variable 'x' into and out of $x ?


Sorry, I don't get your question - if it is a question and not a rhetorical
statement that renders my suggestion useless?

Let's say we have a session variable "x" ($_SESSION['x']).
extract()'s default behaviour would result either in a new variable $x or an
assignment of the value of the session variable "x" to the existing
variable $x. If you assign another value to $x, it is overwritten (again),
which doesn't change the value of the session variable "x" unless you tell
extract() to create the (new) variables by reference (EXTR_REFS,
PHP>=4.3.0).

Please enlighten me if I totally misunderstood what you were after.

JOn
Jul 17 '05 #25

P: n/a
Jon Kraft wrote:
Please enlighten me if I totally misunderstood what you were after.


I'm after the ability to use the variable $x in a script, such that
between requests from the client it retains its value.

That is all.

By variable $x I mean $x, $fred, $user_id, not $_XZJ[14] or anything
else.

--
Spam:newsgroup(at)cr*********@verisign-sux-klj.com
EMail:<0110001100101110011000100111010101110010011 010110
11001010100000001100011011100100110000101111010011 011100
11000010111001000101110011000110110111101101101001 00000>
Jul 17 '05 #26

P: n/a
127.0.0.1 wrote:
With all the problems with having register_globals = on, I propose the
following idea:

We define register_globals_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_important_stuff;

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

Creative suggestions, comments would be welcome.


$user_id =& $_GET['user_id'];
$credit_card =& $_POST['credit_card'];
$really_important_stuff =& $_SESSION['really_important_stuff'];

works fine, I use it all the time.

Jul 17 '05 #27

P: n/a
Kevin Thorpe wrote:
$really_important_stuff =& $_SESSION['really_important_stuff'];

works fine, I use it all the time.


So the following would work ?

First Client Request...
session_start();
$X =& $_SESSION['X'];
$Y = 'Fred';
$X = $Y;

Second client request...
session_start();
$X =& $_SESSION['X'];
$Y = $X;
echo($Y); ... printing 'Fred'....

--
Spam:newsgroup(at)cr*********@verisign-sux-klj.com
EMail:<0110001100101110011000100111010101110010011 010110
11001010100000001100011011100100110000101111010011 011100
11000010111001000101110011000110110111101101101001 00000>
Jul 17 '05 #28

P: n/a
127.0.0.1 <newsgroup(at)cr*********@verisign-sux-ijlkl.com> wrote:
Jon Kraft wrote:
Please enlighten me if I totally misunderstood what you were after.


I'm after the ability to use the variable $x in a script, such that
between requests from the client it retains its value.

That is all.

By variable $x I mean $x, $fred, $user_id, not $_XZJ[14] or anything
else.


Check my previous reply (and the manual for extract()) for the extract_type
"EXTR_REFS".
An assignment of a new value to $x would then in fact change the session
variable "x".

HTH;
JOn
Jul 17 '05 #29

P: n/a
127.0.0.1 wrote:
Kevin Thorpe wrote:
$really_important_stuff =& $_SESSION['really_important_stuff'];

works fine, I use it all the time.


So the following would work ?

First Client Request...
session_start();
$X =& $_SESSION['X'];
$Y = 'Fred';
$X = $Y;

Second client request...
session_start();
$X =& $_SESSION['X'];
$Y = $X;
echo($Y); ... printing 'Fred'....


Yes, it would (see test script):

<?php
if(!isset($_GET['next'])){
// First Client Request...
session_start();
$X =& $_SESSION['X'];
$Y = 'Fred';
$X = $Y;
echo '$_SESSION[\'X\']: ',$_SESSION['X'],'<br>';
echo '$X: ',$X,'<br>';
echo '$Y: ',$Y,'<br>';
echo '<a href="?next">next</a>';
}else{
// Second client request...
session_start();
$X =& $_SESSION['X'];
$Y = $X;
echo '$_SESSION[\'X\']: ',$_SESSION['X'],'<br>';
echo '$X: ',$X,'<br>';
echo '$Y: ',$Y,'<br>';
}
?>
--
Justin Koivisto - sp**@koivi.com
PHP POSTERS: Please use comp.lang.php for PHP related questions,
alt.php* groups are not recommended.

Jul 17 '05 #30

P: n/a
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'];


But why duplicate the variable in the first place? Why not simply use
$_SESSION['blah'] directly? This also has the advantage of making the code
easier to understand because you know precisely from where
$_SESSION['blah'] is coming, something you don't if using just $blah (of
course, if the use follows immediately after the declaration this is no
major issue).

So while I'll agree that your proposed syntax does in fact simplify the use
of GPC variables I think it's actually important to make the use of these
variables more evident (it's like there's a small tax on their use), and so
I must give it thumbs down.

André Nęss
Jul 17 '05 #31

P: n/a
André Nęss wrote:
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'];

But why duplicate the variable in the first place? Why not simply use
$_SESSION['blah'] directly? This also has the advantage of making the code
easier to understand because you know precisely from where
$_SESSION['blah'] is coming, something you don't if using just $blah


I agree on this completely. I do all my scripting and testing with
register_globals = off for a few reasons:

1. Makes the code easier to follow in the future (and for others).
2. Portability to other servers. (This is a big one for me.)
3. Prevents me from getting too sloppy, allowing many security holes.
So while I'll agree that your proposed syntax does in fact simplify the use
of GPC variables I think it's actually important to make the use of these
variables more evident (it's like there's a small tax on their use), and so
I must give it thumbs down.


I too do not approve of such a proposal, especially when you can use the
extract function with the EXTR_REFS flag to do it anyway.

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

Jul 17 '05 #32

P: n/a
Jon Kraft wrote:
Check my previous reply (and the manual for extract()) for the
extract_type "EXTR_REFS".
An assignment of a new value to $x would then in fact change the
session variable "x".


I'm sorry - but I'm still running of a PHP 3/4.0 reference ....
--
Spam:newsgroup(at)cr*********@verisign-sux-klj.com
EMail:<0110001100101110011000100111010101110010011 010110
11001010100000001100011011100100110000101111010011 011100
11000010111001000101110011000110110111101101101001 00000>
Jul 17 '05 #33

P: n/a
Justin Koivisto <sp**@koivi.com> writes:
I too do not approve of such a proposal, especially when you can use
the extract function with the EXTR_REFS flag to do it anyway.


Isn't using the extract function equivalent to register_globals=on?
This proposal is not.

Jul 17 '05 #34

P: n/a
Excellent - that works ... but what is this on the URL

PHPSESSID=d307df95a704af2719819f6d96dac42c

.... isn't that meant to go in the cookies, I can't have it in the URL.

Justin Koivisto wrote:
<?php
if(!isset($_GET['next'])){
// First Client Request...
session_start();
$X =& $_SESSION['X'];
$Y = 'Fred';
$X = $Y;
echo '$_SESSION[\'X\']: ',$_SESSION['X'],'<br>';
echo '$X: ',$X,'<br>';
echo '$Y: ',$Y,'<br>';
echo '<a href="?next">next</a>';
}else{
// Second client request...
session_start();
$X =& $_SESSION['X'];
$Y = $X;
echo '$_SESSION[\'X\']: ',$_SESSION['X'],'<br>';
echo '$X: ',$X,'<br>';
echo '$Y: ',$Y,'<br>';
}
?>


--
Spam:newsgroup(at)cr*********@verisign-sux-klj.com
EMail:<0110001100101110011000100111010101110010011 010110
11001010100000001100011011100100110000101111010011 011100
11000010111001000101110011000110110111101101101001 00000>
Jul 17 '05 #35

P: n/a
André Nęss wrote:
But why duplicate the variable in the first place? Why not simply use
$_SESSION['blah'] directly? T


Been there done that ... I can't.

--
Spam:newsgroup(at)cr*********@verisign-sux-klj.com
EMail:<0110001100101110011000100111010101110010011 010110
11001010100000001100011011100100110000101111010011 011100
11000010111001000101110011000110110111101101101001 00000>
Jul 17 '05 #36

P: n/a
127.0.0.1 wrote:
Excellent - that works ... but what is this on the URL

PHPSESSID=d307df95a704af2719819f6d96dac42c

... isn't that meant to go in the cookies, I can't have it in the URL.


I think your installation is set up to try and detect if cookies are
enabled. It puts this on the URL and in a cookie to start with to see
which works. It will disappear in further requests now it's seen thet
cookies work.

Our installation does this as well. You can force use of cookies by
adding the folowing to php.ini.
session.use_only_cookies = On

Jul 17 '05 #37

P: n/a
Kevin Thorpe wrote:
Our installation does this as well. You can force use of cookies by
adding the folowing to php.ini. session.use_only_cookies = On


Can I force this in PHP, I don't have any say over the php.ini ....

--
Spam:newsgroup(at)cr*********@verisign-sux-klj.com
EMail:<0110001100101110011000100111010101110010011 010110
11001010100000001100011011100100110000101111010011 011100
11000010111001000101110011000110110111101101101001 00000>
Jul 17 '05 #38

P: n/a
On Tue, 07 Oct 2003 14:29:46 GMT, "127.0.0.1"
<newsgroup(at)cr*********@verisign-sux-ijlkl.com> wrote:
Kevin Thorpe wrote:
Our installation does this as well. You can force use of cookies by
adding the folowing to php.ini. session.use_only_cookies = On


Can I force this in PHP, I don't have any say over the php.ini ....


I must say, compared to some other newsgroups, people here are
extremely patient, well-mannered, helpful... :)

I'm pretty much a beginner with PHP myself, and I'm always thankful
for advise on even simple questions. But just a bit reading the manual
might be a good thing before posting...

How to configure PHP with ini_set() or .htaccess files if you are on
Apache is well documented in the PHP documentation. Look for ini_set
and .htaccess ...
Jul 17 '05 #39

P: n/a
On Mon, 06 Oct 2003 22:09:14 GMT, "127.0.0.1"
<newsgroup(at)cr*********@verisign-sux-ijlkl.com> wrote:
It is far easier to write

session $blah;

than to write

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

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


Couldn't you use

$blah =& $_SESSION["blah"];

or import_request_variables?

still, i like register_globals, because it helps me to make much safer
code. when i declare a variable i always either set some default value
to it or check that it has correct value or type and never trust any
input from userside.

- allan savolainen

Jul 17 '05 #40

P: n/a
Bruce Lewis wrote:
Justin Koivisto <sp**@koivi.com> writes:

I too do not approve of such a proposal, especially when you can use
the extract function with the EXTR_REFS flag to do it anyway.


Isn't using the extract function equivalent to register_globals=on?
This proposal is not.


Without the EXTR_REFS it would be.... Try this:

<?php
session_start();
echo '<pre>';
if(!isset($_GET['step'])){
// set up some test SESSION vars
$_SESSION['var1']='Value 1';
$_SESSION['var2']='Value 2';
$_SESSION['var3']='Value 3';

// This link will also set up GET vars
echo '<a href="?step=2&var2=GetValue">Step2</a>';
}else if($_GET['step']==2){
// show what we have registered
echo "_GET\n";
print_r($_GET);
echo "\n_SESSION\n";
print_r($_SESSION);
echo'<hr>';

extract($_SESSION,EXTR_REFS);
echo "_SESSION After Extract\n";
print_r($_SESSION);
echo "var1: $var1\n",
"var2: $var2\n",
"var3: $var3\n";
echo '<hr>';

$var2='New Value 2';
echo "_SESSION After $var2 change\n";
print_r($_SESSION);
echo'<hr>';

extract($_GET,EXTR_REFS);
echo "_GET After Extract\n";
print_r($_GET);
echo "var1: $var1\n",
"var2: $var2\n",
"var3: $var3\n";
echo '<hr>';

$step=3;
echo '<a href="?';
while(list($k,$v)=@each($_GET))
echo "$k=".urlencode($v).'&';
echo '">Next step</a>';

}else if($_GET['step']==3){
echo "_SESSION\n";
print_r($_SESSION);
echo "_GET\n";
print_r($_GET);
echo "\nNotice how _SESSION['var2'] is missing a value?\n",
"That is because the reference to it was overwritten\n",
"when the _GET array was extracted. That reference no\n",
"longer exists in memory (possible security risk?)";
}
echo '</pre>';
?>

What I don't see is where the proposed method is any different - except
that you'd need to define one var at a time rather than a simple
extract. Using the same code as above (without comments and print
statements) with the proposed idea, you'd have the following for step 2:

<?php
session $var1;
session $var2;
session $var3;
$var2='New Value 2';
httpget $var2;
httpget $step;
$step=3;
echo '<a href="?';
while(list($k,$v)=@each($_GET))
echo "$k=".urlencode($v).'&';
echo '">Next step</a>';
?>

It doesn't really seem any easier to read (or efficient) compared to:

<?php
extract($_SESSION,EXTR_REFS);
$var2='New Value 2';
extract($_GET,EXTR_REFS);
$step=3;
echo '<a href="?';
while(list($k,$v)=@each($_GET))
echo "$k=".urlencode($v).'&';
echo '">Next step</a>';
?>

I guess I just don't see the point in adding more stuff the the language
syntax when you can do the same thing here. The arguement of "I'm not
running 4.3.x" isn't valid because you don't/wouldn't have either method.

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

Jul 17 '05 #41

P: n/a
Kevin Thorpe wrote:
127.0.0.1 wrote:
Excellent - that works ... but what is this on the URL
PHPSESSID=d307df95a704af2719819f6d96dac42c

... isn't that meant to go in the cookies, I can't have it in the URL.

I think your installation is set up to try and detect if cookies are
enabled. It puts this on the URL and in a cookie to start with to see
which works. It will disappear in further requests now it's seen thet
cookies work.

Our installation does this as well. You can force use of cookies by
adding the folowing to php.ini.
session.use_only_cookies = On


Actually, I believe it has something to do with the way I wrote the
anchor tag. If you do something like:

echo '<a href="'.$_SERVER['REQUEST_URI'].'?next">next</a>';

The session_id doesn't show in the URL. :P

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

Jul 17 '05 #42

P: n/a
On Tue, 07 Oct 2003 21:51:59 +0300, Allan Savolainen wrote:
still, i like register_globals,
I don't like it, but I consider both (your liking and my not liking)
mere personal preferences.
because it helps me to make much safer code.


However, I don't understand how register_globals could help writing
safer code. Using the proper techniques and writing bug-free code,
code with register_globals could be just as safe as code without it.
But how would it be _safer_?

Jul 17 '05 #43

P: n/a
Gerhard Fiedler wrote:
On Tue, 07 Oct 2003 21:51:59 +0300, Allan Savolainen wrote:
still, i like register_globals,


I don't like it, but I consider both (your liking and my not liking)
mere personal preferences.
because it helps me to make much safer code.


However, I don't understand how register_globals could help writing
safer code. Using the proper techniques and writing bug-free code,
code with register_globals could be just as safe as code without it.


I've been reading up on PHP.INI values, and there is a setting which
can make register_globals VERY safe.

; This directive describes the order in which PHP registers
; GET, POST, Cookie,
; Environment and Built-in variables (G, P, C, E & S respectively, often
; referred to as EGPCS or GPC). Registration is done from
; left to right, newer
; values override older values.
variables_order = "EGPCS"

Seems that this can remove the registration of GET and POST variables
altogether, allowing registration of SESSION variables.
--
Spam:newsgroup(at)cr*********@verisign-sux-klj.com
EMail:<0110001100101110011000100111010101110010011 010110
11001010100000001100011011100100110000101111010011 011100
11000010111001000101110011000110110111101101101001 00000>
Jul 17 '05 #44

P: n/a

"127.0.0.1" <newsgroup(at)cr*********@verisign-sux-ijlkl.com> wrote in
message news:tz********************@news-server.bigpond.net.au...
Gerhard Fiedler wrote:
On Tue, 07 Oct 2003 21:51:59 +0300, Allan Savolainen wrote:
still, i like register_globals,


I don't like it, but I consider both (your liking and my not liking)
mere personal preferences.
because it helps me to make much safer code.


However, I don't understand how register_globals could help writing
safer code. Using the proper techniques and writing bug-free code,
code with register_globals could be just as safe as code without it.


I've been reading up on PHP.INI values, and there is a setting which
can make register_globals VERY safe.

; This directive describes the order in which PHP registers
; GET, POST, Cookie,
; Environment and Built-in variables (G, P, C, E & S respectively, often
; referred to as EGPCS or GPC). Registration is done from
; left to right, newer
; values override older values.
variables_order = "EGPCS"

Seems that this can remove the registration of GET and POST variables
altogether, allowing registration of SESSION variables.


If you write your code based on PHP.INI settings it isn't portable as many
hosts will not allow PHP.INI settings to be changed.

Paulus
Jul 17 '05 #45

P: n/a

"Gerhard Fiedler" <me@privacy.net> wrote in message
news:si********************************@4ax.com...
On Tue, 07 Oct 2003 21:51:59 +0300, Allan Savolainen wrote:
still, i like register_globals,


I don't like it, but I consider both (your liking and my not liking)
mere personal preferences.
because it helps me to make much safer code.


However, I don't understand how register_globals could help writing
safer code. Using the proper techniques and writing bug-free code,
code with register_globals could be just as safe as code without it.
But how would it be _safer_?


*If* people used the right techniques it would be safe but people generally
don't. They don't initialise variables before using them, they concatenate
or add to uninitialised variables assuming they were blank to begin with.
Register globals is a minor part of security but I believe that because you
have to do something to get a posted variable or you have to write
$_GET['id'] it acts as a reminder that this variable is not secure, it may
have been tampered with.

How many people have secured their MySQL queries for injection attacks which
are incredibly easy to perform on MySQL v4.x? Programmers don't do what they
don't have to and I hope that register globals makes people think twice
about the security of their script, rather than doing much about it
directly.

Paulus
Jul 17 '05 #46

P: n/a
Justin Koivisto <sp**@koivi.com> writes:
Bruce Lewis wrote:
Justin Koivisto <sp**@koivi.com> writes:
I too do not approve of such a proposal, especially when you can use
the extract function with the EXTR_REFS flag to do it anyway. Isn't using the extract function equivalent to register_globals=on?
This proposal is not.


Without the EXTR_REFS it would be.... Try this:


I don't need to try this; I'll trust that your comment is true:
echo "\nNotice how _SESSION['var2'] is missing a value?\n",
"That is because the reference to it was overwritten\n",
"when the _GET array was extracted. That reference no\n",
"longer exists in memory (possible security risk?)";


Your comment says the same thing I'm saying: that using extract has the
same possible security risks that register_globals=on has.

The proposal makes it explicit which variables you expect to use from
the _GET array, so an unexpected variable won't get extracted and
overwrite the session variable you intended to use. You get nearly the
convenience of register_globals=on with none of the security risk.

Jul 17 '05 #47

P: n/a
Bruce Lewis wrote:
Justin Koivisto <sp**@koivi.com> writes:
Bruce Lewis wrote:
Justin Koivisto <sp**@koivi.com> writes:

I too do not approve of such a proposal, especially when you can use
the extract function with the EXTR_REFS flag to do it anyway.

Isn't using the extract function equivalent to register_globals=on?
This proposal is not.
Without the EXTR_REFS it would be.... Try this:


I don't need to try this; I'll trust that your comment is true:
echo "\nNotice how _SESSION['var2'] is missing a value?\n",
"That is because the reference to it was overwritten\n",
"when the _GET array was extracted. That reference no\n",
"longer exists in memory (possible security risk?)";

Your comment says the same thing I'm saying: that using extract has the
same possible security risks that register_globals=on has.


Heh, check this out now... The proposal in the form of functions:

<?php
session_start();
echo '<pre>';
if(!isset($_GET['step'])){
// set up some test SESSION vars
$_SESSION['var1']='Value 1';
$_SESSION['var2']='Value 2';
$_SESSION['var3']='Value 3';

// This link will also set up GET vars
echo '<a href="?step=2&var2=GetValue">Step2</a>';
}else if($_GET['step']==2){
// show what we have registered
echo "_GET\n";
print_r($_GET);
echo "\n_SESSION\n";
print_r($_SESSION);
echo'<hr>';

global_session('var1');
global_session('var2');
global_session('var3');

echo "_SESSION After Extract\n";
print_r($_SESSION);
echo "var1: $var1\n",
"var2: $var2\n",
"var3: $var3\n";
echo '<hr>';

$var2='New Value 2';
echo "_SESSION After $var2 change\n";
print_r($_SESSION);
echo'<hr>';

global_get('var2');
global_get('step');

echo "_GET After Extract\n";
print_r($_GET);
echo "var1: $var1\n",
"var2: $var2\n",
"var3: $var3\n";
echo '<hr>';

$step=3;
echo '<a href="?';
while(list($k,$v)=@each($_GET))
echo "$k=".urlencode($v).'&';
echo '">Next step</a>';

}else if($_GET['step']==3){
echo "_SESSION\n";
print_r($_SESSION);
echo "_GET\n";
print_r($_GET);
}
echo '</pre>';

function global_get($var){
if(!array_key_exists($var,$_GET))
$_GET[$var]='';
$GLOBALS[$var]=&$_GET[$var];
}

function global_post($var){
if(!array_key_exists($var,$_POST))
$_POST[$var]='';
$GLOBALS[$var]=&$_POST[$var];
}

function global_session($var){
if(!array_key_exists($var,$_SESSION))
$_SESSION[$var]='';
$GLOBALS[$var]=&$_SESSION[$var];
}

function global_cookie($var){
if(!array_key_exists($var,$_COOKIE))
$_COOKIE[$var]='';
$GLOBALS[$var]=&$_COOKIE[$var];
}

function global_server($var){
if(!array_key_exists($var,$_SERVER))
$_SERVER[$var]='';
$GLOBALS[$var]=&$_SERVER[$var];
}

function global_files($var){
if(!array_key_exists($var,$_FILES))
$_FILES[$var]='';
$GLOBALS[$var]=&$_FILES[$var];
}

function global_env($var){
if(!array_key_exists($var,$_ENV))
$_ENV[$var]='';
$GLOBALS[$var]=&$_ENV[$var];
}

function global_request($var){
if(!array_key_exists($var,$_REQUEST))
$_REQUEST[$var]='';
$GLOBALS[$var]=&$_REQUEST[$var];
}
?>
The proposal makes it explicit which variables you expect to use from
the _GET array, so an unexpected variable won't get extracted and
overwrite the session variable you intended to use. You get nearly the
convenience of register_globals=on with none of the security risk.


I broadened the scope of the proposal in the process. These functions
now support all of the super globals (except$ GLOBALS)in PHP. I also
changed the names to be prefixed by global_ and then the lowercase name
of the superglobal array to play with.

Also, I thought about the case where the key didn't exist in the
superglobal. If this is the case, the key is created and then
referenced. This would likely be handy for _SESSION more than anything.

HTH

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

Jul 17 '05 #48

P: n/a
Hi gerhard!
On Wed, 08 Oct 2003 09:11:23 -0300, Gerhard Fiedler <me@privacy.net>
wrote:
On Tue, 07 Oct 2003 21:51:59 +0300, Allan Savolainen wrote:
still, i like register_globals,


I don't like it, but I consider both (your liking and my not liking)
mere personal preferences.
because it helps me to make much safer code.


However, I don't understand how register_globals could help writing
safer code.


Me neither. But it is a method of producing bug free code, because it
minimizes globals.

HTH, Jochen
--
Jochen Daum - CANS Ltd.
PHP DB Edit Toolkit -- PHP scripts for building
database editing interfaces.
http://sourceforge.net/projects/phpdbedittk/
Jul 17 '05 #49

P: n/a
On Wed, 08 Oct 2003 12:38:49 GMT, "127.0.0.1"
<newsgroup(at)cr*********@verisign-sux-ijlkl.com> wrote:
Gerhard Fiedler wrote:
> because it helps me to make much safer code.


However, I don't understand how register_globals could help writing
safer code. Using the proper techniques and writing bug-free code,
code with register_globals could be just as safe as code without it.


I've been reading up on PHP.INI values, and there is a setting which
can make register_globals VERY safe.
...


This is all good, but how does this make code _safer_ than without
register_globals?

Besides, I personally don't like to mix variables that my program sets
and input. I like to keep them neatly separated, and PHP (without
register_globals) does exactly this.
Jul 17 '05 #50

50 Replies

This discussion thread is closed

Replies have been disabled for this discussion.