Ahh, I think I see now... there is no need to use extract on $_POST or $_GET
in the example.
In the postresponse there's two lines:
$name = wsGetRequest( "name" );
$color = wsGetRequest( "color" );
This is making use of the wsGetRequest function in ioelmsrv.php. It seems
redundant, but wsGetRequest will look in either $_GET or $_POST depending on
the IOMethod used (get, post, upload {which is also post}), or fallback onto
the $_SERVER['REQUEST_METHOD'].
Agreed, there's often much more simple and elegant ways of doing things
natively in PHP than in ASP's JScript and VBScript or in Perl. But the
exercise is to create the same library with the same functions available,
and the examples should use those functions. Correct? Unless I am missing
some other fine point...
Leif
----- Original Message -----
From: "Jeremy Wanamaker" <[EMAIL PROTECTED]>
To: <[EMAIL PROTECTED]>
Sent: Wednesday, August 06, 2003 11:16 AM
Subject: Re: [Dynapi-Dev] dynapi.util.ioelement-postresponse.php
> As it stands, the php code in dynapi.util.ioelement-postresponse.php looks
> like this:
>
> <?
> // generate javascript variables
>
> echo "var response = 'Your name is $name, and your favourite color is
> $color';";
>
> ?>
>
> The values of $name and $color are coming from the post data. If register
> globals are turned on, $name and $color will be automatically assigned
from
> the $_POST array. If register globals are off, you have to reference these
> variable from with the $_POST array as follows:
>
> echo "var response = 'Your name is $_POST[name], and your favourite color
is
> $_POST[color]';";
>
> ... or you can put an
>
> extract($_POST);
>
> before the echo line. There is the potential to overwrite other variables
> with extract if you are not careful. One way to make sure values are not
> overwritten is to use the EXTR_SKIP flag when using extract - see
> http://php.net/extract - The first method is better though. My main point
> was that in the current CVS version, the variables are not referenced
> correctly if register globals are off.
>
> Jeremy
>
> ----- Original Message -----
> From: "Leif W" <[EMAIL PROTECTED]>
> To: <[EMAIL PROTECTED]>
> Sent: Wednesday, August 06, 2003 10:19 AM
> Subject: Re: [Dynapi-Dev] dynapi.util.ioelement-postresponse.php
>
>
> > Hi,
> >
> > I am not sure I understand this... All the variables exist in $_GET,
> $_POST,
> > $_COOKIES, $_FILES, so in the script I referenced them as such. I read
my
> > php.ini and the manual. The extract will bring all the assosciative
array
> > elements into the current symbol table. But if you do this, isn't there
a
> > risk of clobbering existing variables in use? If the PHP script exists
on
> a
> > server, and someone can figure out which variable names we're using,
they
> > may be able to override our variables and gain more control of the
script
> > than we want. Shouldn't we just abide by the default of leaving the
data
> in
> > the $_GET, $_POST, $_COOKIES, $_FILES arrays, and not override the
default
> > behaviour of disabling the register_globals, and so not risk
compromising
> > security?
> >
> > Leif
> >
> >
> > ----- Original Message -----
> > From: "Jeremy Wanamaker" <[EMAIL PROTECTED]>
> > To: <[EMAIL PROTECTED]>
> > Sent: Wednesday, August 06, 2003 9:14 AM
> > Subject: [Dynapi-Dev] dynapi.util.ioelement-postresponse.php
> >
> >
> > > The dynapi.util.ioelement-postresponse.php example script will not
work
> > with
> > > PHP versions > 4.2.0 because register globals are turned off by
default.
> > It
> > > would probably be useful to add
> > >
> > > extract($_POST);
> > >
> > > before the echo in that file. I mention this because I spent about an
> hour
> > > tracing through the rest of the code trying to figure out why the
> > variables
> > > weren't getting passed between php and javascript, only to discover
that
> > > they were. The simplest explanation is usually the correct one I
guess.
> > >
> > > Jeremy
> > >
> > >
> > >
> > > -------------------------------------------------------
> > > This SF.Net email sponsored by: Free pre-built ASP.NET sites including
> > > Data Reports, E-commerce, Portals, and Forums are available now.
> > > Download today and enter to win an XBOX or Visual Studio .NET.
> > >
> >
>
http://aspnet.click-url.com/go/psa00100003ave/direct;at.aspnet_072303_01/01
> > > _______________________________________________
> > > Dynapi-Dev mailing list
> > > [EMAIL PROTECTED]
> > > http://www.mail-archive.com/[EMAIL PROTECTED]/
> > >
> > >
> >
> >
> >
> >
> > -------------------------------------------------------
> > This SF.Net email sponsored by: Free pre-built ASP.NET sites including
> > Data Reports, E-commerce, Portals, and Forums are available now.
> > Download today and enter to win an XBOX or Visual Studio .NET.
> >
>
http://aspnet.click-url.com/go/psa00100003ave/direct;at.aspnet_072303_01/01
> > _______________________________________________
> > Dynapi-Dev mailing list
> > [EMAIL PROTECTED]
> > http://www.mail-archive.com/[EMAIL PROTECTED]/
> >
>
>
>
> -------------------------------------------------------
> This SF.Net email sponsored by: Free pre-built ASP.NET sites including
> Data Reports, E-commerce, Portals, and Forums are available now.
> Download today and enter to win an XBOX or Visual Studio .NET.
>
http://aspnet.click-url.com/go/psa00100003ave/direct;at.aspnet_072303_01/01
> _______________________________________________
> Dynapi-Dev mailing list
> [EMAIL PROTECTED]
> http://www.mail-archive.com/[EMAIL PROTECTED]/
>
>
-------------------------------------------------------
This SF.Net email sponsored by: Free pre-built ASP.NET sites including
Data Reports, E-commerce, Portals, and Forums are available now.
Download today and enter to win an XBOX or Visual Studio .NET.
http://aspnet.click-url.com/go/psa00100003ave/direct;at.aspnet_072303_01/01
_______________________________________________
Dynapi-Dev mailing list
[EMAIL PROTECTED]
http://www.mail-archive.com/[EMAIL PROTECTED]/
