Re: HTTP_REFERER work without a problem....
| From: | Scott Fletcher | Date: | Wed, 15 Jan 2003 21:36:31 +0000 |
| Subject: | Re: HTTP_REFERER work without a problem.... | ||
| References: | 1 2 | Groups: | php.general |
| Request: | Send a blank email to php-general+get-131765@lists.php.net to get a copy of this message | ||
I agree with you on that. Having something that is reliable is not a bad
idea. Anyway, this HTTP_REFERER script have been in use for 4 years and we
sometime very little have problem with it. It the HTTP_REFERER doesn't work
then all the user will experienced is a direct access attempt and be brought
to the login page, it's part of the fail-safe code. I haven't come up with
an alternative to HTTP_REFERER that work even better than this. So, better
safe than sorry. :-)
"Chris Shiflett" <shiflett@php.net> wrote in message
news:20030115212721.66116.qmail@web14311.mail.yahoo.com...
> --- Scott Fletcher <scott@abcoa.com> wrote:
> > Many PHP programmer tried to their best to use
> > HTTP_REFERER so they can keep track of which
> > webpages on the current website did the user
> > last visited.
>
> I think I see what you are referring to now.
>
> The reason that many people (myself included) discourage
> the use of REFERER for this purpose is not only because
> support is inconsistent, but also because it is not
> required that a Web client send this header. In fact, the
> only required header in the latest version of HTTP (1.1) is
> the Host header. So, it really boils down to not depending
> on something that is not guaranteed to be there.
>
> More reliable solutions usually incorporate some sort of
> shared secret between the client and the server. For
> example, say you have a form located at foo.php that
> submits to bar.php. Rather than checking the REFERER on
> bar.php to make sure it is foo.php, it is better to include
> a hidden form field on foo.php that is dynamically
> generated and stored in the user's session. You can be
> assured that the hidden form field will be included with
> the other form elements, so you can compare it to the value
> stored in the user's session and not run the risk of it
> being absent or blank (for the legitimate user, the good
> guy).
>
> Of course, this is just one example of many, but the point
> is that you need to rely on something that is reliable. :-)
>
> Chris