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" <[EMAIL PROTECTED]> wrote in message
[EMAIL PROTECTED]">news:[EMAIL PROTECTED]...
> --- Scott Fletcher <[EMAIL PROTECTED]> 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



-- 
PHP General Mailing List (http://www.php.net/)
To unsubscribe, visit: http://www.php.net/unsub.php

Reply via email to