469,927 Members | 1,884 Online
Bytes | Developer Community
New Post

Home Posts Topics Members FAQ

Post your question to a community of 469,927 developers. It's quick & easy.

Hiding variables passed via URL

Hi,

I have a PHP script that does some processing, and stores an error
message as a variable. The script then redirects to another script
with the error string in the URL, with the second script displaying
the message and continues with the rest of the logic.

Now I want to hide the error message from the URL, but the second
script needs to continue working as is. How can I do this? I have
thought about md5'ing the message but the URLs still look messy. Any
other alternatives?

The script works like this;
$err = "";
$res = process();
if ($res == 0)
{
$err = "An error message";
}
header("Location: script2.php?err=".urlencode($err));

Script2.php would display this message and continue with the rest of
the logic. Now I want to hide the Error message $err from the URL
after a redirect. How do I do this?

Thanks in advance.
Jul 12 '08 #1
103 3670
ch******@gmail.com schrieb:
Hi,

I have a PHP script that does some processing, and stores an error
message as a variable. The script then redirects to another script
with the error string in the URL, with the second script displaying
the message and continues with the rest of the logic.

Now I want to hide the error message from the URL, but the second
script needs to continue working as is. How can I do this? I have
thought about md5'ing the message but the URLs still look messy. Any
other alternatives?

The script works like this;
$err = "";
$res = process();
if ($res == 0)
{
$err = "An error message";
}
header("Location: script2.php?err=".urlencode($err));

Script2.php would display this message and continue with the rest of
the logic. Now I want to hide the Error message $err from the URL
after a redirect. How do I do this?

Thanks in advance.
SESSION varaibles exist.

Jul 12 '08 #2
ch******@gmail.com wrote:
Hi,

I have a PHP script that does some processing, and stores an error
message as a variable. The script then redirects to another script
with the error string in the URL, with the second script displaying
the message and continues with the rest of the logic.

Now I want to hide the error message from the URL, but the second
script needs to continue working as is. How can I do this? I have
thought about md5'ing the message but the URLs still look messy. Any
other alternatives?

The script works like this;
$err = "";
$res = process();
if ($res == 0)
{
$err = "An error message";
}
header("Location: script2.php?err=".urlencode($err));

Script2.php would display this message and continue with the rest of
the logic. Now I want to hide the Error message $err from the URL
after a redirect. How do I do this?

Thanks in advance.
Use POST method.

Declare a form, and set a hidden variable err
Jul 12 '08 #3
..oO(The Natural Philosopher)
>ch******@gmail.com wrote:
>Hi,

I have a PHP script that does some processing, and stores an error
message as a variable. The script then redirects to another script
with the error string in the URL, with the second script displaying
the message and continues with the rest of the logic.

Now I want to hide the error message from the URL, but the second
script needs to continue working as is. How can I do this? I have
thought about md5'ing the message but the URLs still look messy. Any
other alternatives?

The script works like this;
$err = "";
$res = process();
if ($res == 0)
{
$err = "An error message";
}
header("Location: script2.php?err=".urlencode($err));

Script2.php would display this message and continue with the rest of
the logic. Now I want to hide the Error message $err from the URL
after a redirect. How do I do this?

Thanks in advance.

Use POST method.

Declare a form, and set a hidden variable err
You can't redirect a POST request. Sessions are the way to go here if
the error code shouldn't appear in the URL.

Micha
Jul 12 '08 #4
Michael Fesser wrote:
.oO(The Natural Philosopher)
>ch******@gmail.com wrote:
>>Hi,

I have a PHP script that does some processing, and stores an error
message as a variable. The script then redirects to another script
with the error string in the URL, with the second script displaying
the message and continues with the rest of the logic.

Now I want to hide the error message from the URL, but the second
script needs to continue working as is. How can I do this? I have
thought about md5'ing the message but the URLs still look messy. Any
other alternatives?

The script works like this;
$err = "";
$res = process();
if ($res == 0)
{
$err = "An error message";
}
header("Location: script2.php?err=".urlencode($err));

Script2.php would display this message and continue with the rest of
the logic. Now I want to hide the Error message $err from the URL
after a redirect. How do I do this?

Thanks in advance.
Use POST method.

Declare a form, and set a hidden variable err

You can't redirect a POST request.
Are you sure?
>Sessions are the way to go here if
the error code shouldn't appear in the URL.

Micha
Jul 12 '08 #5
..oO(The Natural Philosopher)
>Michael Fesser wrote:
>>
You can't redirect a POST request.

Are you sure?
Sending POST data to another location must be triggered or at least
confirmed by the user. Automatically redirecting anything other than
GET or HEAD is explicitly forbidden by the HTTP spec ("MUST NOT").

Micha
Jul 12 '08 #6
Michael Fesser wrote:
.oO(The Natural Philosopher)
>Michael Fesser wrote:
>>You can't redirect a POST request.
Are you sure?

Sending POST data to another location must be triggered or at least
confirmed by the user. Automatically redirecting anything other than
GET or HEAD is explicitly forbidden by the HTTP spec ("MUST NOT").
Ah, it may be forbidden, but does it work? ;-)

Micha
Jul 13 '08 #7
On Jul 13, 7:13 am, The Natural Philosopher <a...@b.cwrote:
Michael Fesser wrote:
.oO(The Natural Philosopher)
Michael Fesser wrote:
You can't redirect a POST request.
Are you sure?
Sending POST data to another location must be triggered or at least
confirmed by the user. Automatically redirecting anything other than
GET or HEAD is explicitly forbidden by the HTTP spec ("MUST NOT").

Ah, it may be forbidden, but does it work? ;-)
Micha
NO
Jul 13 '08 #8
C. (http://symcbean.blogspot.com/) wrote:
On Jul 13, 7:13 am, The Natural Philosopher <a...@b.cwrote:
>Michael Fesser wrote:
>>.oO(The Natural Philosopher)
Michael Fesser wrote:
You can't redirect a POST request.
Are you sure?
Sending POST data to another location must be triggered or at least
confirmed by the user. Automatically redirecting anything other than
GET or HEAD is explicitly forbidden by the HTTP spec ("MUST NOT").
Ah, it may be forbidden, but does it work? ;-)
>>Micha

NO

Besides all that, a "hidden" variable is not really "hidden". A "view
source" will expose that variable. Session variables are, indeed, the
way to go.

Frankly, though, I don't see the big problem. Since the OP is passing
in the error message, it is obviously to display it to the user.
Otherwise, why do it? If it is also in the URL, so what?
Jul 13 '08 #9
C. (http://symcbean.blogspot.com/) wrote:
On Jul 13, 7:13 am, The Natural Philosopher <a...@b.cwrote:
>Michael Fesser wrote:
>>.oO(The Natural Philosopher)
Michael Fesser wrote:
You can't redirect a POST request.
Are you sure?
Sending POST data to another location must be triggered or at least
confirmed by the user. Automatically redirecting anything other than
GET or HEAD is explicitly forbidden by the HTTP spec ("MUST NOT").
Ah, it may be forbidden, but does it work? ;-)
>>Micha

NO

Lets say we wanted to post something in the background (ie, not
redirect the browser). How do you do that in PHP? In perl, I'd use the
LWP library.

I'm not sure what I'd be looking for, but I don't seem to find it here:

http://www.php.net/manual/en/funcref.php

Jeff
Jul 13 '08 #10
Jeff wrote:
C. (http://symcbean.blogspot.com/) wrote:
>On Jul 13, 7:13 am, The Natural Philosopher <a...@b.cwrote:
>>Michael Fesser wrote:
.oO(The Natural Philosopher)
Michael Fesser wrote:
>You can't redirect a POST request.
Are you sure?
Sending POST data to another location must be triggered or at least
confirmed by the user. Automatically redirecting anything other than
GET or HEAD is explicitly forbidden by the HTTP spec ("MUST NOT").
Ah, it may be forbidden, but does it work? ;-)

Micha

NO


Lets say we wanted to post something in the background (ie, not
redirect the browser). How do you do that in PHP? In perl, I'd use the
LWP library.

I'm not sure what I'd be looking for, but I don't seem to find it here:

http://www.php.net/manual/en/funcref.php

Jeff
What do you mean by "post something in the background"? You either post
or you don't post. There is no foreground or background on the web.

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

Jul 13 '08 #11
Jerry Stuckle wrote:
Jeff wrote:
>C. (http://symcbean.blogspot.com/) wrote:
>>On Jul 13, 7:13 am, The Natural Philosopher <a...@b.cwrote:
Michael Fesser wrote:
.oO(The Natural Philosopher)
>Michael Fesser wrote:
>>You can't redirect a POST request.
>Are you sure?
Sending POST data to another location must be triggered or at least
confirmed by the user. Automatically redirecting anything other than
GET or HEAD is explicitly forbidden by the HTTP spec ("MUST NOT").
Ah, it may be forbidden, but does it work? ;-)

Micha

NO


Lets say we wanted to post something in the background (ie, not
redirect the browser). How do you do that in PHP? In perl, I'd use the
LWP library.

I'm not sure what I'd be looking for, but I don't seem to find it here:

http://www.php.net/manual/en/funcref.php

Jeff

What do you mean by "post something in the background"? You either post
or you don't post. There is no foreground or background on the web.
I found this just after I posted:

http://us.php.net/manual/en/book.http.php

But I'm unsure how that works as it is missing the examples.

Having a server retrieve a page or post data is not an unusual thing
to do, You may refer to it differently and my choice of terms may be
bad. One use would be if you are transparently handling something like a
Credit Card transaction and you don't want to take the customer off the
site. Usually you'd want that done with SSL and not on the query string.

Jeff
>
Jul 13 '08 #12
Jeff wrote:
Jerry Stuckle wrote:
>Jeff wrote:
>>C. (http://symcbean.blogspot.com/) wrote:
On Jul 13, 7:13 am, The Natural Philosopher <a...@b.cwrote:
Michael Fesser wrote:
>.oO(The Natural Philosopher)
>>Michael Fesser wrote:
>>>You can't redirect a POST request.
>>Are you sure?
>Sending POST data to another location must be triggered or at least
>confirmed by the user. Automatically redirecting anything other than
>GET or HEAD is explicitly forbidden by the HTTP spec ("MUST NOT").
Ah, it may be forbidden, but does it work? ;-)
>
>Micha

NO
Lets say we wanted to post something in the background (ie, not
redirect the browser). How do you do that in PHP? In perl, I'd use
the LWP library.

I'm not sure what I'd be looking for, but I don't seem to find it here:

http://www.php.net/manual/en/funcref.php

Jeff

What do you mean by "post something in the background"? You either
post or you don't post. There is no foreground or background on the web.

I found this just after I posted:

http://us.php.net/manual/en/book.http.php

But I'm unsure how that works as it is missing the examples.

Having a server retrieve a page or post data is not an unusual thing
to do, You may refer to it differently and my choice of terms may be
bad. One use would be if you are transparently handling something like a
Credit Card transaction and you don't want to take the customer off the
site. Usually you'd want that done with SSL and not on the query string.

Jeff
>>
Ok, you're talking about using the cURL libraries - that's the easiest
way, although you could do it with sockets, also.

Additionally, whether you're using SSL or not is completely independent
of whether you're using a query string (GET method) or not. GET/POST is
a means of transferring data between applications. SSL runs at a lower
level to encrypt/decrypt data. There is no relationship between them.

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

Jul 13 '08 #13
sheldonlg wrote:
C. (http://symcbean.blogspot.com/) wrote:
>On Jul 13, 7:13 am, The Natural Philosopher <a...@b.cwrote:
>>Michael Fesser wrote:
.oO(The Natural Philosopher)
Michael Fesser wrote:
>You can't redirect a POST request.
Are you sure?
Sending POST data to another location must be triggered or at least
confirmed by the user. Automatically redirecting anything other than
GET or HEAD is explicitly forbidden by the HTTP spec ("MUST NOT").
Ah, it may be forbidden, but does it work? ;-)

Micha

NO


Besides all that, a "hidden" variable is not really "hidden". A "view
source" will expose that variable. Session variables are, indeed, the
way to go.
well you can view cookies as well.
Frankly, though, I don't see the big problem. Since the OP is passing
in the error message, it is obviously to display it to the user.
Otherwise, why do it? If it is also in the URL, so what?
Jul 14 '08 #14
The Natural Philosopher wrote:
sheldonlg wrote:
>C. (http://symcbean.blogspot.com/) wrote:
>>On Jul 13, 7:13 am, The Natural Philosopher <a...@b.cwrote:
Michael Fesser wrote:
.oO(The Natural Philosopher)
>Michael Fesser wrote:
>>You can't redirect a POST request.
>Are you sure?
Sending POST data to another location must be triggered or at least
confirmed by the user. Automatically redirecting anything other than
GET or HEAD is explicitly forbidden by the HTTP spec ("MUST NOT").
Ah, it may be forbidden, but does it work? ;-)

Micha

NO


Besides all that, a "hidden" variable is not really "hidden". A "view
source" will expose that variable. Session variables are, indeed, the
way to go.

well you can view cookies as well.
>Frankly, though, I don't see the big problem. Since the OP is passing
in the error message, it is obviously to display it to the user.
Otherwise, why do it? If it is also in the URL, so what?
What does that have to do with this conversation? No one has mentioned
cookies until you did.

Why do you keep bringing up unrelated topics?

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

Jul 14 '08 #15
On Jul 14, 5:17*am, Jerry Stuckle <jstuck...@attglobal.netwrote:
The Natural Philosopher wrote:
sheldonlg wrote:
C. (http://symcbean.blogspot.com/) wrote:
On Jul 13, 7:13 am, The Natural Philosopher <a...@b.cwrote:
Michael Fesser wrote:
.oO(The Natural Philosopher)
Michael Fesser wrote:
>You can't redirect a POST request.
Are you sure?
Sending POST data to another location must be triggered or at least
confirmed by the user. Automatically redirecting anything other than
GET or HEAD is explicitly forbidden by the HTTP spec ("MUST NOT").
Ah, it may be forbidden, but does it work? ;-)
>>>Micha
>NO
Besides all that, a "hidden" variable is not really "hidden". *A "view
source" will expose that variable. *Session variables are, indeed, the
way to go.
well you can view cookies as well.
Frankly, though, I don't see the big problem. *Since the OP is passing
in the error message, it is obviously to display it to the user.
Otherwise, why do it? *If it is also in the URL, so what?

What does that have to do with this conversation? *No one has mentioned
cookies until you did.

Why do you keep bringing up unrelated topics?

--
==================
Remove the "x" from my email address
Jerry Stuckle
JDS Computer Training Corp.
jstuck...@attglobal.net
==================- Hide quoted text -

- Show quoted text -
or you can also try to base64_encode the url query string part.
$tmp = base64_encode('your query string')
then
?query_string=$tmp;
Jul 14 '08 #16
Jerry Stuckle wrote:
The Natural Philosopher wrote:
>sheldonlg wrote:
>>C. (http://symcbean.blogspot.com/) wrote:
On Jul 13, 7:13 am, The Natural Philosopher <a...@b.cwrote:
Michael Fesser wrote:
>.oO(The Natural Philosopher)
>>Michael Fesser wrote:
>>>You can't redirect a POST request.
>>Are you sure?
>Sending POST data to another location must be triggered or at least
>confirmed by the user. Automatically redirecting anything other than
>GET or HEAD is explicitly forbidden by the HTTP spec ("MUST NOT").
Ah, it may be forbidden, but does it work? ;-)
>
>Micha

NO
Besides all that, a "hidden" variable is not really "hidden". A
"view source" will expose that variable. Session variables are,
indeed, the way to go.

well you can view cookies as well.
>>Frankly, though, I don't see the big problem. Since the OP is
passing in the error message, it is obviously to display it to the
user. Otherwise, why do it? If it is also in the URL, so what?

What does that have to do with this conversation? No one has mentioned
cookies until you did.
What else constitutes a 'session variable' apart from POST or GET data
or cookies?

Why do you keep bringing up unrelated topics?
Because they are related.
Jul 14 '08 #17
The Natural Philosopher wrote:
Jerry Stuckle wrote:
>The Natural Philosopher wrote:
>>sheldonlg wrote:
C. (http://symcbean.blogspot.com/) wrote:
On Jul 13, 7:13 am, The Natural Philosopher <a...@b.cwrote:
>Michael Fesser wrote:
>>.oO(The Natural Philosopher)
>>>Michael Fesser wrote:
>>>>You can't redirect a POST request.
>>>Are you sure?
>>Sending POST data to another location must be triggered or at least
>>confirmed by the user. Automatically redirecting anything other than
>>GET or HEAD is explicitly forbidden by the HTTP spec ("MUST NOT").
>Ah, it may be forbidden, but does it work? ;-)
>>
>>Micha
>
NO
Besides all that, a "hidden" variable is not really "hidden". A
"view source" will expose that variable. Session variables are,
indeed, the way to go.
well you can view cookies as well.

Frankly, though, I don't see the big problem. Since the OP is
passing in the error message, it is obviously to display it to the
user. Otherwise, why do it? If it is also in the URL, so what?

What does that have to do with this conversation? No one has
mentioned cookies until you did.

What else constitutes a 'session variable' apart from POST or GET data
or cookies?

>Why do you keep bringing up unrelated topics?
Because they are related.
Because until you mentioned them, no one else said anything about cookies.

But then you don't understand that session variables aren't POST or GET
data or cookies.

Once again you bring up unrelated things because of your ignorance of
the subject.

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

Jul 14 '08 #18
On Jul 14, 6:19*am, Jerry Stuckle <jstuck...@attglobal.netwrote:
The Natural Philosopher wrote:
Jerry Stuckle wrote:
The Natural Philosopher wrote:
sheldonlg wrote:
C. (http://symcbean.blogspot.com/) wrote:
On Jul 13, 7:13 am, The Natural Philosopher <a...@b.cwrote:
Michael Fesser wrote:
>.oO(The Natural Philosopher)
>>Michael Fesser wrote:
>>>You can't redirect a POST request.
>>Are you sure?
>Sending POST data to another location must be triggered or at least
>confirmed by the user. Automatically redirecting anything other than
>GET or HEAD is explicitly forbidden by the HTTP spec ("MUST NOT")..
Ah, it may be forbidden, but does it work? ;-)
>>>>>Micha
>>>NO
>>Besides all that, a "hidden" variable is not really "hidden". *A
"view source" will expose that variable. *Session variables are,
indeed, the way to go.
>well you can view cookies as well.
>>Frankly, though, I don't see the big problem. *Since the OP is
passing in the error message, it is obviously to display it to the
user. Otherwise, why do it? *If it is also in the URL, so what?
What does that have to do with this conversation? *No one has
mentioned cookies until you did.
What else constitutes a 'session variable' apart from POST or GET data
or cookies?
Why do you keep bringing up unrelated topics?
Because they are related.

Because until you mentioned them, no one else said anything about cookies..

But then you don't understand that session variables aren't POST or GET
data or cookies.

Once again you bring up unrelated things because of your ignorance of
the subject.

--
==================
Remove the "x" from my email address
Jerry Stuckle
JDS Computer Training Corp.
jstuck...@attglobal.net
==================- Hide quoted text -

- Show quoted text -
Perhaps what he meant was that you COULD set a cookie on one script
and then initiate a redirect and view the contents of that cookie on a
second page.

Either way, since we are discussing using POST as a method for doing
this I thought I'd also put in my 2 cents:

You could coordinate PHP with Javascript. Have PHP set a hidden form
variable on one page, and then use Javascript to automatically submit
the form as soon as the page loads. But really, the simplest solution
would be good ole' session variables.

Jul 14 '08 #19
bu*************@gmail.com wrote:
On Jul 14, 6:19 am, Jerry Stuckle <jstuck...@attglobal.netwrote:
>The Natural Philosopher wrote:
>>Jerry Stuckle wrote:
The Natural Philosopher wrote:
sheldonlg wrote:
>C. (http://symcbean.blogspot.com/) wrote:
>>On Jul 13, 7:13 am, The Natural Philosopher <a...@b.cwrote:
>>>Michael Fesser wrote:
>>>>.oO(The Natural Philosopher)
>>>>>Michael Fesser wrote:
>>>>>>You can't redirect a POST request.
>>>>>Are you sure?
>>>>Sending POST data to another location must be triggered or at least
>>>>confirmed by the user. Automatically redirecting anything other than
>>>>GET or HEAD is explicitly forbidden by the HTTP spec ("MUST NOT").
>>>Ah, it may be forbidden, but does it work? ;-)
>>>>Micha
>>NO
>Besides all that, a "hidden" variable is not really "hidden". A
>"view source" will expose that variable. Session variables are,
>indeed, the way to go.
well you can view cookies as well.
>Frankly, though, I don't see the big problem. Since the OP is
>passing in the error message, it is obviously to display it to the
>user. Otherwise, why do it? If it is also in the URL, so what?
What does that have to do with this conversation? No one has
mentioned cookies until you did.
What else constitutes a 'session variable' apart from POST or GET data
or cookies?
Why do you keep bringing up unrelated topics?
Because they are related.
Because until you mentioned them, no one else said anything about cookies.

But then you don't understand that session variables aren't POST or GET
data or cookies.

Once again you bring up unrelated things because of your ignorance of
the subject.

--
==================
Remove the "x" from my email address
Jerry Stuckle
JDS Computer Training Corp.
jstuck...@attglobal.net
==================- Hide quoted text -

- Show quoted text -

Perhaps what he meant was that you COULD set a cookie on one script
and then initiate a redirect and view the contents of that cookie on a
second page.

Either way, since we are discussing using POST as a method for doing
this I thought I'd also put in my 2 cents:

You could coordinate PHP with Javascript. Have PHP set a hidden form
variable on one page, and then use Javascript to automatically submit
the form as soon as the page loads. But really, the simplest solution
would be good ole' session variables.

Yep, I've done that before when having to transfer to another site (a
submission to PayPal). But I don't like to do it - it requires the user
have javascript enabled. And that's not always the case.

I agree that a session variable is the way to go.

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

Jul 14 '08 #20
Jerry Stuckle wrote:
bu*************@gmail.com wrote:
>On Jul 14, 6:19 am, Jerry Stuckle <jstuck...@attglobal.netwrote:
>>The Natural Philosopher wrote:
Jerry Stuckle wrote:
The Natural Philosopher wrote:
>sheldonlg wrote:
>>C. (http://symcbean.blogspot.com/) wrote:
>>>On Jul 13, 7:13 am, The Natural Philosopher <a...@b.cwrote:
>>>>Michael Fesser wrote:
>>>>>.oO(The Natural Philosopher)
>>>>>>Michael Fesser wrote:
>>>>>>>You can't redirect a POST request.
>>>>>>Are you sure?
>>>>>Sending POST data to another location must be triggered or at
>>>>>least
>>>>>confirmed by the user. Automatically redirecting anything
>>>>>other than
>>>>>GET or HEAD is explicitly forbidden by the HTTP spec ("MUST
>>>>>NOT").
>>>>Ah, it may be forbidden, but does it work? ;-)
>>>>>Micha
>>>NO
>>Besides all that, a "hidden" variable is not really "hidden". A
>>"view source" will expose that variable. Session variables are,
>>indeed, the way to go.
>well you can view cookies as well.
>>Frankly, though, I don't see the big problem. Since the OP is
>>passing in the error message, it is obviously to display it to the
>>user. Otherwise, why do it? If it is also in the URL, so what?
What does that have to do with this conversation? No one has
mentioned cookies until you did.
What else constitutes a 'session variable' apart from POST or GET data
or cookies?
Why do you keep bringing up unrelated topics?
Because they are related.
Because until you mentioned them, no one else said anything about
cookies.

But then you don't understand that session variables aren't POST or GET
data or cookies.

Once again you bring up unrelated things because of your ignorance of
the subject.

--
==================
Remove the "x" from my email address
Jerry Stuckle
JDS Computer Training Corp.
jstuck...@attglobal.net
==================- Hide quoted text -

- Show quoted text -

Perhaps what he meant was that you COULD set a cookie on one script
and then initiate a redirect and view the contents of that cookie on a
second page.

Either way, since we are discussing using POST as a method for doing
this I thought I'd also put in my 2 cents:

You could coordinate PHP with Javascript. Have PHP set a hidden form
variable on one page, and then use Javascript to automatically submit
the form as soon as the page loads. But really, the simplest solution
would be good ole' session variables.


Yep, I've done that before when having to transfer to another site (a
submission to PayPal). But I don't like to do it - it requires the user
have javascript enabled. And that's not always the case.

I agree that a session variable is the way to go.
Oh dear. Jerryu is at it again

From the PHP manual

"Session support in PHP consists of a way to preserve certain data
across subsequent accesses. This enables you to build more customized
applications and increase the appeal of your web site.

A visitor accessing your web site is assigned a unique id, the so-called
session id. *This is either stored in a cookie on the user side or is
propagated in the URL.*"
Once more Stuckle is shown to be ignorant of the true way things work.
Jul 14 '08 #21
On Jul 14, 1:18*pm, The Natural Philosopher <a...@b.cwrote:
Jerry Stuckle wrote:
burgermeiste...@gmail.com wrote:
On Jul 14, 6:19 am, Jerry Stuckle <jstuck...@attglobal.netwrote:
The Natural Philosopher wrote:
Jerry Stuckle wrote:
The Natural Philosopher wrote:
sheldonlg wrote:
>C. (http://symcbean.blogspot.com/) wrote:
>>On Jul 13, 7:13 am, The Natural Philosopher <a...@b.cwrote:
>>>Michael Fesser wrote:
>>>>.oO(The Natural Philosopher)
>>>>>Michael Fesser wrote:
>>>>>>You can't redirect a POST request.
>>>>>Are you sure?
>>>>Sending POST data to another location must be triggered or at
>>>>least
>>>>confirmed by the user. Automatically redirecting anything
>>>>other than
>>>>GET or HEAD is explicitly forbidden by the HTTP spec ("MUST
>>>>NOT").
>>>Ah, it may be forbidden, but does it work? ;-)
>>>>Micha
>>NO
>Besides all that, a "hidden" variable is not really "hidden". *A
>"view source" will expose that variable. *Session variables are,
>indeed, the way to go.
well you can view cookies as well.
>Frankly, though, I don't see the big problem. *Since the OP is
>passing in the error message, it is obviously to display it to the
>user. Otherwise, why do it? *If it is also in the URL, so what?
What does that have to do with this conversation? *No one has
mentioned cookies until you did.
What else constitutes a 'session variable' apart from POST or GET data
or cookies?
Why do you keep bringing up unrelated topics?
Because they are related.
Because until you mentioned them, no one else said anything about
cookies.
>But then you don't understand that session variables aren't POST or GET
data or cookies.
>Once again you bring up unrelated things because of your ignorance of
the subject.
>--
==================
Remove the "x" from my email address
Jerry Stuckle
JDS Computer Training Corp.
jstuck...@attglobal.net
==================- Hide quoted text -
>- Show quoted text -
Perhaps what he meant was that you COULD set a cookie on one script
and then initiate a redirect and view the contents of that cookie on a
second page.
Either way, since we are discussing using POST as a method for doing
this I thought I'd also put in my 2 cents:
You could coordinate PHP with Javascript. Have PHP set a hidden form
variable on one page, and then use Javascript to automatically submit
the form as soon as the page loads. But really, the simplest solution
would be good ole' session variables.
Yep, I've done that before when having to transfer to another site (a
submission to PayPal). *But I don't like to do it - it requires the user
have javascript enabled. *And that's not always the case.
I agree that a session variable is the way to go.

Oh dear. Jerryu is at it again

*From the PHP manual

* "Session support in PHP consists of a way to preserve certain data
across subsequent accesses. This enables you to build more customized
applications and increase the appeal of your web site.

A visitor accessing your web site is assigned a unique id, the so-called
session id. *This is either stored in a cookie on the user side or is
propagated in the URL.*"

Once more Stuckle is shown to be ignorant of the true way things work.
Only the ID is stored in the cookie or the URL. Not the data itself.
So the ability to view the cookie will not display any information
that the session contains. The session data is stored server side
using the id in the cookie to track which user is associated with
which data server side. So your comment about being able to view
cookies like a view source is not comparable.
Jul 14 '08 #22
The Natural Philosopher wrote:
Jerry Stuckle wrote:
>bu*************@gmail.com wrote:
>>On Jul 14, 6:19 am, Jerry Stuckle <jstuck...@attglobal.netwrote:
The Natural Philosopher wrote:
Jerry Stuckle wrote:
>The Natural Philosopher wrote:
>>sheldonlg wrote:
>>>C. (http://symcbean.blogspot.com/) wrote:
>>>>On Jul 13, 7:13 am, The Natural Philosopher <a...@b.cwrote:
>>>>>Michael Fesser wrote:
>>>>>>.oO(The Natural Philosopher)
>>>>>>>Michael Fesser wrote:
>>>>>>>>You can't redirect a POST request.
>>>>>>>Are you sure?
>>>>>>Sending POST data to another location must be triggered or at
>>>>>>least
>>>>>>confirmed by the user. Automatically redirecting anything
>>>>>>other than
>>>>>>GET or HEAD is explicitly forbidden by the HTTP spec ("MUST
>>>>>>NOT").
>>>>>Ah, it may be forbidden, but does it work? ;-)
>>>>>>Micha
>>>>NO
>>>Besides all that, a "hidden" variable is not really "hidden". A
>>>"view source" will expose that variable. Session variables are,
>>>indeed, the way to go.
>>well you can view cookies as well.
>>>Frankly, though, I don't see the big problem. Since the OP is
>>>passing in the error message, it is obviously to display it to the
>>>user. Otherwise, why do it? If it is also in the URL, so what?
>What does that have to do with this conversation? No one has
>mentioned cookies until you did.
What else constitutes a 'session variable' apart from POST or GET data
or cookies?
>Why do you keep bringing up unrelated topics?
Because they are related.
Because until you mentioned them, no one else said anything about
cookies.

But then you don't understand that session variables aren't POST or GET
data or cookies.

Once again you bring up unrelated things because of your ignorance of
the subject.

--
==================
Remove the "x" from my email address
Jerry Stuckle
JDS Computer Training Corp.
jstuck...@attglobal.net
==================- Hide quoted text -

- Show quoted text -

Perhaps what he meant was that you COULD set a cookie on one script
and then initiate a redirect and view the contents of that cookie on a
second page.

Either way, since we are discussing using POST as a method for doing
this I thought I'd also put in my 2 cents:

You could coordinate PHP with Javascript. Have PHP set a hidden form
variable on one page, and then use Javascript to automatically submit
the form as soon as the page loads. But really, the simplest solution
would be good ole' session variables.


Yep, I've done that before when having to transfer to another site (a
submission to PayPal). But I don't like to do it - it requires the
user have javascript enabled. And that's not always the case.

I agree that a session variable is the way to go.
Oh dear. Jerryu is at it again

From the PHP manual

"Session support in PHP consists of a way to preserve certain data
across subsequent accesses. This enables you to build more customized
applications and increase the appeal of your web site.

A visitor accessing your web site is assigned a unique id, the so-called
session id. *This is either stored in a cookie on the user side or is
propagated in the URL.*"
Once more Stuckle is shown to be ignorant of the true way things work.
That's correct. Which has absolutely nothing to do with storing the
data in a cookie. But you don't know the difference.

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

Jul 14 '08 #23
On Jul 14, 2:27*pm, Jerry Stuckle <jstuck...@attglobal.netwrote:
The Natural Philosopher wrote:
Jerry Stuckle wrote:
burgermeiste...@gmail.com wrote:
On Jul 14, 6:19 am, Jerry Stuckle <jstuck...@attglobal.netwrote:
The Natural Philosopher wrote:
Jerry Stuckle wrote:
The Natural Philosopher wrote:
>sheldonlg wrote:
>>C. (http://symcbean.blogspot.com/) wrote:
>>>On Jul 13, 7:13 am, The Natural Philosopher <a...@b.cwrote:
>>>>Michael Fesser wrote:
>>>>>.oO(The Natural Philosopher)
>>>>>>Michael Fesser wrote:
>>>>>>>You can't redirect a POST request.
>>>>>>Are you sure?
>>>>>Sending POST data to another location must be triggered or at
>>>>>least
>>>>>confirmed by the user. Automatically redirecting anything
>>>>>other than
>>>>>GET or HEAD is explicitly forbidden by the HTTP spec ("MUST
>>>>>NOT").
>>>>Ah, it may be forbidden, but does it work? ;-)
>>>>>Micha
>>>NO
>>Besides all that, a "hidden" variable is not really "hidden". *A
>>"view source" will expose that variable. *Session variables are,
>>indeed, the way to go.
>well you can view cookies as well.
>>Frankly, though, I don't see the big problem. *Since the OP is
>>passing in the error message, it is obviously to display it to the
>>user. Otherwise, why do it? *If it is also in the URL, so what?
What does that have to do with this conversation? *No one has
mentioned cookies until you did.
What else constitutes a 'session variable' apart from POST or GET data
or cookies?
Why do you keep bringing up unrelated topics?
Because they are related.
Because until you mentioned them, no one else said anything about
cookies.
>>But then you don't understand that session variables aren't POST or GET
data or cookies.
>>Once again you bring up unrelated things because of your ignorance of
the subject.
>>--
==================
Remove the "x" from my email address
Jerry Stuckle
JDS Computer Training Corp.
jstuck...@attglobal.net
==================- Hide quoted text -
>>- Show quoted text -
>Perhaps what he meant was that you COULD set a cookie on one script
and then initiate a redirect and view the contents of that cookie on a
second page.
>Either way, since we are discussing using POST as a method for doing
this I thought I'd also put in my 2 cents:
>You could coordinate PHP with Javascript. Have PHP set a hidden form
variable on one page, and then use Javascript to automatically submit
the form as soon as the page loads. But really, the simplest solution
would be good ole' session variables.
Yep, I've done that before when having to transfer to another site (a
submission to PayPal). *But I don't like to do it - it requires the
user have javascript enabled. *And that's not always the case.
I agree that a session variable is the way to go.
Oh dear. Jerryu is at it again
*From the PHP manual
*"Session support in PHP consists of a way to preserve certain data
across subsequent accesses. This enables you to build more customized
applications and increase the appeal of your web site.
A visitor accessing your web site is assigned a unique id, the so-called
session id. *This is either stored in a cookie on the user side or is
propagated in the URL.*"
Once more Stuckle is shown to be ignorant of the true way things work.

That's correct. *Which has absolutely nothing to do with storing the
data in a cookie. *But you don't know the difference.

--
==================
Remove the "x" from my email address
Jerry Stuckle
JDS Computer Training Corp.
jstuck...@attglobal.net
==================- Hide quoted text -

- Show quoted text -
I'd give the guy some amnesty. I know when I was learning about PHP in
the first place, I had a difficult time comprehending sessions,
cookies and their exact relation. Then again, I only drop by these PHP
groups from time to time, so I don't know the guy's history in the
group(s) so well.
Jul 14 '08 #24
Peter D. wrote:
On Jul 14, 1:18 pm, The Natural Philosopher <a...@b.cwrote:
>Jerry Stuckle wrote:
>>burgermeiste...@gmail.com wrote:
On Jul 14, 6:19 am, Jerry Stuckle <jstuck...@attglobal.netwrote:
The Natural Philosopher wrote:
>Jerry Stuckle wrote:
>>The Natural Philosopher wrote:
>>>sheldonlg wrote:
>>>>C. (http://symcbean.blogspot.com/) wrote:
>>>>>On Jul 13, 7:13 am, The Natural Philosopher <a...@b.cwrote:
>>>>>>Michael Fesser wrote:
>>>>>>>.oO(The Natural Philosopher)
>>>>>>>>Michael Fesser wrote:
>>>>>>>>>You can't redirect a POST request.
>>>>>>>>Are you sure?
>>>>>>>Sending POST data to another location must be triggered or at
>>>>>>>least
>>>>>>>confirmed by the user. Automatically redirecting anything
>>>>>>>other than
>>>>>>>GET or HEAD is explicitly forbidden by the HTTP spec ("MUST
>>>>>>>NOT").
>>>>>>Ah, it may be forbidden, but does it work? ;-)
>>>>>>>Micha
>>>>>NO
>>>>Besides all that, a "hidden" variable is not really "hidden". A
>>>>"view source" will expose that variable. Session variables are,
>>>>indeed, the way to go.
>>>well you can view cookies as well.
>>>>Frankly, though, I don't see the big problem. Since the OP is
>>>>passing in the error message, it is obviously to display it to the
>>>>user. Otherwise, why do it? If it is also in the URL, so what?
>>What does that have to do with this conversation? No one has
>>mentioned cookies until you did.
>What else constitutes a 'session variable' apart from POST or GET data
>or cookies?
>>Why do you keep bringing up unrelated topics?
>Because they are related.
Because until you mentioned them, no one else said anything about
cookies.
But then you don't understand that session variables aren't POST or GET
data or cookies.
Once again you bring up unrelated things because of your ignorance of
the subject.
--
==================
Remove the "x" from my email address
Jerry Stuckle
JDS Computer Training Corp.
jstuck...@attglobal.net
==================- Hide quoted text -
- Show quoted text -
Perhaps what he meant was that you COULD set a cookie on one script
and then initiate a redirect and view the contents of that cookie on a
second page.
Either way, since we are discussing using POST as a method for doing
this I thought I'd also put in my 2 cents:
You could coordinate PHP with Javascript. Have PHP set a hidden form
variable on one page, and then use Javascript to automatically submit
the form as soon as the page loads. But really, the simplest solution
would be good ole' session variables.
Yep, I've done that before when having to transfer to another site (a
submission to PayPal). But I don't like to do it - it requires the user
have javascript enabled. And that's not always the case.
I agree that a session variable is the way to go.
Oh dear. Jerryu is at it again

From the PHP manual

"Session support in PHP consists of a way to preserve certain data
across subsequent accesses. This enables you to build more customized
applications and increase the appeal of your web site.

A visitor accessing your web site is assigned a unique id, the so-called
session id. *This is either stored in a cookie on the user side or is
propagated in the URL.*"

Once more Stuckle is shown to be ignorant of the true way things work.

Only the ID is stored in the cookie or the URL. Not the data itself.
So the ability to view the cookie will not display any information
that the session contains. The session data is stored server side
using the id in the cookie to track which user is associated with
which data server side. So your comment about being able to view
cookies like a view source is not comparable.
But that goes for any information passed between client and server: one
session Id can relate any amount of server side data to a session:
Whether you use php 'sessions' or construct your own system is
irrelevant: in the limit there are only two generaic ways to maintain
state across pages: cookies or GET variables, plus post if you set a form.

They are as secure as each other in the limit.
My objection ws that any session ID was ultimately decipherable, and to
point out that its as easy to view a cookie as a URL..at which point
jerry big mouth stick his oar in and I had to explain why cookies are
associated with session variables, as he obviously hadn't read the manual.

Jul 14 '08 #25
Jerry Stuckle wrote:
The Natural Philosopher wrote:
>Jerry Stuckle wrote:
>>bu*************@gmail.com wrote:
On Jul 14, 6:19 am, Jerry Stuckle <jstuck...@attglobal.netwrote:
The Natural Philosopher wrote:
>Jerry Stuckle wrote:
>>The Natural Philosopher wrote:
>>>sheldonlg wrote:
>>>>C. (http://symcbean.blogspot.com/) wrote:
>>>>>On Jul 13, 7:13 am, The Natural Philosopher <a...@b.cwrote:
>>>>>>Michael Fesser wrote:
>>>>>>>.oO(The Natural Philosopher)
>>>>>>>>Michael Fesser wrote:
>>>>>>>>>You can't redirect a POST request.
>>>>>>>>Are you sure?
>>>>>>>Sending POST data to another location must be triggered or
>>>>>>>at least
>>>>>>>confirmed by the user. Automatically redirecting anything
>>>>>>>other than
>>>>>>>GET or HEAD is explicitly forbidden by the HTTP spec ("MUST
>>>>>>>NOT").
>>>>>>Ah, it may be forbidden, but does it work? ;-)
>>>>>>>Micha
>>>>>NO
>>>>Besides all that, a "hidden" variable is not really "hidden". A
>>>>"view source" will expose that variable. Session variables are,
>>>>indeed, the way to go.
>>>well you can view cookies as well.
>>>>Frankly, though, I don't see the big problem. Since the OP is
>>>>passing in the error message, it is obviously to display it to the
>>>>user. Otherwise, why do it? If it is also in the URL, so what?
>>What does that have to do with this conversation? No one has
>>mentioned cookies until you did.
>What else constitutes a 'session variable' apart from POST or GET
>data
>or cookies?
>>Why do you keep bringing up unrelated topics?
>Because they are related.
Because until you mentioned them, no one else said anything about
cookies.
>
But then you don't understand that session variables aren't POST or
GET
data or cookies.
>
Once again you bring up unrelated things because of your ignorance of
the subject.
>
--
==================
Remove the "x" from my email address
Jerry Stuckle
JDS Computer Training Corp.
jstuck...@attglobal.net
==================- Hide quoted text -
>
- Show quoted text -

Perhaps what he meant was that you COULD set a cookie on one script
and then initiate a redirect and view the contents of that cookie on a
second page.

Either way, since we are discussing using POST as a method for doing
this I thought I'd also put in my 2 cents:

You could coordinate PHP with Javascript. Have PHP set a hidden form
variable on one page, and then use Javascript to automatically submit
the form as soon as the page loads. But really, the simplest solution
would be good ole' session variables.

Yep, I've done that before when having to transfer to another site (a
submission to PayPal). But I don't like to do it - it requires the
user have javascript enabled. And that's not always the case.

I agree that a session variable is the way to go.
Oh dear. Jerryu is at it again

From the PHP manual

"Session support in PHP consists of a way to preserve certain data
across subsequent accesses. This enables you to build more customized
applications and increase the appeal of your web site.

A visitor accessing your web site is assigned a unique id, the
so-called session id. *This is either stored in a cookie on the user
side or is propagated in the URL.*"
Once more Stuckle is shown to be ignorant of the true way things work.

That's correct. Which has absolutely nothing to do with storing the
data in a cookie. But you don't know the difference.
I never mentioned storing the data in a cookie: that was your own
invention: I merely pointed out that cookies are potentially visible.
You chose to open your big mouth and invent a straw man.
Jul 14 '08 #26
bu*************@gmail.com wrote:
On Jul 14, 2:27 pm, Jerry Stuckle <jstuck...@attglobal.netwrote:
>The Natural Philosopher wrote:
>>Jerry Stuckle wrote:
burgermeiste...@gmail.com wrote:
On Jul 14, 6:19 am, Jerry Stuckle <jstuck...@attglobal.netwrote:
>The Natural Philosopher wrote:
>>Jerry Stuckle wrote:
>>>The Natural Philosopher wrote:
>>>>sheldonlg wrote:
>>>>>C. (http://symcbean.blogspot.com/) wrote:
>>>>>>On Jul 13, 7:13 am, The Natural Philosopher <a...@b.cwrote:
>>>>>>>Michael Fesser wrote:
>>>>>>>>.oO(The Natural Philosopher)
>>>>>>>>>Michael Fesser wrote:
>>>>>>>>>>You can't redirect a POST request.
>>>>>>>>>Are you sure?
>>>>>>>>Sending POST data to another location must be triggered or at
>>>>>>>>least
>>>>>>>>confirmed by the user. Automatically redirecting anything
>>>>>>>>other than
>>>>>>>>GET or HEAD is explicitly forbidden by the HTTP spec ("MUST
>>>>>>>>NOT").
>>>>>>>Ah, it may be forbidden, but does it work? ;-)
>>>>>>>>Micha
>>>>>>NO
>>>>>Besides all that, a "hidden" variable is not really "hidden". A
>>>>>"view source" will expose that variable. Session variables are,
>>>>>indeed, the way to go.
>>>>well you can view cookies as well.
>>>>>Frankly, though, I don't see the big problem. Since the OP is
>>>>>passing in the error message, it is obviously to display it to the
>>>>>user. Otherwise, why do it? If it is also in the URL, so what?
>>>What does that have to do with this conversation? No one has
>>>mentioned cookies until you did.
>>What else constitutes a 'session variable' apart from POST or GET data
>>or cookies?
>>>Why do you keep bringing up unrelated topics?
>>Because they are related.
>Because until you mentioned them, no one else said anything about
>cookies.
>But then you don't understand that session variables aren't POST or GET
>data or cookies.
>Once again you bring up unrelated things because of your ignorance of
>the subject.
>--
>==================
>Remove the "x" from my email address
>Jerry Stuckle
>JDS Computer Training Corp.
>jstuck...@attglobal.net
>==================- Hide quoted text -
>- Show quoted text -
Perhaps what he meant was that you COULD set a cookie on one script
and then initiate a redirect and view the contents of that cookie on a
second page.
Either way, since we are discussing using POST as a method for doing
this I thought I'd also put in my 2 cents:
You could coordinate PHP with Javascript. Have PHP set a hidden form
variable on one page, and then use Javascript to automatically submit
the form as soon as the page loads. But really, the simplest solution
would be good ole' session variables.
Yep, I've done that before when having to transfer to another site (a
submission to PayPal). But I don't like to do it - it requires the
user have javascript enabled. And that's not always the case.
I agree that a session variable is the way to go.
Oh dear. Jerryu is at it again
From the PHP manual
"Session support in PHP consists of a way to preserve certain data
across subsequent accesses. This enables you to build more customized
applications and increase the appeal of your web site.
A visitor accessing your web site is assigned a unique id, the so-called
session id. *This is either stored in a cookie on the user side or is
propagated in the URL.*"
Once more Stuckle is shown to be ignorant of the true way things work.
That's correct. Which has absolutely nothing to do with storing the
data in a cookie. But you don't know the difference.

--
==================
Remove the "x" from my email address
Jerry Stuckle
JDS Computer Training Corp.
jstuck...@attglobal.net
==================- Hide quoted text -

- Show quoted text -

I'd give the guy some amnesty. I know when I was learning about PHP in
the first place, I had a difficult time comprehending sessions,
cookies and their exact relation. Then again, I only drop by these PHP
groups from time to time, so I don't know the guy's history in the
group(s) so well.
Yes, but his problem is he can read (and quote), but he doesn't
comprehend what he reads.

This isn't the first time he's gone off on a completely irrelevant
tangent, then tries to make it look like someone else doesn't understand.

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

Jul 14 '08 #27
bu*************@gmail.com wrote:
On Jul 14, 2:27 pm, Jerry Stuckle <jstuck...@attglobal.netwrote:
>The Natural Philosopher wrote:
>>Jerry Stuckle wrote:
burgermeiste...@gmail.com wrote:
On Jul 14, 6:19 am, Jerry Stuckle <jstuck...@attglobal.netwrote:
>The Natural Philosopher wrote:
>>Jerry Stuckle wrote:
>>>The Natural Philosopher wrote:
>>>>sheldonlg wrote:
>>>>>C. (http://symcbean.blogspot.com/) wrote:
>>>>>>On Jul 13, 7:13 am, The Natural Philosopher <a...@b.cwrote:
>>>>>>>Michael Fesser wrote:
>>>>>>>>.oO(The Natural Philosopher)
>>>>>>>>>Michael Fesser wrote:
>>>>>>>>>>You can't redirect a POST request.
>>>>>>>>>Are you sure?
>>>>>>>>Sending POST data to another location must be triggered or at
>>>>>>>>least
>>>>>>>>confirmed by the user. Automatically redirecting anything
>>>>>>>>other than
>>>>>>>>GET or HEAD is explicitly forbidden by the HTTP spec ("MUST
>>>>>>>>NOT").
>>>>>>>Ah, it may be forbidden, but does it work? ;-)
>>>>>>>>Micha
>>>>>>NO
>>>>>Besides all that, a "hidden" variable is not really "hidden". A
>>>>>"view source" will expose that variable. Session variables are,
>>>>>indeed, the way to go.
>>>>well you can view cookies as well.
>>>>>Frankly, though, I don't see the big problem. Since the OP is
>>>>>passing in the error message, it is obviously to display it to the
>>>>>user. Otherwise, why do it? If it is also in the URL, so what?
>>>What does that have to do with this conversation? No one has
>>>mentioned cookies until you did.
>>What else constitutes a 'session variable' apart from POST or GET data
>>or cookies?
>>>Why do you keep bringing up unrelated topics?
>>Because they are related.
>Because until you mentioned them, no one else said anything about
>cookies.
>But then you don't understand that session variables aren't POST or GET
>data or cookies.
>Once again you bring up unrelated things because of your ignorance of
>the subject.
>--
>==================
>Remove the "x" from my email address
>Jerry Stuckle
>JDS Computer Training Corp.
>jstuck...@attglobal.net
>==================- Hide quoted text -
>- Show quoted text -
Perhaps what he meant was that you COULD set a cookie on one script
and then initiate a redirect and view the contents of that cookie on a
second page.
Either way, since we are discussing using POST as a method for doing
this I thought I'd also put in my 2 cents:
You could coordinate PHP with Javascript. Have PHP set a hidden form
variable on one page, and then use Javascript to automatically submit
the form as soon as the page loads. But really, the simplest solution
would be good ole' session variables.
Yep, I've done that before when having to transfer to another site (a
submission to PayPal). But I don't like to do it - it requires the
user have javascript enabled. And that's not always the case.
I agree that a session variable is the way to go.
Oh dear. Jerryu is at it again
From the PHP manual
"Session support in PHP consists of a way to preserve certain data
across subsequent accesses. This enables you to build more customized
applications and increase the appeal of your web site.
A visitor accessing your web site is assigned a unique id, the so-called
session id. *This is either stored in a cookie on the user side or is
propagated in the URL.*"
Once more Stuckle is shown to be ignorant of the true way things work.
That's correct. Which has absolutely nothing to do with storing the
data in a cookie. But you don't know the difference.

--
==================
Remove the "x" from my email address
Jerry Stuckle
JDS Computer Training Corp.
jstuck...@attglobal.net
==================- Hide quoted text -

- Show quoted text -

I'd give the guy some amnesty. I know when I was learning about PHP in
the first place, I had a difficult time comprehending sessions,
cookies and their exact relation. Then again, I only drop by these PHP
groups from time to time, so I don't know the guy's history in the
group(s) so well.
I have no trouble understanding cookies and sessions.

Its jerry's assumptions that I didn't know that irritate.

All that is needed t preserve states across a session is to have some
unique session ID. That has to be carried by a cookie or by a URL .

After that, you can associate any amount of crap with that session ID.

I simply didn't see any difference in principle between carrying the
session ID as a URL than as a cookie.

Which I pointed out. Jerry then said 'what's cookies got to do with it'
so I explained what they had to do with it.
Dont you think a knowledgeable person would have said at that point 'ah
but there is a difference between carrying data and a pointer to data'
or somesuch?

Not our jerry. Always jumps at a chance to piss all over someone, so he
ended up in the Jerry trap.

Jul 14 '08 #28
..oO(The Natural Philosopher)
>I have no trouble understanding cookies and sessions.

Its jerry's assumptions that I didn't know that irritate.

All that is needed t preserve states across a session is to have some
unique session ID. That has to be carried by a cookie or by a URL .

After that, you can associate any amount of crap with that session ID.

I simply didn't see any difference in principle between carrying the
session ID as a URL than as a cookie.
There are a dozen ways for a URL to leak (the HTTP_REFERER is just one
way), which would easily allow other sites to grab valid session IDs.
Such attacks were done some years ago against a number of big free mail
services, which led to thousands of stolen accounts.

Session cookies are much more secure, because you actually have to sniff
the HTTP communication between the clients and the server or use XSS to
grab them.
>Which I pointed out. Jerry then said 'what's cookies got to do with it'
so I explained what they had to do with it.
But they don't have anything to do with the OPs problem, which was about
passing data from one page to another. POST won't work here, GET is not
wanted, so the only viable alternative is a session. Question answered.

Micha
Jul 14 '08 #29
Michael Fesser wrote:
.oO(The Natural Philosopher)
>I have no trouble understanding cookies and sessions.

Its jerry's assumptions that I didn't know that irritate.

All that is needed t preserve states across a session is to have some
unique session ID. That has to be carried by a cookie or by a URL .

After that, you can associate any amount of crap with that session ID.

I simply didn't see any difference in principle between carrying the
session ID as a URL than as a cookie.

There are a dozen ways for a URL to leak (the HTTP_REFERER is just one
way), which would easily allow other sites to grab valid session IDs.
Such attacks were done some years ago against a number of big free mail
services, which led to thousands of stolen accounts.

Session cookies are much more secure, because you actually have to sniff
the HTTP communication between the clients and the server or use XSS to
grab them.
>Which I pointed out. Jerry then said 'what's cookies got to do with it'
so I explained what they had to do with it.

But they don't have anything to do with the OPs problem, which was about
passing data from one page to another. POST won't work here, GET is not
wanted, so the only viable alternative is a session. Question answered.
No the only viable way is a cookie. Whether or not that is used with PHP
sessions or not, is actually not the point. They are no more secure than
simply setting a number in your own custom cookie.

All PHP sessions are area wasy of pasing a unique ID using cookies, and
a handy interface fr dummies, but they still use either the URL or the
cookie to pass that one vital bit of info.

Now I also thought that the point was that the user was worried about
his clients seeing the info in the URL and messing with it.

My point was that they could as easily mess with the cookies.

I don't recall any issues about security with respect to third parties
at all, which makes your point another straw man.
Micha
Jul 14 '08 #30
On Jul 14, 3:47*pm, The Natural Philosopher <a...@b.cwrote:
Michael Fesser wrote:
.oO(The Natural Philosopher)
I have no trouble understanding cookies and sessions.
Its jerry's assumptions that I didn't know that irritate.
All that is needed t preserve states across a session is to have some
unique session ID. That has to be carried by a cookie or by a URL .
After that, you can associate any amount of crap with that session ID.
I simply didn't see any difference in principle between carrying the
session ID as a URL than as a cookie.
There are a dozen ways for a URL to leak (the HTTP_REFERER is just one
way), which would easily allow other sites to grab valid session IDs.
Such attacks were done some years ago against a number of big free mail
services, which led to thousands of stolen accounts.
Session cookies are much more secure, because you actually have to sniff
the HTTP communication between the clients and the server or use XSS to
grab them.
Which I pointed out. Jerry then said 'what's cookies got to do with it'
so I explained what they had to do with it.
But they don't have anything to do with the OPs problem, which was about
passing data from one page to another. POST won't work here, GET is not
wanted, so the only viable alternative is a session. Question answered.

No the only viable way is a cookie. Whether or not that is used with PHP
sessions or not, is actually not the point. They are no more secure than
simply setting a number in your own custom cookie.

All PHP sessions are area wasy of pasing a unique ID using cookies, and
a handy interface fr dummies, but they still use either the URL or the
cookie to pass that one vital bit of info.

Now I also thought that the point was that the user was worried about
his clients seeing the info in the URL and messing with it.

My point was that they could as easily mess with the cookies.

I don't recall any issues about security with respect to third parties
at all, which makes your point another straw man.
Micha- Hide quoted text -

- Show quoted text -- Hide quoted text -

- Show quoted text -
Okay, I'm beginning to see why some other group members are rather
frustrated with Natural Philosopher.

Using sessions only stores the ID associated with the user on the
client machine. That ID is linked to the client's data which is stored
on a file on the server the client is communicating with. Cookies
actually store all the data on the client machine. That means that
when you use cookies, all the data is available for the client to view
and edit. Using sessions seperates the client from his or her data,
thus making it uneditable; the only thing that can be edited on the
client is the session ID, which isn't very useful, since at best you
associate yourself with someone else's data, and at worse, you divorce
the client from its session data. Therefore, using sessions is more
secure because the client cannot directly access his or her data.

How did this even become a security discussion????
Jul 14 '08 #31
..oO(The Natural Philosopher)
>Michael Fesser wrote:
>But they don't have anything to do with the OPs problem, which was about
passing data from one page to another. POST won't work here, GET is not
wanted, so the only viable alternative is a session. Question answered.

No the only viable way is a cookie.
For passing data from one page to another? You're kidding.
>Whether or not that is used with PHP
sessions or not, is actually not the point.
Correct. The point is whether to store the actual data in a session or
in a cookie. If you think that cookies are better here, then you haven't
understood the concept of sessions.
>They are no more secure than
simply setting a number in your own custom cookie.

All PHP sessions are area wasy of pasing a unique ID using cookies, and
a handy interface fr dummies, but they still use either the URL or the
cookie to pass that one vital bit of info.

Now I also thought that the point was that the user was worried about
his clients seeing the info in the URL and messing with it.
You're still missing the point. With sessions the client will never see
the actual data that's stored in it, because it never leaves the server!

You can easily write something like "the client is too stupid to enter
valid data" as an error string to your session - the client will never
see it. If you would store the same info to a cookie instead, then you
might get some problems.
>My point was that they could as easily mess with the cookies.
Sure, but in this case all they can do is to invalidate the session ID
and kick themselves out of the application. They can't do any harm. But
with the actual data stored in the cookie, they could manipulate it at
will and maybe even control the application's behaviour.
>I don't recall any issues about security with respect to third parties
at all, which makes your point another straw man.
The scenario was always the same:

* attacker sends an email to thousands of users with a link to a
malicious site
* Joe User opens the mail in his webmailer frontend
* Joe User clicks the link
* browsers requests new URL and sends the current webmailer URL in the
HTTP referer - including the current SID
* attacker just has open the referer URL and change the account password

(It worked even better with HTML mails and embedded images, because the
user didn't have to click a link anymore.)

This happened a lot with various big free mailers years ago and is the
reason why many of them don't use URL-SIDs anymore and don't directly
open external links from within an email, but use a kind of "de-referer"
script.

Micha
Jul 14 '08 #32
bu*************@gmail.com wrote:
On Jul 14, 3:47 pm, The Natural Philosopher <a...@b.cwrote:
>Michael Fesser wrote:
>>.oO(The Natural Philosopher)
I have no trouble understanding cookies and sessions.
Its jerry's assumptions that I didn't know that irritate.
All that is needed t preserve states across a session is to have some
unique session ID. That has to be carried by a cookie or by a URL .
After that, you can associate any amount of crap with that session ID.
I simply didn't see any difference in principle between carrying the
session ID as a URL than as a cookie.
There are a dozen ways for a URL to leak (the HTTP_REFERER is just one
way), which would easily allow other sites to grab valid session IDs.
Such attacks were done some years ago against a number of big free mail
services, which led to thousands of stolen accounts.
Session cookies are much more secure, because you actually have to sniff
the HTTP communication between the clients and the server or use XSS to
grab them.
Which I pointed out. Jerry then said 'what's cookies got to do with it'
so I explained what they had to do with it.
But they don't have anything to do with the OPs problem, which was about
passing data from one page to another. POST won't work here, GET is not
wanted, so the only viable alternative is a session. Question answered.
No the only viable way is a cookie. Whether or not that is used with PHP
sessions or not, is actually not the point. They are no more secure than
simply setting a number in your own custom cookie.

All PHP sessions are area wasy of pasing a unique ID using cookies, and
a handy interface fr dummies, but they still use either the URL or the
cookie to pass that one vital bit of info.

Now I also thought that the point was that the user was worried about
his clients seeing the info in the URL and messing with it.

My point was that they could as easily mess with the cookies.

I don't recall any issues about security with respect to third parties
at all, which makes your point another straw man.
>>Micha- Hide quoted text -
- Show quoted text -- Hide quoted text -

- Show quoted text -

Okay, I'm beginning to see why some other group members are rather
frustrated with Natural Philosopher.

Using sessions only stores the ID associated with the user on the
client machine. That ID is linked to the client's data which is stored
on a file on the server the client is communicating with. Cookies
actually store all the data on the client machine. That means that
when you use cookies, all the data is available for the client to view
and edit. Using sessions seperates the client from his or her data,
thus making it uneditable; the only thing that can be edited on the
client is the session ID, which isn't very useful, since at best you
associate yourself with someone else's data, and at worse, you divorce
the client from its session data. Therefore, using sessions is more
secure because the client cannot directly access his or her data.

How did this even become a security discussion????
Ever since The Natural Philosopher made another stupid comment and I
called him on it.

Now he's doing his best to try to justify his stupidity.

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

Jul 14 '08 #33
bu*************@gmail.com wrote:
On Jul 14, 3:47 pm, The Natural Philosopher <a...@b.cwrote:
>Michael Fesser wrote:
>>.oO(The Natural Philosopher)
I have no trouble understanding cookies and sessions.
Its jerry's assumptions that I didn't know that irritate.
All that is needed t preserve states across a session is to have some
unique session ID. That has to be carried by a cookie or by a URL .
After that, you can associate any amount of crap with that session ID.
I simply didn't see any difference in principle between carrying the
session ID as a URL than as a cookie.
There are a dozen ways for a URL to leak (the HTTP_REFERER is just one
way), which would easily allow other sites to grab valid session IDs.
Such attacks were done some years ago against a number of big free mail
services, which led to thousands of stolen accounts.
Session cookies are much more secure, because you actually have to sniff
the HTTP communication between the clients and the server or use XSS to
grab them.
Which I pointed out. Jerry then said 'what's cookies got to do with it'
so I explained what they had to do with it.
But they don't have anything to do with the OPs problem, which was about
passing data from one page to another. POST won't work here, GET is not
wanted, so the only viable alternative is a session. Question answered.
No the only viable way is a cookie. Whether or not that is used with PHP
sessions or not, is actually not the point. They are no more secure than
simply setting a number in your own custom cookie.

All PHP sessions are area wasy of pasing a unique ID using cookies, and
a handy interface fr dummies, but they still use either the URL or the
cookie to pass that one vital bit of info.

Now I also thought that the point was that the user was worried about
his clients seeing the info in the URL and messing with it.

My point was that they could as easily mess with the cookies.

I don't recall any issues about security with respect to third parties
at all, which makes your point another straw man.
>>Micha- Hide quoted text -
- Show quoted text -- Hide quoted text -

- Show quoted text -

Okay, I'm beginning to see why some other group members are rather
frustrated with Natural Philosopher.

Using sessions only stores the ID associated with the user on the
client machine. That ID is linked to the client's data which is stored
on a file on the server the client is communicating with. Cookies
actually store all the data on the client machine. That means that
when you use cookies, all the data is available for the client to view
and edit. Using sessions seperates the client from his or her data,
thus making it uneditable; the only thing that can be edited on the
client is the session ID, which isn't very useful, since at best you
associate yourself with someone else's data, and at worse, you divorce
the client from its session data. Therefore, using sessions is more
secure because the client cannot directly access his or her data.

How did this even become a security discussion????
Ever since The Natural Philosopher made another stupid comment and I
called him on it.

Now he's doing his best to try to justify his stupidity.

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

Jul 14 '08 #34
bu*************@gmail.com wrote:
....
>>That's correct. Which has absolutely nothing to do with storing the
data in a cookie. But you don't know the difference.
You should set a nick of jonny jumper, stuck; you're debasing yourself
again.
>>>
--
==================
Remove the "x" from my email address
Jerry Stuckle
JDS Computer Training Corp.
jstuck...@attglobal.net
==================- Hide quoted text -

- Show quoted text -

I'd give the guy some amnesty. I know when I was learning about PHP
in the first place, I had a difficult time comprehending sessions,
cookies and their exact relation. Then again, I only drop by these
PHP groups from time to time, so I don't know the guy's history in
the group(s) so well.

Yes, but his problem is he can read (and quote), but he doesn't
comprehend what he reads.
So ... you come down on someone YOU think has low reading comprehension
skills; now, THAT is an intelligent attitude, I must say. If you only
posted what you actually knew, we'd never hear from you again, would we?
>
This isn't the first time he's gone off on a completely irrelevant
tangent,
Just like you do, and
then tries to make it look like someone else doesn't
understand.
exactly as you do.

Your intelligence is superceded only by your total lack of power; you
won't get it back this way.

It's too bad they let you breathe the same air other sapient beings
breathe.


Jul 14 '08 #35
....
>>
How did this even become a security discussion????

Ever since The Natural Philosopher made another stupid comment and I
called him on it.
Aww, and you're just so proud of yourself over it too, aren't you?
>
Now he's doing his best to try to justify his stupidity.
Eggzactly as I've watched you do over and over in several threads now.
Sometimes you're entertaining, other times you're just plain boring.
Funny how your lack of a willingness to assist people shows through in
your pathetic power plays in these posts. You're one of the original
"Kaners" I suspect.

Jul 14 '08 #36
....
>>
How did this even become a security discussion????

Ever since The Natural Philosopher made another stupid comment and I
called him on it.

Now he's doing his best to try to justify his stupidity.
13 seconds between identical posts; you're letting your liver quiver too
much.
Jul 14 '08 #37
..oO(Twayne)
>13 seconds
15 minutes.
>between identical posts; you're letting your liver quiver too
much.
Occasional duplicate postings are no reason for a flame.

Sometimes you get an error or a connection timeout, even though the
server already got the full posting. Sometimes the posting might even
got stuck in some queue.

To be sure you just send it again - and there you have your duplicate.

Micha
Jul 15 '08 #38
Twayne wrote:
...
>>How did this even become a security discussion????
Ever since The Natural Philosopher made another stupid comment and I
called him on it.

Aww, and you're just so proud of yourself over it too, aren't you?
>Now he's doing his best to try to justify his stupidity.

Eggzactly as I've watched you do over and over in several threads now.
Sometimes you're entertaining, other times you're just plain boring.
Funny how your lack of a willingness to assist people shows through in
your pathetic power plays in these posts. You're one of the original
"Kaners" I suspect.

Go away, stoopid twat. You're not even funny any more. You've just
become a troll. And one who's going to have a hell of a time finding
ANY answers here.

<plonk!>

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

Jul 15 '08 #39
Michael Fesser wrote:
.oO(Twayne)
>13 seconds

15 minutes.
>between identical posts; you're letting your liver quiver too
much.

Occasional duplicate postings are no reason for a flame.

Sometimes you get an error or a connection timeout, even though the
server already got the full posting. Sometimes the posting might even
got stuck in some queue.

To be sure you just send it again - and there you have your duplicate.

Micha
Don't worry about him, Micha. He's just becoming another troll. He
doesn't like it that Luuk told him to try googling before asking here.
He just thinks we're his personal (free) consulting service.

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

Jul 15 '08 #40
On Jul 14, 6:48*pm, "Twayne" <nob...@devnull.spamcop.netwrote:
...
How did this even become a security discussion????
Ever since The Natural Philosopher made another stupid comment and I
called him on it.

Aww, and you're just so proud of yourself over it too, aren't you?
Now he's doing his best to try to justify his stupidity.

Eggzactly as I've watched you do over and over in several threads now.
Sometimes you're entertaining, other times you're just plain boring.
Funny how your lack of a willingness to assist people shows through in
your pathetic power plays in these posts. *You're one of the original
"Kaners" I suspect.
Ah, joining a flame war...nothing quite like it.

Jerry might be a dick from time to time, but his participation and
helpfulness to the PHP groups is unprecedented. On days I lurk he has
questions answered before I even can write a response.

To top that I've actually seen messages where he admits he's wrong;
the last thing he's doing here is stroking his e-peen.
Jul 15 '08 #41
Thanks everyone. I ll just use sessions :-).

Regards
Jul 15 '08 #42
Message-ID: <12****************@proxy01.news.clara.netfrom The Natural
Philosopher contained the following:
>Now I also thought that the point was that the user was worried about
his clients seeing the info in the URL and messing with it.
Well that's easy enough to check.

From the OP:-
"I have a PHP script that does some processing, and stores an error
message as a variable. The script then redirects to another script
with the error string in the URL, with the second script displaying
the message and continues with the rest of the logic.

Now I want to hide the error message from the URL, but the second
script needs to continue working as is. How can I do this? I have
thought about md5'ing the message but the URLs still look messy. Any
other alternatives?"
--end quote

You started digging a hole when you suggested using the POST method and
clearly haven't stopped digging yet.

To the OP.

Instead of sessions you could store all your error messages in an array
and then pass the array key in the URL
Script 2 then simply looks up the error message from the array.

--
Geoff Berrow 0110001001101100010000000110
001101101011011001000110111101100111001011
100110001101101111001011100111010101101011
http://slipperyhill.co.uk
Jul 15 '08 #43
Geoff Berrow wrote:
Message-ID: <12****************@proxy01.news.clara.netfrom The Natural
Philosopher contained the following:
>Now I also thought that the point was that the user was worried about
his clients seeing the info in the URL and messing with it.

Well that's easy enough to check.

From the OP:-
"I have a PHP script that does some processing, and stores an error
message as a variable. The script then redirects to another script
with the error string in the URL, with the second script displaying
the message and continues with the rest of the logic.

Now I want to hide the error message from the URL, but the second
script needs to continue working as is. How can I do this? I have
thought about md5'ing the message but the URLs still look messy. Any
other alternatives?"
--end quote
Precicely - no mention of third party security: merely wanting to hide
the info in the URL.

You started digging a hole when you suggested using the POST method and
clearly haven't stopped digging yet.
Post method perfectly valid in fact.

There are only three ways of preserving states across http sessions:
Post, Get and cookies.

>
To the OP.

Instead of sessions you could store all your error messages in an array
and then pass the array key in the URL
Script 2 then simply looks up the error message from the array.
Which is what php sessions do, if you don't use cookies.
Jul 15 '08 #44
..oO(The Natural Philosopher)
>Geoff Berrow wrote:
>You started digging a hole when you suggested using the POST method and
clearly haven't stopped digging yet.

Post method perfectly valid in fact.
Not really, as already mentioned at the beginning of the thread. A POST
can't automatically be redirected to another URL. And you surely don't
want to put every single page into a form and use submit buttons instead
of links ... or maybe you do.
>There are only three ways of preserving states across http sessions:
Post, Get and cookies.
POST - almost useless
GET - dangerous
COOKIE - recommended

But we're spinning in circles.

Micha
Jul 15 '08 #45
Michael Fesser wrote:
.oO(The Natural Philosopher)
>Geoff Berrow wrote:
>>You started digging a hole when you suggested using the POST method and
clearly haven't stopped digging yet.
Post method perfectly valid in fact.

Not really, as already mentioned at the beginning of the thread. A POST
can't automatically be redirected to another URL. And you surely don't
want to put every single page into a form and use submit buttons instead
of links ... or maybe you do.
if you use Javascript methods to SUBMIT, it looks and feel just the way
a standard link does.
>There are only three ways of preserving states across http sessions:
Post, Get and cookies.

POST - almost useless
GET - dangerous
COOKIE - recommended

But we're spinning in circles.

Micha
Jul 15 '08 #46
On Jul 12, 6:44*pm, choch...@gmail.com wrote:
Hi,

I have a PHP script that does some processing, and stores an error
message as a variable. The script then redirects to another script
with the error string in the URL, with the second script displaying
the message and continues with the rest of the logic.

Now I want to hide the error message from the URL, but the second
script needs to continue working as is. How can I do this? I have
thought about md5'ing the message but the URLs still look messy. Any
other alternatives?

The script works like this;
$err = "";
$res = process();
if ($res == 0)
{
*$err = "An error message";}

header("Location: script2.php?err=".urlencode($err));

Script2.php would display this message and continue with the rest of
the logic. Now I want to hide the Error message $err *from the URL
after a redirect. How do I do this?

Thanks in advance.
I feel that these might help:

http://us.php.net/manual/en/function.http-redirect.php
http://us.php.net/manual/en/function.http-post-data.php
http://us.php.net/manual/en/function...ost-fields.php

the main page:
http://us.php.net/manual/en/ref.http.php

But I don't know how to use it even if it really do the purpose or
not.
Actually I am beginner in php.
Jul 15 '08 #47
..oO(The Natural Philosopher)
>Michael Fesser wrote:
>Not really, as already mentioned at the beginning of the thread. A POST
can't automatically be redirected to another URL. And you surely don't
want to put every single page into a form and use submit buttons instead
of links ... or maybe you do.

if you use Javascript methods to SUBMIT, it looks and feel just the way
a standard link does.
Sure. Makes the pages perfectly inaccessible for many people, perhaps
even for search engines.

Micha
Jul 17 '08 #48

"Jerry Stuckle" <js*******@attglobal.netwrote in message
news:g5**********@registered.motzarella.org...
bu*************@gmail.com wrote:
>On Jul 14, 3:47 pm, The Natural Philosopher <a...@b.cwrote:
>>Michael Fesser wrote:
.oO(The Natural Philosopher)
I have no trouble understanding cookies and sessions.
Its jerry's assumptions that I didn't know that irritate.
All that is needed t preserve states across a session is to have some
unique session ID. That has to be carried by a cookie or by a URL .
After that, you can associate any amount of crap with that session ID.
I simply didn't see any difference in principle between carrying the
session ID as a URL than as a cookie.
There are a dozen ways for a URL to leak (the HTTP_REFERER is just one
way), which would easily allow other sites to grab valid session IDs.
Such attacks were done some years ago against a number of big free mail
services, which led to thousands of stolen accounts.
Session cookies are much more secure, because you actually have to
sniff
the HTTP communication between the clients and the server or use XSS to
grab them.
Which I pointed out. Jerry then said 'what's cookies got to do with
it'
so I explained what they had to do with it.
But they don't have anything to do with the OPs problem, which was
about
passing data from one page to another. POST won't work here, GET is not
wanted, so the only viable alternative is a session. Question answered.
No the only viable way is a cookie. Whether or not that is used with PHP
sessions or not, is actually not the point. They are no more secure than
simply setting a number in your own custom cookie.

All PHP sessions are area wasy of pasing a unique ID using cookies, and
a handy interface fr dummies, but they still use either the URL or the
cookie to pass that one vital bit of info.

Now I also thought that the point was that the user was worried about
his clients seeing the info in the URL and messing with it.

My point was that they could as easily mess with the cookies.

I don't recall any issues about security with respect to third parties
at all, which makes your point another straw man.

Micha- Hide quoted text -
- Show quoted text -- Hide quoted text -

- Show quoted text -

Okay, I'm beginning to see why some other group members are rather
frustrated with Natural Philosopher.

Using sessions only stores the ID associated with the user on the
client machine. That ID is linked to the client's data which is stored
on a file on the server the client is communicating with. Cookies
actually store all the data on the client machine. That means that
when you use cookies, all the data is available for the client to view
and edit. Using sessions seperates the client from his or her data,
thus making it uneditable; the only thing that can be edited on the
client is the session ID, which isn't very useful, since at best you
associate yourself with someone else's data, and at worse, you divorce
the client from its session data. Therefore, using sessions is more
secure because the client cannot directly access his or her data.

How did this even become a security discussion????

Ever since The Natural Philosopher made another stupid comment and I
called him on it.

Now he's doing his best to try to justify his stupidity.
It seems to me, Jerry, that Phil is making a point you are not catching. You
seem busy about all manner of things NOT related to what he is saying, yet
you are bashing him for what he IS saying. You haven't stopped to hear him.

You asked what cookies had to do with anything. He's saying that it's one
way for the PHP_SESSION_ID to be passed between the client and server. You
assume, inappropriately, that he means ALL SESSION DATA is passed around in
a cookie. You seemed to be a bit in a rush to 'call him on it'...even when
he clearly explained that was NOT what he meant. However, now that he has
painstakingly TRIED to clear up YOUR confusion, you keep playing the
champion...beating your chest, as it were, like a juvenile gorilla afraid of
a real confrontation, hoping all the arm-waving comotion will scare off your
'rival' before he notices it's all a front.

He's only talking about passing the session ID. Nothing more than that,
Jerry. Since you were the one who was pondering how cookies fit into
sessions, I fail to see how you could possibly a good argument...since yours
would seemingly be made from ignorance. Further, after all of your raging
tantrums in a know-it-all fashion, it seems you have projection issues as
all fingers should be pointing to your own lack of reading
comprehension...or your willingness to only give others' remarks cursory
scans. Obviously, the latter is quite dangerous as it can lead to the
offender looking a fool.

Consider yourself, 'called on it'.

Someone needs to grow up. And if he can't read that, maybe he'll catch his
name...JERRY.
Jul 18 '08 #49
Ah, joining a flame war...nothing quite like it.

Jerry might be a dick from time to time, but his participation and
helpfulness to the PHP groups is unprecedented. On days I lurk he has
questions answered before I even can write a response.

To top that I've actually seen messages where he admits he's wrong;
the last thing he's doing here is stroking his e-peen.

=======

From what I've seen, he's becoming a 'dick' more and more as of late. I've
only seen him admit he was wrong ONCE...and that was after beating him to
death with the facts until he had to say something. He was going to let it
slide.

He may have copious replies, but even though quantity may have a quality all
it's own it hardly matters to an individual looking for a single quality
response. I've seen Jerry wrong almost as often as I've seen him be right.

He also seems to relish being confronted. You can tell when Jerry is wrong
when he plonks people that kindly disagree with him - all the while Jerry is
cursing and throwing insults. That is a very common occurance. He loves to
claim 'troll' or 'stoopid'. Yes, there's some mighty big stroking going on
there.

What I truly wonder is how Jerry can afford to post here 24/7/365? He
obviously is NOT employed, or, is waisting his employer's time and money.
That, or he's loaded...and not just with booze and pills. :)
Jul 18 '08 #50

This discussion thread is closed

Replies have been disabled for this discussion.

By using this site, you agree to our Privacy Policy and Terms of Use.