On Mon, Oct 13, 2008 at 3:09 AM, Per Jessen <[EMAIL PROTECTED]> wrote: > Ashley Sheridan wrote: > >> You should look at developing the app so that it doesn't rely on >> referrer information, as this is unpredictable as you've seen. > > Yep, that's what I did too. Can't remember exactly what I did, but I > suspect it involved setting info in the session, > >> Not just with IE as well, because some proxy servers have been known >> to strip out this information, and individual users can turn this off >> if they know how. > > That is/was not a concern in my case. > >> What are you doing with it? Maybe there's another solution to the >> problem. > > My problem was that I needed to use the HTTP_REFERER as the URL in a 303 > redirect after a POST. From page 1 (list of items), the user would > click on an item and the new url would be set through javascript. On > page 2 (item detail), the user would then POST some action, after which > he should be returned to the original list at the same place. (The > list is a window of e.g. 500 items from a list of several thousands). > > Anyway, I don't know what the OPs was trying do with HTTP_REFERER. > > > /Per Jessen, Zürich > > > -- > PHP General Mailing List (http://www.php.net/) > To unsubscribe, visit: http://www.php.net/unsub.php > >
I don't bother with the referer at all. Whenever I've needed this information I either: 1) store it in the session 2) store it in the url as a ?continue=url Lately I've been having to build a lot of different ways of getting to the same edit form. So to get the user back to where they came from this previous url is quite important. Also it's imperative to validate that the $_GET['url'] is a url that your system can handle though. http://www.owasp.org/index.php/Open_redirect
