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

[Jerry Stuckle]

axlq wrote:

In article <i4************ *************** ***@comcast.com >,
Jerry Stuckle <js*******@attg lobal.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_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.

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

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.

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

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*******@attgl obal.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*******@attgl obal.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*******@attgl obal.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*******@attgl obal.net
=============== ===