Есть сайт, на нем страницы одни общие для всех, другие только для авторизированных.
Можно, после авторизировации юзера присвоить ему обычную переменную, скажем $_SESSION['ok']='' и дальше на запретных страница проверять есть она или нет т.е. пускать не пускать.
Можно, каждый раз на странице сверять его логин и хэш пароля с БД. Или даже на index проводить 'ne сверку при условии что сессия логина существует и дальше создавать обычную переменную или константу.
У меня второй вариант, но он снижает производительность.
В связи два вопроса:
1. Насколько безопасно, создавать переменную $_SESSION['ok'] и осуществлять проверку только на ее наличие?
2. При генерации на главной index.php обычных переменных и констант можно ли разрешать работу без проверки на их существование в инклюд'иемых файлах?
Спустя 1 час, 21 минута, 2 секунды (13.03.2012 - 14:57) NitroGenerate написал(а):
на счет 1.
задам встречный вопрос, а на сколько безопасно хранить в куках логин и хеш пароля ?
По моему это одно и тоже. Даже более того, используя данные сессии, мы меньше захламляем куки, А стащить можно одинакового, что PHPSESSID, что логин с хешем.
Для большей защиты, можно еще в сессию сразу после ввода верного логина и пароля закинуть, ip пользователя, а дальше сверять постоянно ip сессии и текущий ip пользователя.
Но это уже проверка постоянная.
задам встречный вопрос, а на сколько безопасно хранить в куках логин и хеш пароля ?
По моему это одно и тоже. Даже более того, используя данные сессии, мы меньше захламляем куки, А стащить можно одинакового, что PHPSESSID, что логин с хешем.
Для большей защиты, можно еще в сессию сразу после ввода верного логина и пароля закинуть, ip пользователя, а дальше сверять постоянно ip сессии и текущий ip пользователя.
Но это уже проверка постоянная.
Спустя 12 часов, 12 минут, 4 секунды (14.03.2012 - 03:09) Президент! написал(а):
A.B.C. задавая вопрос ты сам на него отвечаешь, что-то не совсем ясно что ты хочешь добиться?
по мне сесси более безопастны нежели куки. потому что ты их создаешь непосредственно на нужной странице и жизнь сессий определяешь, либо сам, либо настройкой сервера, возможны ещё варианты, это тонкости уже
я так и делаю запихиваю в сессионную переменную и проверяю если юзер не в сессию не допускаю, если в сессии, значит допуск на страницу есть
как пример: уничтожение и переброска на регу если нет в сессии переменной
по мне сесси более безопастны нежели куки. потому что ты их создаешь непосредственно на нужной странице и жизнь сессий определяешь, либо сам, либо настройкой сервера, возможны ещё варианты, это тонкости уже
я так и делаю запихиваю в сессионную переменную и проверяю если юзер не в сессию не допускаю, если в сессии, значит допуск на страницу есть
как пример: уничтожение и переброска на регу если нет в сессии переменной
<?php session_start();
unset($_SESSION['login']);
session_destroy();
//переброска на страницу реги
header("Location:http://(..домен или путь..)/index.php");
Спустя 1 час, 15 минут, 35 секунд (14.03.2012 - 04:24) GET написал(а):
Президент!
прочитал на хакерском форуме, что они узнают каталог где хранятся сессии, а они помимо tmp типовые для хостеров и угоняют оттуда их, чтоб потом свободно скрипты сайта инклюдить.
прочитал на хакерском форуме, что они узнают каталог где хранятся сессии, а они помимо tmp типовые для хостеров и угоняют оттуда их, чтоб потом свободно скрипты сайта инклюдить.
Спустя 1 час, 52 минуты, 59 секунд (14.03.2012 - 06:17) Игорь_Vasinsky написал(а):
да хз.
Еслу хулиганы доберутся до директории с сессиями, если они уже там - то как не защищайся.
я имею ввиду - то чё они сразу в твою директорию не побегут то7
волков бояться в лес не ходить.
Еслу хулиганы доберутся до директории с сессиями, если они уже там - то как не защищайся.
я имею ввиду - то чё они сразу в твою директорию не побегут то7
волков бояться в лес не ходить.
_____________
Не тот велик, кто не падал, а тот кто падал и поднимался.