dynapi-dev

[Dynapi-Dev] dynapi.util.ioelement-postresponse.php

[Jeremy W. <je...@ma...>]

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

Re: [Dynapi-Dev] dynapi.util.ioelement-postresponse.php

[Leif W <war...@us...>]

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" <je...@ma...>
To: <dyn...@li...>
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
> Dyn...@li...
> http://www.mail-archive.com/dyn...@li.../
>
>

[Dynapi-Dev] IE4 SP1a

[Daniel T. <de...@ti...>]

Hello!

Is there anyone out there that have ie4 sp1a installed on some old
computer that can try out http://195.178.179.45 and see if they get a
error on line 318 in the menu, i have just ie4 on nt and ie4 sp1a is not
availible anymore it seams.

Regards
Daniel

Re: [Dynapi-Dev] dynapi.util.ioelement-postresponse.php

[Jeremy W. <je...@ma...>]

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" <war...@us...>
To: <dyn...@li...>
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" <je...@ma...>
> To: <dyn...@li...>
> 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
> > Dyn...@li...
> > http://www.mail-archive.com/dyn...@li.../
> >
> >
>
>
>
>
> -------------------------------------------------------
> 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
> Dyn...@li...
> http://www.mail-archive.com/dyn...@li.../
>

Re: [Dynapi-Dev] dynapi.util.ioelement-postresponse.php

[Leif W <war...@us...>]

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" <je...@ma...>
To: <dyn...@li...>
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" <war...@us...>
> To: <dyn...@li...>
> 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" <je...@ma...>
> > To: <dyn...@li...>
> > 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
> > > Dyn...@li...
> > > http://www.mail-archive.com/dyn...@li.../
> > >
> > >
> >
> >
> >
> >
> > -------------------------------------------------------
> > 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
> > Dyn...@li...
> > http://www.mail-archive.com/dyn...@li.../
> >
>
>
>
> -------------------------------------------------------
> 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
> Dyn...@li...
> http://www.mail-archive.com/dyn...@li.../
>
>

Re: [Dynapi-Dev] dynapi.util.ioelement-postresponse.php

[Jeremy W. <je...@ma...>]

Leif,

I see now why we haven't been on the same page. The August 6th DynAPI
snapshot contains different versions of the postresponse and ioelmsrv php
files than the August 5th snapshot. So I was pointing out a bug that had
already been fixed. I do agree with you that standardizing the functions
between scripting languages is important to the goal of DynAPI. Keep up the
good work.

Jeremy


----- Original Message ----- 
From: "Leif W" <war...@us...>
To: <dyn...@li...>
Sent: Wednesday, August 06, 2003 12:21 PM
Subject: Re: [Dynapi-Dev] dynapi.util.ioelement-postresponse.php


> 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" <je...@ma...>
> To: <dyn...@li...>
> 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" <war...@us...>
> > To: <dyn...@li...>
> > 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" <je...@ma...>
> > > To: <dyn...@li...>
> > > 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
> > > > Dyn...@li...
> > > > http://www.mail-archive.com/dyn...@li.../
> > > >
> > > >
> > >
> > >
> > >
> > >
> > > -------------------------------------------------------
> > > 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
> > > Dyn...@li...
> > > http://www.mail-archive.com/dyn...@li.../
> > >
> >
> >
> >
> > -------------------------------------------------------
> > 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
> > Dyn...@li...
> > http://www.mail-archive.com/dyn...@li.../
> >
> >
>
>
>
>
> -------------------------------------------------------
> 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
> Dyn...@li...
> http://www.mail-archive.com/dyn...@li.../
>

Re: [Dynapi-Dev] dynapi.util.ioelement-postresponse.php

[Leif W <war...@us...>]

Ahh yeah that makes sense.  Some of the initial PHP code was broken so I
fixed it.  I added the new code to CVS last night.  Sorry for not making it
clear.

Leif

----- Original Message ----- 
From: "Jeremy Wanamaker" <je...@ma...>
To: <dyn...@li...>
Sent: Wednesday, August 06, 2003 2:45 PM
Subject: Re: [Dynapi-Dev] dynapi.util.ioelement-postresponse.php


> Leif,
>
> I see now why we haven't been on the same page. The August 6th DynAPI
> snapshot contains different versions of the postresponse and ioelmsrv php
> files than the August 5th snapshot. So I was pointing out a bug that had
> already been fixed. I do agree with you that standardizing the functions
> between scripting languages is important to the goal of DynAPI. Keep up
the
> good work.
>
> Jeremy
>
>
> ----- Original Message ----- 
> From: "Leif W" <war...@us...>
> To: <dyn...@li...>
> Sent: Wednesday, August 06, 2003 12:21 PM
> Subject: Re: [Dynapi-Dev] dynapi.util.ioelement-postresponse.php
>
>
> > 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" <je...@ma...>
> > To: <dyn...@li...>
> > 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" <war...@us...>
> > > To: <dyn...@li...>
> > > 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" <je...@ma...>
> > > > To: <dyn...@li...>
> > > > 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
> > > > > Dyn...@li...
> > > > > http://www.mail-archive.com/dyn...@li.../
> > > > >
> > > > >
> > > >
> > > >
> > > >
> > > >
> > > > -------------------------------------------------------
> > > > 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
> > > > Dyn...@li...
> > > > http://www.mail-archive.com/dyn...@li.../
> > > >
> > >
> > >
> > >
> > > -------------------------------------------------------
> > > 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
> > > Dyn...@li...
> > > http://www.mail-archive.com/dyn...@li.../
> > >
> > >
> >
> >
> >
> >
> > -------------------------------------------------------
> > 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
> > Dyn...@li...
> > http://www.mail-archive.com/dyn...@li.../
> >
>
>
>
> -------------------------------------------------------
> 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
> Dyn...@li...
> http://www.mail-archive.com/dyn...@li.../
>

Re: [Dynapi-Dev] dynapi.util.ioelement-postresponse.php

[Raymond I. <xw...@ya...>]

Good going Leif! 

I've uploaded the vbscript and jscript versions of the
ioelement server-side libraries to support the new
wsAddJSCommand() function

wsAddJSCommand() -  This will allow JavaScript
commands to be executed on client and should only be
used when html content is being returned to the client

Please new dynapi.util.ioelement-dynamic-code.html
example for more info on the execInParent()
client-side function.

--
Raymond Irving


--- Leif W <war...@us...> wrote:
> Ahh yeah that makes sense.  Some of the initial PHP
> code was broken so I
> fixed it.  I added the new code to CVS last night. 
> Sorry for not making it
> clear.
> 
> Leif
> 
> ----- Original Message ----- 
> From: "Jeremy Wanamaker" <je...@ma...>
> To: <dyn...@li...>
> Sent: Wednesday, August 06, 2003 2:45 PM
> Subject: Re: [Dynapi-Dev]
> dynapi.util.ioelement-postresponse.php
> 
> 
> > Leif,
> >
> > I see now why we haven't been on the same page.
> The August 6th DynAPI
> > snapshot contains different versions of the
> postresponse and ioelmsrv php
> > files than the August 5th snapshot. So I was
> pointing out a bug that had
> > already been fixed. I do agree with you that
> standardizing the functions
> > between scripting languages is important to the
> goal of DynAPI. Keep up
> the
> > good work.
> >
> > Jeremy
> >
> >
> > ----- Original Message ----- 
> > From: "Leif W" <war...@us...>
> > To: <dyn...@li...>
> > Sent: Wednesday, August 06, 2003 12:21 PM
> > Subject: Re: [Dynapi-Dev]
> dynapi.util.ioelement-postresponse.php
> >
> >
> > > 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"
> <je...@ma...>
> > > To: <dyn...@li...>
> > > 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" <war...@us...>
> > > > To: <dyn...@li...>
> > > > 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"
> <je...@ma...>
> > > > > To: <dyn...@li...>
> > > > > 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
> 
=== message truncated ===


__________________________________
Do you Yahoo!?
Yahoo! SiteBuilder - Free, easy-to-use web site design software
http://sitebuilder.yahoo.com

RE: [Dynapi-Dev] dynapi.util.ioelement-postresponse.php

[Daniel T. <de...@ti...>]

Hi all!

What i wonder is if someone have tried to load in images with the
ioelement... Just show a layer with a image in?

Cause sometimes when that is done the image wont show, i think this is
caused byt that the webbrowser somehow loads the html first and never
displays the image... I have no good example for this... But can make
one on request if you dont understand how it works.

Would the solution under here work you think? As its only happening if
you make the layer and the image in the ioelement, and not on the
mainpage.

Regards
Daniel

-----Original Message-----
From: dyn...@li...
[mailto:dyn...@li...] On Behalf Of Raymond
Irving
Sent: den 7 augusti 2003 17:35
To: dyn...@li...
Subject: Re: [Dynapi-Dev] dynapi.util.ioelement-postresponse.php



Good going Leif! 

I've uploaded the vbscript and jscript versions of the ioelement
server-side libraries to support the new
wsAddJSCommand() function

wsAddJSCommand() -  This will allow JavaScript
commands to be executed on client and should only be
used when html content is being returned to the client

Please new dynapi.util.ioelement-dynamic-code.html
example for more info on the execInParent()
client-side function.

--
Raymond Irving


--- Leif W <war...@us...> wrote:
> Ahh yeah that makes sense.  Some of the initial PHP
> code was broken so I
> fixed it.  I added the new code to CVS last night.
> Sorry for not making it
> clear.
> 
> Leif
> 
> ----- Original Message -----
> From: "Jeremy Wanamaker" <je...@ma...>
> To: <dyn...@li...>
> Sent: Wednesday, August 06, 2003 2:45 PM
> Subject: Re: [Dynapi-Dev]
> dynapi.util.ioelement-postresponse.php
> 
> 
> > Leif,
> >
> > I see now why we haven't been on the same page.
> The August 6th DynAPI
> > snapshot contains different versions of the
> postresponse and ioelmsrv php
> > files than the August 5th snapshot. So I was
> pointing out a bug that had
> > already been fixed. I do agree with you that
> standardizing the functions
> > between scripting languages is important to the
> goal of DynAPI. Keep up
> the
> > good work.
> >
> > Jeremy
> >
> >
> > ----- Original Message -----
> > From: "Leif W" <war...@us...>
> > To: <dyn...@li...>
> > Sent: Wednesday, August 06, 2003 12:21 PM
> > Subject: Re: [Dynapi-Dev]
> dynapi.util.ioelement-postresponse.php
> >
> >
> > > 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"
> <je...@ma...>
> > > To: <dyn...@li...>
> > > 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" <war...@us...>
> > > > To: <dyn...@li...>
> > > > 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"
> <je...@ma...>
> > > > > To: <dyn...@li...>
> > > > > 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
> 
=== message truncated ===


__________________________________
Do you Yahoo!?
Yahoo! SiteBuilder - Free, easy-to-use web site design software
http://sitebuilder.yahoo.com


-------------------------------------------------------
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
Dyn...@li...
http://www.mail-archive.com/dyn...@li.../

RE: [Dynapi-Dev] dynapi.util.ioelement-postresponse.php

[Raymond I. <xw...@ya...>]

You'll have to give it a try.

That's very strange though.

--
Raymond Irving

--- Daniel Tiru <de...@ti...> wrote:
> Hi all!
> 
> What i wonder is if someone have tried to load in
> images with the
> ioelement... Just show a layer with a image in?
> 
> Cause sometimes when that is done the image wont
> show, i think this is
> caused byt that the webbrowser somehow loads the
> html first and never
> displays the image... I have no good example for
> this... But can make
> one on request if you dont understand how it works.
> 
> Would the solution under here work you think? As its
> only happening if
> you make the layer and the image in the ioelement,
> and not on the
> mainpage.
> 
> Regards
> Daniel
> 
> -----Original Message-----
> From: dyn...@li...
> [mailto:dyn...@li...] On
> Behalf Of Raymond
> Irving
> Sent: den 7 augusti 2003 17:35
> To: dyn...@li...
> Subject: Re: [Dynapi-Dev]
> dynapi.util.ioelement-postresponse.php
> 
> 
> 
> Good going Leif! 
> 
> I've uploaded the vbscript and jscript versions of
> the ioelement
> server-side libraries to support the new
> wsAddJSCommand() function
> 
> wsAddJSCommand() -  This will allow JavaScript
> commands to be executed on client and should only be
> used when html content is being returned to the
> client
> 
> Please new dynapi.util.ioelement-dynamic-code.html
> example for more info on the execInParent()
> client-side function.
> 
> --
> Raymond Irving
> 
> 
> --- Leif W <war...@us...> wrote:
> > Ahh yeah that makes sense.  Some of the initial
> PHP
> > code was broken so I
> > fixed it.  I added the new code to CVS last night.
> > Sorry for not making it
> > clear.
> > 
> > Leif
> > 
> > ----- Original Message -----
> > From: "Jeremy Wanamaker" <je...@ma...>
> > To: <dyn...@li...>
> > Sent: Wednesday, August 06, 2003 2:45 PM
> > Subject: Re: [Dynapi-Dev]
> > dynapi.util.ioelement-postresponse.php
> > 
> > 
> > > Leif,
> > >
> > > I see now why we haven't been on the same page.
> > The August 6th DynAPI
> > > snapshot contains different versions of the
> > postresponse and ioelmsrv php
> > > files than the August 5th snapshot. So I was
> > pointing out a bug that had
> > > already been fixed. I do agree with you that
> > standardizing the functions
> > > between scripting languages is important to the
> > goal of DynAPI. Keep up
> > the
> > > good work.
> > >
> > > Jeremy
> > >
> > >
> > > ----- Original Message -----
> > > From: "Leif W" <war...@us...>
> > > To: <dyn...@li...>
> > > Sent: Wednesday, August 06, 2003 12:21 PM
> > > Subject: Re: [Dynapi-Dev]
> > dynapi.util.ioelement-postresponse.php
> > >
> > >
> > > > 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"
> > <je...@ma...>
> > > > To: <dyn...@li...>
> > > > 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.
> 
=== message truncated ===


__________________________________
Do you Yahoo!?
Yahoo! SiteBuilder - Free, easy-to-use web site design software
http://sitebuilder.yahoo.com