можно подробнее? информация консультативная, для удобства пользователя, никакой авторизации на этом поле не завязано.
пусть поле будет подделано, если проверять содержимое по каким-то параметром(принадлежность домену, и т.д..) чем это грозит? или может грозить?
P.S. Началось с темы Кнопка "Назад", оптимальный алгоритм

Не вижу ничего страшного в использовании HTTP_REFERER. Но, если логически подумать, его нужно использовать при условии что источник, откуда пришел пользователь, может быть какой угодно и нам неизвестный. Если все идет с нашего сайта, добавляем к URL формы ?return_url=/return/url/.

Добавлено через 2 минуты и 18 секунд
Кстати, если речь все же идет о проверке валидности пользователя, тогда мне становится не совсем ясно с какого боку сюда прибился HTTP_REFERER?

Ушел читать тему по ссылке...

естественно, интересуют глобальные аспекты, но и вопрос, затронутый  в  указанной теме: по заявлению Feldmarschall'a, HTTP_REFFERER использовать нельзя. категорически. вот я и поинтересовался, с чем может быть связана такая категоричность.

skyboy, я понял его слова несколько иначе - имеется ввиду, строить логику выполнения на основании HTTP_REFERER (мне так показалось). А вообще, сессия решает все проблемы, поэтому я не вижу необходимости в использовании проверок по REFERRER'у.

Нужно иметь ввиду что: 
1. REFERRER может быть подделан.
2. REFERRER может придти пустым.
3. REFERRER может служить в качестве обратной ссылки после выполнения некоего действия, в случае отсутствия которого нужно подставлять default location.

Если у некоторого количества пользователей программа работать не будет, то, по моему мнению, такой программой пользоваться нельзя.
Ну вот к примеру скачал пользователь калькулятор. Нажимает 2+2, а в поле результата - пусто. У троих было нормально, а у четвертого - не считает. Я считаю, что такие программы писать нельзя. 
Сайт, который не работает - это позор и отток посетителей. Проблемы, которые случаются при работе любых сайтов, исправляются как можно раньше. Это, я надеюсь, аксиома, которую доказывать не нужно. Но проблему с отсутствующим реферером решить в принципе невозможно. То есть, использовать реферер - это намеренно делать неработающим сайт. Я считаю такой подход невозможным.

Добавлено через 1 минуту и 27 секунд
IZ@TOP, да, совершенно верно. Речь идет не о реферере вообще, а об использовании в логике приложения.

IZ@TOP, спасибо. я думал, я что-то по рассеянности упустил.
Feldmarschall, спасибо. хотя, хотелось бы узнать, сталкивался ли ты со случаем "неотдачи" реферрера от более-менее популярного сейчас браузера. 
а то ведь человек может и куки почистить внезапно("delete private information") и сессия внезапно окажется пустой - и тут ничего не поделать...

skyboy, да, разумеется.

с другой стороны, с использованием сессий есть проблема.
проблема, связанная с тем, что сессия одна. 
например, пусть у нас страница, с которой надо "вернуться назад" - это форма авторизации на... скажем, torrent-трекере.
вот пооткрывал человек кучу тем в разных закладках(сессий браузера одна). потом вдруг обнаруживает, что для скачивания нужна авторизация(получил на всех страницах форму авторизации). в сессии адресом возврата значится последняя открытая страница.
значит, после авторизации он на всех закладках попадет на последнюю открытую страницу. логично, с точки зрения работы механизма сессий, но нелогично с точки зрения пользователя.
потому, как мне думается, тут использование refferer'a вполне оправдано, а уж если в этом поле будет пусто... что ж, пользователь, возможно, получит проблемы(впрочем, можно вывести его на главную страницу).
универсально работающий метод(к примеру, передавать скрипту, формирующему авторизацию, параметром адрес, с которого был сделан переход) будет довольно-таки трудоемким, как я считаю. т.е. ссылки, передающие адрес, с которого осуществлен переход - это, конечно, универсально, но громоздко и некрасиво.

Я тут подумал, что файрволл Аутпост может быть не так туп, как мне представлялось ранее, а рубит реферер только при переходах между сайтами. Если же домен в реферере и хосте совпадает, то не рубит. Надо проверить эту мысль.
Впрочем, остаются ещё всякие акселераторы, которые в большом ходу у провайдеров.

Описанная ситуация представляется мне надуманной. Я могу представить себе пользователя трекера, который открывает раздачи в новом окне из поиска. Но представить себе его же, но жмущего "скачать" и тут же, не глядя на результат, идущего в следующее окно, жать то же самое - не могу.
Как по мне - так я форму авторизации выдаю прямо на той странице, которая была запрошена. то есть, ничего запоминать вообще не надо.
И в большинстве известных мне сайтов делается то же самое. То есть, сессия не нужна вообще, получается, для этих целей.

В таком случае, прерывание выполнения программы должно произойти до выполнения запрашиваемого действия. 

пожалуй, есть такое дело.

пример из собственного опыта. или я туп, или интернет у меня не так уж и быстр...

По-моему суть всей дискусси сводится к тому что, реферер может быть пуст и что он может быть подделан а тут уже 10 постов интерпретации каждым этих двух фактов )

Реализуй в сессии массив адресов возврата


Передавай вместо урл - UID.

Куда возвращаться будеш вытаскивать из этого стека по UID.
Если ты сам себе злобный буратино и откроешь 10к авторизаций с одной и той же страницы, то после авторизации на любой из них, ты все равно вернешься на исходную.

Единственное усложнение - я бы предусмотрел сборщик мусора по массиву. Т.е. ссылки по которым произошел уже возврат - должны чиститься.

Это сообщение отредактировал(а) Fortop - 22.4.2008, 14:06

Чего-то вы по-моему мудрите...

flashaa, нет, речь не совсем об этом.
Речь о том, насколько эти два факта распространены, и следует ли их учитывать при разработке сайта.

Что именно непонятно?

Был вопрос - как реализовать возврат для одновременно открытых страниц в рамках одной сессии.
Ответ - Хранишь не просто url для возврата, а массив таких url, для каждой открытой страницы - своя запись.

Fortop, вот только это придется в сессию писать каждую страницу, которую открывал юзер. 
и плюс - передавать по ссылке уид из сессии. поменяли шило на мыло =)

чесно говоря, я вообще о таком только от тебя здесь услышал :( не думал, что файрволл занимается изменением данных. доступом -- да, но данные...   
собственно, ради выяснения вот таких вот моментов и начал тему.

вот-вот. единственно - идентификатор сессии обычно в coockie лежит и, по крайней мере, юзеру глаза не мозолит. 

так точно. спасибо за понимание.

Естественно.
Но в этом и плюс, ты для любой страницы сможешь восстановить весь путь, по которому туда пришел пользователь.
И соответственно возврат возможен на любой уровень глубины.


Не проникся.

UID будет много короче реального пути возврата в виде URL, особенно если погуляешь до страницы не сразу, а через несколько других.


UID предлагался для замены списка URL, но никак не сессии.

Вместо



Использовать вот такое



И ничего более 

Блин, сменили тему, я в прошлой отписал ту же мысль со стеком в сессии :(

По-моему самый правильный вариант: не карячит URL, не зависит от каких-либо настроек на стороне пользователя.

// p.s. сполз под стол уидев описание темы. Такого девайса я себе не мог представить!

Это сообщение отредактировал(а) SamDark - 22.4.2008, 19:08

Блин, ребята? Чего вы тут городите? Используйте ?return_url=/return/url/ и не пилите мозг себе и другим людям. В обоснование своих слов - скажу только, что, все более-менее крупные проекты, используют именно такой подход (кроме особо сложных случаев, которые сейчас не рассматриваются). Какие именно? Двух думаю будет достаточно: mail.ru, photofile.ru. К чему усложнять код?
Пришел с return_url, после выполнения действия отправился обратно, без - пошел на дефолтный урл (на главную, к примеру).



Такое может получиться только если руки растут из ж*ы.

Это сообщение отредактировал(а) IZ@TOP - 24.4.2008, 16:32

IZ@TOP, читаем внимательно, и соседнюю тему тоже