Re: Hiding variables passed via URL

Peter D. wrote:
On Jul 14, 1:18 pm, The Natural Philosopher <a...@xxx> 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.

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.





.

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. ... What else constitutes a 'session variable' apart from POST or GET data ... 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)