Re: Hiding variables passed via URL

burgermeister01@xxxxxxxxx wrote:
On Jul 14, 2:27 pm, Jerry Stuckle <jstuck...@xxxxxxxxxxxxx> wrote:
The Natural Philosopher wrote:
Jerry Stuckle wrote:
burgermeiste...@xxxxxxxxx wrote:
On Jul 14, 6:19 am, Jerry Stuckle <jstuck...@xxxxxxxxxxxxx> wrote:
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...@xxx> wrote:
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...@xxxxxxxxxxxxx
==================- 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...@xxxxxxxxxxxxx
==================- 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.





.

Relevant Pages

  • Re: Hiding variables passed via URL
    ... Jerry Stuckle wrote: ... well you can view cookies as well. ... But then you don't understand that session variables aren't POST or GET ... You could coordinate PHP with Javascript. ...
    (comp.lang.php)
  • Re: Hiding variables passed via URL
    ... well you can view cookies as well. ... But then you don't understand that session variables aren't POST or GET ... Jerry Stuckle ... You could coordinate PHP with Javascript. ...
    (comp.lang.php)
  • Re: Hiding variables passed via URL
    ... Automatically redirecting anything other than ... well you can view cookies as well. ... But then you don't understand that session variables aren't POST or GET ... You could coordinate PHP with Javascript. ...
    (comp.lang.php)
  • Re: PHP sessions and disabled cookies
    ... Cookies are blocked in my ... I do not see the URL containing the session ID. ... [PHP] ... A warning appears if the specified function is not defined, ...
    (php.general)
  • Re: $_SESSION problem - page reload creates new Session ID
    ... > Web Server IIS (is local and there are no links to other servers from ... > The problem I am having is that each time I reload the same PHP page, ... > I did not know what is happening and when printing out the session id ... Cookies are invisible when the domain changes (or even path in the same ...
    (comp.lang.php)