Does $_POST survive script hopping?

[Zorque]

Suppose I have an HTML form that sends data to a PHP script, "post"
method.

If this script generates a page with a link to another script, will the
latter script get the former's $_POST data when the user clicks on the
link?

If not, is there a straightforward way (i.e.: no saving to files or
cookies) to "post" the data to the latter script without using a form?

TIA for your comments...

[Rik Wasmus]

On Wed, 06 Feb 2008 00:15:42 +0100, Zorque <zo**@127.0.0.1 wrote:

Suppose I have an HTML form that sends data to a PHP script, "post"
method.

If this script generates a page with a link to another script, will the
latter script get the former's $_POST data when the user clicks on the
link?

No.

If not, is there a straightforward way (i.e.: no saving to files or
cookies) to "post" the data to the latter script without using a form?

No. Either use sessions or curl in some way to achieve this.

--
Rik Wasmus

[Jerry Stuckle]

Zorque wrote:

Suppose I have an HTML form that sends data to a PHP script, "post"
method.

If this script generates a page with a link to another script, will the
latter script get the former's $_POST data when the user clicks on the
link?

No. Each request is new.

If not, is there a straightforward way (i.e.: no saving to files or
cookies) to "post" the data to the latter script without using a form?

TIA for your comments...

cURL can do it, but may not be what you want. Otherwise save in the
session or use a form.

--
=============== ===
Remove the "x" from my email address
Jerry Stuckle
JDS Computer Training Corp.
js*******@attgl obal.net
=============== ===

[=?ISO-8859-15?Q?Iv=E1n_S=E1nchez_Ortega?=]

Zorque wrote:

If this script generates a page with a link to another script, will the
latter script get the former's $_POST data when the user clicks on the
link?

No. If you read about how HTTP works, you'll find that values are only
posted once.

If not, is there a straightforward way (i.e.: no saving to files or
cookies) to "post" the data to the latter script without using a form?

Several methods exist. One is using cookies, another one is saving to a
file...

I think that the answer you want is "sessions". Store things on a session
variable, and the second script will find those sessions variables with
their values. Do read http://php.net/session .

Cheers,
--
----------------------------------
Iván Sánchez Ortega -ivansanchez-algarroba-escomposlinux-punto-org-

Un ordenador no es un televisor ni un microondas, es una herramienta
compleja.

[axlq]

In article <fo**********@a ioe.org>, Zorque <zo**@127.0.0.1 wrote:

>Suppose I have an HTML form that sends data to a PHP script, "post"
method.

If this script generates a page with a link to another script, will the
latter script get the former's $_POST data when the user clicks on the
link?

Not unless you save the post in the local session array:

$_SESSION['post'] = $_POST;

Then in the other script you'd simply retrieve the post data as

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

Be sure you do all the necessary initializations *each* time *any*
script is invoked, or the $_SESSION functionality won't work. All
my scripts execute these statements before doing anything else:

session_save_pa th("/home/myaccountpath/sessions");
session_name('u ser_settings');
session_start() ;
if (session_id() == 'deleted') session_regener ate_id(true);

>If not, is there a straightforward way (i.e.: no saving to files or
cookies) to "post" the data to the latter script without using a form?

Well, if you don't want to save files, then $_SESSION isn't for you,
because that automatically saves a session file.

-A

[Jerry Stuckle]

axlq wrote:

In article <fo**********@a ioe.org>, Zorque <zo**@127.0.0.1 wrote:

>Suppose I have an HTML form that sends data to a PHP script, "post"
method.

If this script generates a page with a link to another script, will the
latter script get the former's $_POST data when the user clicks on the
link?

Not unless you save the post in the local session array:

$_SESSION['post'] = $_POST;

Then in the other script you'd simply retrieve the post data as

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

Be sure you do all the necessary initializations *each* time *any*
script is invoked, or the $_SESSION functionality won't work. All
my scripts execute these statements before doing anything else:

session_save_pa th("/home/myaccountpath/sessions");
session_name('u ser_settings');
session_start() ;
if (session_id() == 'deleted') session_regener ate_id(true);

Wrong. All that you need is session_start() . But it needs to be at the
top of your script, before ANYTHING else (including white space) is output.

>If not, is there a straightforward way (i.e.: no saving to files or
cookies) to "post" the data to the latter script without using a form?

Well, if you don't want to save files, then $_SESSION isn't for you,
because that automatically saves a session file.

-A

--
=============== ===
Remove the "x" from my email address
Jerry Stuckle
JDS Computer Training Corp.
js*******@attgl obal.net
=============== ===

[axlq]

In article <i4************ *************** ***@comcast.com >,
Jerry Stuckle <js*******@attg lobal.netwrote:

>my scripts execute these statements before doing anything else:

session_save_p ath("/home/myaccountpath/sessions");
session_name(' user_settings') ;
session_start( );
if (session_id() == 'deleted') session_regener ate_id(true);

Wrong. All that you need is session_start() .

Wrong.

Perhaps different ISPs behave differently. Those lines above are
there because they are necessary in my case, and in general cases it
does no harm to include them.

session_save_pa th() is necessary because the default session path
results in sessions that last 20 minutes. There are likely other
ways to cause the session to last as long as the user's browser is
open. Setting one's own path is one way to do it.

session_name() isn't really necessary, but does give a meaningful
name to the cookie set in the user's browser, if the user cares to
look. Since *I* am that sort of user who looks at my cookies, I do
things to cater to other users like me.

session_start() is necessary, but can't occur until
session_save_pa th and session_name have been called.

The 'if' statement above is necessary. When a user logs out and
session_destroy () is called, a session file on the server still
exists but is renamed to 'deleted'. The session cookie is renamed
to 'deleted' (at least it is in Opera). When multiple users access
the site with a session cookie named 'deleted', they will end up
sharing session data. I have tested and verified this behavior, as
well as verified it with the PHP support folks.

You may want to argue about it, but I doubt you'd be able to argue
successfully that the above 4 lines aren't necessary for my site.

-A

[Zorque]

Thanks, everybody. I really need to read up on sessions.

But in this case I think I might take another route, following my latest
discovery: HTML forms can have hidden fields with fixed values.

So the first script could dump its $_POST as hidden fields of a form on
the page it generates, and the link to the second script could be a
"submit" button.

[=?ISO-8859-15?Q?Iv=E1n_S=E1nchez_Ortega?=]

Zorque wrote:

Thanks, everybody. I really need to read up on sessions.

But in this case I think I might take another route, following my latest
discovery: HTML forms can have hidden fields with fixed values.

Yes, but keep in mind that hidden values can be tampered with by a savvy
user.

Have a look at the "tamper data" and "web developer toolbar" extensions for
firefox and play with your hidden fields.

Sessions are usually prefered because they can't be tampered with, and
they'll save a tiny little bit of bandwidth, as you won't be piggybacking
the data back and forth.

--
----------------------------------
Iván Sánchez Ortega -ivansanchez-algarroba-escomposlinux-punto-org-

MSN:i_********* *************** *@hotmail.com
Jabber:iv****** ***@jabber.org ; iv*********@kde talk.net

[Toby A Inkster]

Jerry Stuckle wrote:

All that you need is session_start() . But it needs to be at the top of
your script, before ANYTHING else (including white space) is output.

session_start() only needs to be at the top of the script if:

1. You are using cookie-based sessions; *and*
2. You are writing data to a new session.

If you are only reading data from session, or if you are writing data to a
session which you know already exists (e.g. on a page that a user can only
access once they've logged in, where your authentication system uses
sessions) then your call to session_start() does not need to be before
output -- it only has to be before you start using $_SESSION.

--
Toby A Inkster BSc (Hons) ARCS
[Geek of HTML/SQL/Perl/PHP/Python/Apache/Linux]
[OS: Linux 2.6.17.14-mm-desktop-9mdvsmp, up 7 days, 18:34.]

Looking Ahead to Perl 6
http://tobyinkster.co.uk/blog/2008/02/05/perl6/