Kusss
Если все будет происходить в таком порядке как было описано "зашел на сайт - пошарился там, пришел на регистрацию - зарегился", то на странице регистрации, через глобальную переменную "Сервер", будет "предыдущий" урл...
А что бы "при регистрации нужно записать, откуда из вне пришел юзер", я бы сделал навскидку, так:
При посещении index`а, проверял бы уникальную, свою, куку...
1) если есть, то - спокойствие...
2) если нет, записал урл( кому куда нравится ) откуда пришел пассажир и поставил куку.
Полная Версия: После авторизации возвращаем пользователя
Вообще как ты собираешься запоминать откуда пришел человек?
Через $_SERVER['HTTP_REFERER'], да это не то, его и подделать можно, да и если к примеру юсер с закладок пришел, что перенаправишь на ту же страницу? Какая то глупость, а не задача...
Авторизировался юсер, так и к примеру покащывай личный кабинет, если нет его так покажи то что при авторизации. Зачем мозг мучять себе и еще и юсеру
Через $_SERVER['HTTP_REFERER'], да это не то, его и подделать можно, да и если к примеру юсер с закладок пришел, что перенаправишь на ту же страницу? Какая то глупость, а не задача...
Авторизировался юсер, так и к примеру покащывай личный кабинет, если нет его так покажи то что при авторизации. Зачем мозг мучять себе и еще и юсеру
walerus
все верно ... нужно кудато-то писать при первом заходе. Я уточнял про это
все верно ... нужно кудато-то писать при первом заходе. Я уточнял про это
| Цитата (depp @ 22.11.2016 - 18:36) |
| по моему все можно сделать без сессий и кук, обыграв на обычном js. через ajax запрос и метод location. |
| Цитата (walerus @ 23.11.2016 - 01:55) |
| dimka.2016 - depp Дело говорит, что мешает на JQuery сделать регистрацию в модальном окне? что бы не париться с редиректами... |
Хотелось проще. Сессии как то привычней
Нашел самый простой способ (для чайников)
Сделал для каждой странички, где требуется пароль входа,2 файла регистрации, после успешной проверки юзер возвращается на нужную страничку
Сделал для каждой странички, где требуется пароль входа,2 файла регистрации, после успешной проверки юзер возвращается на нужную страничку
Над модальные окнами можно поработать. Быстро качественно и красиво
<a href="/login?ret_path=<?= htmlspecialchars(getenv('REQUEST_URI')) ?>">Войти</a>
Верно, только у исходного адреса может быть своя строка параметров, поэтому лучше так:
Тут пример: Как сделать авторизацию пользователя?
/login<?= $_SERVER['REQUEST_URI'] ?>
Тут пример: Как сделать авторизацию пользователя?
| Цитата (miketomlin @ 1.12.2016 - 03:11) |
| Верно, только у исходного адреса может быть своя строка параметров, поэтому лучше так: |
чем лучше?
Найди десять отличий Все пользовательские данные выводимые в поток, должны обрабатываться ВСЕГДА!
От XSS в твоём примере спасает только автоматическое кодирование урл в современных браузерах. Полагаться в безопасности на наличие защиты в клиентском софте не правильно, всегда остаётся потенциальная вероятность, баг в какой нибудь версии браузера, который в купе с твоим дырявым кодом породит уязвимость.
| Цитата (killer8080 @ 1.12.2016 - 10:02) |
| Все пользовательские данные выводимые в поток, должны обрабатываться ВСЕГДА! От XSS в твоём примере спасает только автоматическое кодирование урл в современных браузерах. Полагаться в безопасности на наличие защиты в клиентском софте не правильно, всегда остаётся потенциальная вероятность, баг в какой нибудь версии браузера, который в купе с твоим дырявым кодом породит уязвимость. |
Хотел я про это написать, но не стал, т.к. суть не в этом.
Что касается моего примера, вы видимо не подумали, когда писали, что входящий адрес может где-то заранее однократно фильтроваться, а не кодироваться при каждом чихе.
Что касается моего примера, вы видимо не подумали, когда писали, что входящий адрес может где-то заранее однократно фильтроваться, а не кодироваться при каждом чихе.
Пруф, если на слово не верите: g09.ru/my/<"&">
miketomlin
| Цитата (miketomlin @ 1.12.2016 - 03:11) |
| Верно, только у исходного адреса может быть своя строка параметров, поэтому лучше так: /login<?= $_SERVER['REQUEST_URI'] ?> |
я так и не увидел обоснования, в чем принципиальное улучшение, по сравнению с
| Цитата (killer8080 @ 28.11.2016 - 15:32) |
| login?ret_path=<?= htmlspecialchars(getenv('REQUEST_URI')) |
собственно вопрос был в этом
| Цитата (miketomlin @ 1.12.2016 - 17:47) |
| Что касается моего примера, вы видимо не подумали, когда писали, что входящий адрес может где-то заранее однократно фильтроваться, а не кодироваться при каждом чихе. |
$_SERVER['REQUEST_URI'] это суперглобальная переменная, строка в ней в сыром виде, как есть, из заголовка запроса. Конечно я не думал, что ты её где то фильтруешь, входные данные неприкосновенны, с ними нужно работать в режиме read only. Только за помыслы их модифицировать нужно бить больно по рукам
| Цитата (miketomlin @ 1.12.2016 - 17:54) |
| Пруф, если на слово не верите: g09.ru/my/<"&"> |
пруф чего? Стесьняюсь спросить
Я же сразу объяснил, почему лучше. Если бы там была своя строка параметров, а тут своя, уже пойдет перетекание части GET-параметров в тек. страницу. Эстетика у адреса с двумя ? тоже еще та.
Под фильтрацией я подразумевал недопуск адреса, содержащего недопустимые символы, для штатной обработки. Можно назвать это валидацией, если так понятнее.
Насчет пруфа это да, мой косяк. Там фильтр работает централизованно. К тому же чтобы хотя бы попытаться увидеть некорректную ссылку, нужно пройти авторизацию. Суть в том, что запрос по адресу, содержащему некорректные символы, не будет отрабатываться штатным образом, а вместо этого будет отображена страница 404-ой ошибке. Конечно, если на странице ошибки использовать показанную мной ссылку, то верстка может поломаться при использовании адреса с некорректными символами, однако для существующих страниц это невозможно.
Более наглядным будет этот пример: g09.ru/gency-demo/<"&"> (если в последней части пути написать корректные символы, то будет отображаться страница со значением REQUEST_URI в незакодированном виде – несмотря на это «поломать» страницу сложно, т.к. адрес предварительно проверяется на предмет наличия в нем «недопустимых» символов). Надеюсь, объяснил. В преть, пожалуйста, будьте не столь агрессивны
Под фильтрацией я подразумевал недопуск адреса, содержащего недопустимые символы, для штатной обработки. Можно назвать это валидацией, если так понятнее.
Насчет пруфа это да, мой косяк. Там фильтр работает централизованно. К тому же чтобы хотя бы попытаться увидеть некорректную ссылку, нужно пройти авторизацию. Суть в том, что запрос по адресу, содержащему некорректные символы, не будет отрабатываться штатным образом, а вместо этого будет отображена страница 404-ой ошибке. Конечно, если на странице ошибки использовать показанную мной ссылку, то верстка может поломаться при использовании адреса с некорректными символами, однако для существующих страниц это невозможно.
Более наглядным будет этот пример: g09.ru/gency-demo/<"&"> (если в последней части пути написать корректные символы, то будет отображаться страница со значением REQUEST_URI в незакодированном виде – несмотря на это «поломать» страницу сложно, т.к. адрес предварительно проверяется на предмет наличия в нем «недопустимых» символов). Надеюсь, объяснил. В преть, пожалуйста, будьте не столь агрессивны
| Цитата (Guest @ 4.12.2016 - 21:40) |
| Я же сразу объяснил, почему лучше. Если бы там была своя строка параметров, а тут своя, уже пойдет перетекание части GET-параметров в тек. страницу. |
тут ты прав, чтоб не потерять все гет параметры исходного урл, нужно кодировать через urlencode
<a href="/login?ret_path=<?= urlencode($_SERVER['REQUEST_URI']) ?>">link</a>
| Цитата (Guest @ 4.12.2016 - 21:40) |
| Под фильтрацией я подразумевал недопуск адреса, содержащего недопустимые символы, для штатной обработки. Можно назвать это валидацией, если так понятнее. |
в показанном коде ничего этого нет
| Цитата (Guest @ 4.12.2016 - 21:40) |
| Насчет пруфа это да, мой косяк. |
да причем тут пруф? Код нужно показывать открыто, на форуме, то что там где то у тебя что то фильтруется я не сомневаюсь, но дав совет ты об этом нигде не упомянул, в товем коде не было никакой фильтрации
То что это не создало уязвимости, это лишь особенность поведения браузера в данном случае, но на это нельзя полагаться. Я всего лишь это пытался донести.| Цитата (Guest @ 4.12.2016 - 21:40) |
| Надеюсь, объяснил. В преть, пожалуйста, будьте не столь агрессивны |
В преть пожалуйста не принимайте критику за агрессию
нельзя быть таким ранимым в нашем мире
Здесь расположена полная версия этой страницы.