By using this site, you agree to our updated Privacy Policy and our Terms of Use. Manage your Cookies Settings.
438,303 Members | 1,260 Online
Bytes IT Community
+ Ask a Question
Need help? Post your question and get tips & solutions from a community of 438,303 IT Pros & Developers. It's quick & easy.

sending session cookie before redirect

P: n/a
Hi!

I have a function in a lot of pages, which redirects to a new page, if
a form has been submitted:

if (!(defined("DEBUG_INSERT") && DEBUG_INSERT) &&
!(defined("DEBUG_UPDATE") && DEBUG_UPDATE) &&
!(defined("DEBUG_SELECT") && DEBUG_SELECT)){
if ($_POST){
$_SESSION["postvalue"] = $_POST;
header("HTTP/1.1 302 Moved Temporarily");
header ("Location: ".BASE_URL.$sess->assemble(),true, 302);
header("Connection: close");
exit();
}else{
if (isset($_SESSION["postvalue"])){
$_POST = $_SESSION["postvalue"];
}
}
}

In conjunction with a login form and a browser that accepts cookies
for the session handling, this leads to everyone having to enter his
login and pasword twice.

i believe this is, because the cookie do not get sent before the
header ("Location:
Has anyone an idea how to force this or send them by hand?

Cheers, Jochen
--
Jochen Daum - CANS Ltd.
PHP DB Edit Toolkit -- PHP scripts for building
database editing interfaces.
http://sourceforge.net/projects/phpdbedittk/
Jul 16 '05 #1
Share this Question
Share on Google+
16 Replies


P: n/a
A Martian named "Jochen Daum" <jo*********@cans.co.nz> telepathically
imparted message <pn********************************@4ax.com> to us on
Thu, 04 Sep 2003 23:57:35 -0500:
Hi!

I have a function in a lot of pages, which redirects to a new page, if a
form has been submitted:

if (!(defined("DEBUG_INSERT") && DEBUG_INSERT) &&
!(defined("DEBUG_UPDATE") && DEBUG_UPDATE) &&
!(defined("DEBUG_SELECT") && DEBUG_SELECT)){
if ($_POST){
$_SESSION["postvalue"] = $_POST;
header("HTTP/1.1 302 Moved Temporarily");
header ("Location: ".BASE_URL.$sess->assemble(),true, 302);
header("Connection: close");
exit();
}else{
if (isset($_SESSION["postvalue"])){
$_POST = $_SESSION["postvalue"];
}
}
}
}
In conjunction with a login form and a browser that accepts cookies for
the session handling, this leads to everyone having to enter his login
and pasword twice.

i believe this is, because the cookie do not get sent before the header
("Location:
Has anyone an idea how to force this or send them by hand?

Cheers, Jochen


Keep it simple:

session_start();
if (!isset($_SESSION['postvalue'])):
header ("HTTP/1.1 302 Moved Temporarily to Singapore");
header ("Location: http://myhost.com/login.php");
exit();
endif;
$_POST = $_SESSION['postvalue'];
// show the page
BTW, is there any reason that you just *have* to
use $_POST for all the pages? $_POST is only needed to
retrieve the variables from the (login?) form. After that,
you are free to do everything in $_SESSION['postvalue'].

The "to Singapore" part is just a jest. Don't include it :D
Jul 16 '05 #2

P: n/a
HI Gary!

On Sun, 07 Sep 2003 09:31:51 GMT, Gary Petersen
<ga*******@REMOVE.MEearthlink.INVALID> wrote:
A Martian named "Jochen Daum" <jo*********@cans.co.nz> telepathically
imparted message <pn********************************@4ax.com> to us on
Thu, 04 Sep 2003 23:57:35 -0500:
Hi!

I have a function in a lot of pages, which redirects to a new page, if a
form has been submitted:

if (!(defined("DEBUG_INSERT") && DEBUG_INSERT) &&
!(defined("DEBUG_UPDATE") && DEBUG_UPDATE) &&
!(defined("DEBUG_SELECT") && DEBUG_SELECT)){
if ($_POST){
$_SESSION["postvalue"] = $_POST;
header("HTTP/1.1 302 Moved Temporarily");
header ("Location: ".BASE_URL.$sess->assemble(),true, 302);
header("Connection: close");
exit();
}else{
if (isset($_SESSION["postvalue"])){
$_POST = $_SESSION["postvalue"];
}
}
}
}
In conjunction with a login form and a browser that accepts cookies for
the session handling, this leads to everyone having to enter his login
and pasword twice.

i believe this is, because the cookie do not get sent before the header
("Location:
Has anyone an idea how to force this or send them by hand?

Cheers, Jochen
Keep it simple:

session_start();
if (!isset($_SESSION['postvalue'])):
header ("HTTP/1.1 302 Moved Temporarily to Singapore");
header ("Location: http://myhost.com/login.php");
exit();
endif;
$_POST = $_SESSION['postvalue'];
// show the page


How does the value of all form fields get into $_SESSION?
BTW, is there any reason that you just *have* to
use $_POST for all the pages? $_POST is only needed to
retrieve the variables from the (login?) form.


No. I have eg. a form on nearly every page to change filters of the
data displayed etc.

Jochen
--
PHP DB Edit Toolkit -- PHP scripts for building
database editing interfaces.
http://sourceforge.net/projects/phpdbedittk/
Jul 16 '05 #3

P: n/a
On Sun, 07 Sep 2003 21:56:31 +1200, Jochen Daum wrote:
How does the value of all form fields get into $_SESSION?


you have to put it there, by simple assignment:

$_SESSION['parameter'] = $_POST['parameter'];

or something to that effect.
Jul 16 '05 #4

P: n/a
Hi Gerhard!

On Sun, 07 Sep 2003 12:16:26 -0700, Gerhard Fiedler
<no****@globo.com.REMOVE> wrote:
On Sun, 07 Sep 2003 21:56:31 +1200, Jochen Daum wrote:
How does the value of all form fields get into $_SESSION?


you have to put it there, by simple assignment:

$_SESSION['parameter'] = $_POST['parameter'];

Well, I understand that. That's why I had it there in the original
post.

Any suggestions for my orginal problem?

Jochen
--
PHP DB Edit Toolkit -- PHP scripts for building
database editing interfaces.
http://sourceforge.net/projects/phpdbedittk/
Jul 16 '05 #5

P: n/a
A horsie named Jochen Daum demonstrated surprising intellligence and
its ability to use morse code on Sun, 07 Sep 2003 04:56:31 -0500 when
it tapped <9u********************************@4ax.com> with its hoof:
HI Gary!

Hi Jochen!
On Sun, 07 Sep 2003 09:31:51 GMT, Gary Petersen
<ga*******@REMOVE.MEearthlink.INVALID> wrote:
[...]
Keep it simple:

session_start();
if (!isset($_SESSION['postvalue'])):
header ("HTTP/1.1 302 Moved Temporarily to Singapore");
header ("Location: http://myhost.com/login.php");
exit();
endif;
$_POST = $_SESSION['postvalue'];
// show the page


How does the value of all form fields get into $_SESSION?


The login.php page should present a username/password form
to the user. When the user submits the form, the form's data
would go to a process_login.php page. If the username and
password are correct, process_login.php would put all of
the necessary data into $_SESSION['postvalue']. The password
does not need to be stored in the session.

BTW, is there any reason that you just *have* to
use $_POST for all the pages? $_POST is only needed to
retrieve the variables from the (login?) form.


No. I have eg. a form on nearly every page to change filters of the
data displayed etc.


To make my life easier, I would do this:
if (isset($_POST['somevariable'])) {
$_SESSION['displayform'] = $_POST;
$disp = & $_SESSION['displayform'];
}

Then I would use $disp for everything on the page.
"Somevariable" is just any variable that you can use
to make sure that the form variables are there.
Good luck.

PS.
Unless you are running on a dedicated server, sessions
are not all that secure.
Jul 16 '05 #6

P: n/a
On Mon, 08 Sep 2003 07:41:24 +1200, Jochen Daum wrote:
Well, I understand that. That's why I had it there in the original
post.
I only looked at the post I answered to... :-/
Any suggestions for my orginal problem?


It seems Gary answered. But for more, I guess some more code would be
necessary. At first sight (without actually testing it) there seems
nothing wrong with your code.

You say that you do something with cookies -- but there's no cookie
code in what you posted. You can look at the cookie (at the client),
and you can also look at the headers that get exchanged (use something
like Proxomitron) to make sure they do what you want them to do.

You can also dump your postvalue and _POST arrays at various points to
make sure they contain what you expect them to contain. That should
get you closer to the point where things start to diverge from what
you think they should do.

Jul 16 '05 #7

P: n/a
Hi Gary!

....
[...]
Keep it simple:

session_start();
if (!isset($_SESSION['postvalue'])):
header ("HTTP/1.1 302 Moved Temporarily to Singapore");
header ("Location: http://myhost.com/login.php");
exit();
endif;
$_POST = $_SESSION['postvalue'];
// show the page

How does the value of all form fields get into $_SESSION?


The login.php page should present a username/password form
to the user. When the user submits the form, the form's data
would go to a process_login.php page. If the username and
password are correct, process_login.php would put all of
the necessary data into $_SESSION['postvalue']. The password
does not need to be stored in the session.

Sorry, you misunderstand the problem slighly. The data stored in
postvalue is not the data from the login form, but from another form.
It should actually be all form data, that is sent by post in a whole
application (meaning a set of web pages). The problem is, that if I
run the function above (my original one) everytime there is a post
form (including the login), then the user gets prompted twice for the
password/username. This is IMO, because the cookie with the PHPSESSID
is not sent to the client browser, before the header ("Location" line.
I think it is like that, because
1.) it works fine, if I exclude the login form from the ones handled
by this function
2.) it works with browser denying all cookies.

BTW, is there any reason that you just *have* to
use $_POST for all the pages? $_POST is only needed to
retrieve the variables from the (login?) form.


No. I have eg. a form on nearly every page to change filters of the
data displayed etc.


To make my life easier, I would do this:
if (isset($_POST['somevariable'])) {
$_SESSION['displayform'] = $_POST;
$disp = & $_SESSION['displayform'];
}

Then I would use $disp for everything on the page.
"Somevariable" is just any variable that you can use
to make sure that the form variables are there.


I though of marking the login form with a hidden field, so that I can
recognise it, but I actually want the functionality also for the login
form. Its basically about usability against speed. The users don't
understand, what they have to do, if the browser asks them if they
want to resubmit the data. Thats why I redirect them to a GET request
everytime, so that the message doesn't come up.
PS.
Unless you are running on a dedicated server, sessions
are not all that secure.


I do.

Jochen

--
Jochen Daum - CANS Ltd.
PHP DB Edit Toolkit -- PHP scripts for building
database editing interfaces.
http://sourceforge.net/projects/phpdbedittk/
Jul 16 '05 #8

P: n/a
Hi Gerhard,
Any suggestions for my orginal problem?
It seems Gary answered. But for more, I guess some more code would be
necessary. At first sight (without actually testing it) there seems
nothing wrong with your code.

You say that you do something with cookies -- but there's no cookie
code in what you posted. You can look at the cookie (at the client),
and you can also look at the headers that get exchanged (use something
like Proxomitron) to make sure they do what you want them to do.


When you use PHP sessions, a unique ID is transported to the browser
by a cookie, if the browser accepts it. AFAIK on the first request
there is always a cookie sent, and if it wasn't there and a session
has been started with the SID parameter in the URL none gets sent.

This is the cookie I'm talking about. My original problem is, that if
I run the original function on all pages, the user gets prompted twice
for username/password. This is IMO, because this cookie (for
successful login) is not sent through before the header command.
You can also dump your postvalue and _POST arrays at various points to
make sure they contain what you expect them to contain. That should
get you closer to the point where things start to diverge from what
you think they should do.


They seem to look fine. I'll have a closer look soon.

Jochen
--
Jochen Daum - CANS Ltd.
PHP DB Edit Toolkit -- PHP scripts for building
database editing interfaces.
http://sourceforge.net/projects/phpdbedittk/
Jul 16 '05 #9

P: n/a
A horsie named Jochen Daum demonstrated surprising intellligence and its
ability to use morse code on Sun, 07 Sep 2003 23:35:14 -0500 when it
tapped <o1********************************@4ax.com> with its hoof:
Hi Gary!
Hi Jochen!
[...] everytime there is a post form
(including the login), then the user gets prompted twice for the
password/username. This is IMO, because the cookie with the PHPSESSID is
not sent to the client browser, before the header ("Location" line. I
think it is like that, because
1.) it works fine, if I exclude the login form from the ones handled by
this function
2.) it works with browser denying all cookies.
[...]


Maybe you are not starting the session early enough on one
of your pages.

The session has to exist *before* the login process starts,
so if you have a login.php page that presents a login form to
the user, make sure that it starts the
session with session_start() -- right at the top of the page--
before the user gets to do anything (even log in). And then each
page in the system does the same, starting the session as
the first thing.

Separate the concept of a session from the concept of an
authenticated user. It's possible to have a session where
the user is un-authenticated, and it's possible to have a
session where the user is authenticated.

Jul 16 '05 #10

P: n/a
Hi Gary!
On Mon, 08 Sep 2003 07:30:59 GMT, Gary Petersen
[...] everytime there is a post form
(including the login), then the user gets prompted twice for the
password/username. This is IMO, because the cookie with the PHPSESSID is
not sent to the client browser, before the header ("Location" line. I
think it is like that, because
1.) it works fine, if I exclude the login form from the ones handled by
this function
2.) it works with browser denying all cookies.
[...]
Maybe you are not starting the session early enough on one
of your pages.

The session has to exist *before* the login process starts,
so if you have a login.php page that presents a login form to
the user, make sure that it starts the
session with session_start() -- right at the top of the page--
before the user gets to do anything (even log in). And then each
page in the system does the same, starting the session as
the first thing.


I just checked that. It always happens before anything else happens.
This is because my login class checks a parameter from my session
class, so the latter one has to be instantiated. And session_start is
in the constructor of that class.

Separate the concept of a session from the concept of an
authenticated user. It's possible to have a session where
the user is un-authenticated, and it's possible to have a
session where the user is authenticated.


yep.

Jochen

--
Jochen Daum - CANS Ltd.
PHP DB Edit Toolkit -- PHP scripts for building
database editing interfaces.
http://sourceforge.net/projects/phpdbedittk/
Jul 16 '05 #11

P: n/a
On Mon, 08 Sep 2003 16:40:00 +1200, Jochen Daum wrote:
You say that you do something with cookies -- but there's no cookie
code in what you posted. You can look at the cookie (at the client),
and you can also look at the headers that get exchanged (use something
like Proxomitron) to make sure they do what you want them to do.


When you use PHP sessions, a unique ID is transported to the browser
by a cookie, if the browser accepts it. AFAIK on the first request
there is always a cookie sent, and if it wasn't there and a session
has been started with the SID parameter in the URL none gets sent.

This is the cookie I'm talking about. My original problem is, that if
I run the original function on all pages, the user gets prompted twice
for username/password. This is IMO, because this cookie (for
successful login) is not sent through before the header command.


it is easy enough to verify on a client whether it is actually a
problem with the session cookie.

the one thing that crossed my mind is the connection:close header you
send. i'm not 100% clear on what it does, but it seems to me at least
possible that PHP adds the cookie headers after your script
terminates, and that they may get ignored if coming after this header.
Jul 16 '05 #12

P: n/a
Hi Gerhard!

On Mon, 08 Sep 2003 10:08:38 -0700, Gerhard Fiedler <me@privacy.net>
wrote:
On Mon, 08 Sep 2003 16:40:00 +1200, Jochen Daum wrote:
You say that you do something with cookies -- but there's no cookie
code in what you posted. You can look at the cookie (at the client),
and you can also look at the headers that get exchanged (use something
like Proxomitron) to make sure they do what you want them to do.


When you use PHP sessions, a unique ID is transported to the browser
by a cookie, if the browser accepts it. AFAIK on the first request
there is always a cookie sent, and if it wasn't there and a session
has been started with the SID parameter in the URL none gets sent.

This is the cookie I'm talking about. My original problem is, that if
I run the original function on all pages, the user gets prompted twice
for username/password. This is IMO, because this cookie (for
successful login) is not sent through before the header command.


it is easy enough to verify on a client whether it is actually a
problem with the session cookie.

the one thing that crossed my mind is the connection:close header you
send. i'm not 100% clear on what it does, but it seems to me at least
possible that PHP adds the cookie headers after your script
terminates, and that they may get ignored if coming after this header.


I added that after reading a post on www.php.net/header, which seemed
to match a bit, its the same problem without.

Jochen

--
PHP DB Edit Toolkit -- PHP scripts for building
database editing interfaces.
http://sourceforge.net/projects/phpdbedittk/
Jul 16 '05 #13

P: n/a
On Tue, 09 Sep 2003 07:28:03 +1200, Jochen Daum wrote:
the one thing that crossed my mind is the connection:close header you
send. i'm not 100% clear on what it does, but it seems to me at least
possible that PHP adds the cookie headers after your script
terminates, and that they may get ignored if coming after this header.


I added that after reading a post on www.php.net/header, which seemed
to match a bit, its the same problem without.


well, then the only thing that comes to my mind is to look at the
headers that you are sending and receiving, with a proxy tool like
proxomitron or so.
Jul 16 '05 #14

P: n/a
Jochen Daum <jo*********@cans.co.nz> wrote in message news:<pn********************************@4ax.com>. ..
Hi!

I have a function in a lot of pages, which redirects to a new page, if
a form has been submitted:

i believe this is, because the cookie do not get sent before the
header ("Location:
Has anyone an idea how to force this or send them by hand?

Cheers, Jochen


Hi,

"Set-Cookie:" and "Location:" HTTP headers don't mix well with most
web browsers. Instead of using "Location:" header, put a "Refresh:"
HTTP header, <meta http-equiv="refresh" content="0, URL=..."/> or a
JavaScript "document.replace.location(...)" to have the web-browser
accept the cookie. Best is probably a mix of all. I usually favor the
JavaScript approach because it keeps the "History" clean of the
intermediate redirection page.

To be sure of what's going on, enable "prompt for cookies" in your
web-browser settings (make sure you delete any previously "Remember my
decision" type of settings.)

I hope this helps.

-Philippe
[ 11abacus.com ]
Jul 16 '05 #15

P: n/a
A horsie named 11abacus demonstrated surprising intelligence and its
ability to use morse code on Tue, 09 Sep 2003 11:05:14 -0500 when it
tapped <1a**************************@posting.google.com > with its hoof:
"Set-Cookie:" and "Location:" HTTP headers don't mix well with most web
browsers [...]


The following script, which uses both setcookie() and
the location header, works with these web browsers:
Lynx, Firebird, Mozilla, Galeon, Konqueror, wget.

wget doesn't seem to like cookies that have square
brackets [] in them, but it did accept and use
the 'captain' cookie.

<?php
// PHP 4.0.5
error_reporting(E_ALL);

$g = & $HTTP_GET_VARS;
$c = & $HTTP_COOKIE_VARS;
$s = & $HTTP_SERVER_VARS;
$ttl = time() + 86400;

header('Cache-control: no-cache');
header('Pragma: no-cache');

if (!isset($g['show'])):
setcookie('user[cindy]', '8', $ttl, '/');
setcookie('user[mark]', '4', $ttl, '/');
setcookie('user[jarmain]', 41, $ttl, '/');
setcookie('captain', 'mark', $ttl, '/');
header("Location: http://$s[HTTP_HOST]$s[PHP_SELF]?show=1");
exit();
else:
?>
<title> A Cookie Test </title>
<p> This page sets and displays some cookies.
</p>
<?php
echo "<pre>\n";
print_r($c);
echo "</pre>\n";
endif;
?>

I don't have access to MSIE; perhaps someone can test
with that one.

Jul 16 '05 #16

P: n/a
Hi !

On Wed, 10 Sep 2003 05:19:58 GMT, Gary Petersen
<ga*******@remove.meearthlink.invalid> wrote:
A horsie named 11abacus demonstrated surprising intelligence and its
ability to use morse code on Tue, 09 Sep 2003 11:05:14 -0500 when it
tapped <1a**************************@posting.google.com > with its hoof:
"Set-Cookie:" and "Location:" HTTP headers don't mix well with most web
browsers [...]
The following script, which uses both setcookie() and
the location header, works with these web browsers:
Lynx, Firebird, Mozilla, Galeon, Konqueror, wget.

wget doesn't seem to like cookies that have square
brackets [] in them, but it did accept and use
the 'captain' cookie.


So I just have to find out how to set the PHPSESSID cookie, ey?
Shouldn't be to hard.

Thanks for the help.

Jochen

<?php
// PHP 4.0.5
error_reporting(E_ALL);

$g = & $HTTP_GET_VARS;
$c = & $HTTP_COOKIE_VARS;
$s = & $HTTP_SERVER_VARS;
$ttl = time() + 86400;

header('Cache-control: no-cache');
header('Pragma: no-cache');

if (!isset($g['show'])):
setcookie('user[cindy]', '8', $ttl, '/');
setcookie('user[mark]', '4', $ttl, '/');
setcookie('user[jarmain]', 41, $ttl, '/');
setcookie('captain', 'mark', $ttl, '/');
header("Location: http://$s[HTTP_HOST]$s[PHP_SELF]?show=1");
exit();
else:
?>
<title> A Cookie Test </title>
<p> This page sets and displays some cookies.
</p>
<?php
echo "<pre>\n";
print_r($c);
echo "</pre>\n";
endif;
?>

I don't have access to MSIE; perhaps someone can test
with that one.


--
Jochen Daum - CANS Ltd.
PHP DB Edit Toolkit -- PHP scripts for building
database editing interfaces.
http://sourceforge.net/projects/phpdbedittk/
Jul 16 '05 #17

This discussion thread is closed

Replies have been disabled for this discussion.