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.1wrote:

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*******@attglobal.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**********@aioe.org>, Zorque <zo**@127.0.0.1wrote:

>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_path("/home/myaccountpath/sessions");
session_name('user_settings');
session_start();
if (session_id() == 'deleted') session_regenerate_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**********@aioe.org>, Zorque <zo**@127.0.0.1wrote:

>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_path("/home/myaccountpath/sessions");
session_name('user_settings');
session_start();
if (session_id() == 'deleted') session_regenerate_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*******@attglobal.net
==================

[axlq]

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

>my scripts execute these statements before doing anything else:

session_save_path("/home/myaccountpath/sessions");
session_name('user_settings');
session_start();
if (session_id() == 'deleted') session_regenerate_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_path() 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_path 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*********@kdetalk.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/

[Jerry Stuckle]

axlq wrote:

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

>>my scripts execute these statements before doing anything else:

session_save_path("/home/myaccountpath/sessions");
session_name('user_settings');
session_start();
if (session_id() == 'deleted') session_regenerate_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.

Then your ISP is broken. I have sites on several servers. They all use
session_start() and nothing more.

session_save_path() 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.

That is dependent on your server configuration, which can be changed,
both in your php.ini file and the .htaccess.

And the correct way to do it would be to change the session.cookie_lifetime.

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.

Cookie name is unimportant. But again, this is a server configuration
parameter which can be changed multiple ways.

session_start() is necessary, but can't occur until
session_save_path 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.

When a session is destroyed, it's temp file may not be deleted
immediately. But I have *never* seen it's name changed to 'deleted'.
And I have *never* seen anyone able to access a session after it's been
destroyed.

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

Then you have one screwed up host.
--
==================
Remove the "x" from my email address
Jerry Stuckle
JDS Computer Training Corp.
js*******@attglobal.net
==================

[Jerry Stuckle]

Toby A Inkster wrote:

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.

Sorry, Toby - on every system I've seen you get an error message about
headers already been sent if you try to call session_start() after any
output (and, of course are displaying errors).

And lots of other people have seen that, too. Look at all of the
questions we've gotten in this newsgroup about that problem.

Now if you're buffering all of your output (i.e. ob_start(), etc.) it's
not a problem because the data hasn't been sent.

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

[Jerry Stuckle]

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.

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.

Sure. We were just showing you ways to do it based on your first post: :-)

"... "post" the data to the latter script without using a form?"

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

[Toby A Inkster]

Jerry Stuckle wrote:

Toby A Inkster wrote:

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

Sorry, Toby - on every system I've seen you get an error message about
headers already been sent if you try to call session_start() after any
output (and, of course are displaying errors).

http://examples.tobyinkster.co.uk/session-start

PHP 5; no special configuration needed; no output buffering; all errors
shown (even E_STRICT) -- the source is there, so you can try it on your
own server if you like.

Click repeatedly on "session then echo", "echo then session", "session
then echo" and so forth and you'll see both work fine, neither issuing
errors.

The only time you'll see an error is if you visit "echo then session"
without having already visited "session then echo". That is because you've
hit against both condition 1 and condition 2 in my quote above.

--
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 9 days, 16:27.]

The Great IE8 Meta Tag Debacle
http://tobyinkster.co.uk/blog/2008/02/06/ie-8-meta-tag/

[Jerry Stuckle]

Toby A Inkster wrote:

Jerry Stuckle wrote:

>Toby A Inkster wrote:

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

Sorry, Toby - on every system I've seen you get an error message about
headers already been sent if you try to call session_start() after any
output (and, of course are displaying errors).

http://examples.tobyinkster.co.uk/session-start

PHP 5; no special configuration needed; no output buffering; all errors
shown (even E_STRICT) -- the source is there, so you can try it on your
own server if you like.

Click repeatedly on "session then echo", "echo then session", "session
then echo" and so forth and you'll see both work fine, neither issuing
errors.

The only time you'll see an error is if you visit "echo then session"
without having already visited "session then echo". That is because you've
hit against both condition 1 and condition 2 in my quote above.

Sorry. Echo then session fails on two servers I just tried, even if I
called session then echo first.

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