Авторизация по сессии

Здрасте, можно ли сделать так что бы при авторизации 2 человек на одном акк одного из них выкидывало.

Тип авторизации: сессии

Для этого нужно различать клиентов.
Самое простое - если они имеют разный REMOTE_ADDR. Тогда достаточно записать адрес входа в сессионную переменную и при запуске страницы помимо наличия авторизации в сессии проверять, совпадает ли адрес с тем, что есть в сессии. И если нет совпадения - то не давать зайти в систему. Это - реализация схемы "вход только один и с одного IP"
Если же IP-адреса одинаковые, то здесь уже 100% гарантии не будет, так как придется устанавливать куки (с функционалом, аналогичным тому, что я описал), которые доступны клиенту - и, значит, он может их стереть/изменить.

-----
Есть в мире две бесконечные вещи - это Вселенная и человеческая глупость. Но насчет первой .. я не уверен.

Зачем же так резко??
Логика проста,если мы НЕ можем записать куки или же ип у пользователей одинаковый то достаточно сделать следующее.
1 При авторизации через форму пользователю вместо пароля подсовывать хеш,который состоит из набора букв,символов и цифр и состоит минимум из 16-25 символов(подбор хеша невозможен,так как слишком длинное значение)
2 Далее,сверять например логин и хеш по базе и если все норм то пользователь авторизован.
3 Если появится второй пользователь под данной учеткой(войдет через форму авторизации) то хеш полюбому изменится,и следовательно предыдущегго выкинет с авторизации.
Вот и вся логика.И тут совершенно без разницы,что за браузер,какои ип и так далее.
Ps Другой вопрос если авторизация идет по Кукам,но тогда тут вина не сис админа сайта,а только пользователя,ибо 99 процентов сайта используют именно этот тип авторизации,и хранят данные логин пароль у пользователя.
Что касается ip то не стоит забывать что у большей части пользователей он динамичный.

(Отредактировано автором: 23 Июня, 2012 - 17:49:35)

Если это злоумышленник, то ему не составит труда посмотреть при первом логине свой хеш и подставить его затем в форму при втором, таким образом становясь для системы "правильным" пользователем.
Все, что отдается клиенту - не может быть доверенной информацией.

-----
Есть в мире две бесконечные вещи - это Вселенная и человеческая глупость. Но насчет первой .. я не уверен.

C чего Вы взяли что это поможет? При входе у пользователя 1 hash(session_id) а при каждом заходе нужно просто менять этот session_id. И тогда каждый 2 пользователь вошедший "выбьет" из системы 1 - го пользователя так как session_id уже измениться

-----
Так было, так есть и так будет

И что же?
0. Сессионные переменные хранятся на сервере.
1. Доступ к сессии со стороны клиента - некоторый идентификатор (id сессии) - хранится в куках, или передается при каждом запросе.
2. Если Вы планируете контролировать что-либо, передавая на клиент, он это увидит
3. Просто скопировав с компьютера, где сделан первый вход, на второй, свой идентификатор и все "контролирующие" куки/хеши и т.п. - пользователь получит доступ и данные к своей же сессии (и это правильно - это же его сессия), так как - id сессии будет корректен, а хеш, как бы он ни проверялся, придет равный тому, что был в первом случае. Иными словами, пользователь даже не будет пользоваться формой входа - ему незачем, ведь у него есть для того все данные.

-----
Есть в мире две бесконечные вещи - это Вселенная и человеческая глупость. Но насчет первой .. я не уверен.

Вы хотите сказать что 1 пользователь на 2 компах зайдет под одной и той же session_id? или я Вас не правильно понял

-----
Так было, так есть и так будет

И снова вы меня не поняли или не хотите понимать.
Смотрите,вы сами сказали что сесии хранятся на стороне сервера,у пользователя ТОЛЬКО ее индентификатор,то есть берем такую логику авторизации.
1 Пользователь вводит логин и пароль в форму авторизации.
2 Идет сверка логина пароля по базе данных.
3 Если все удачно то пользователю присваиваем 2 индентификатора сесии ,например session['id'] и session['hach'] где hach это случайно сгенерированная строка, а id это пользовательский ид.
4 При серфинге пользователя по сайту сверяем эти самые индентификатры по базе и если они есть то пользователь авторизован,если нет то уничтожаем индентификаторы и даем пользователю знать что он гость.
5 Если под одним и тем же логином(ид) зайдут 2 пользователя то одного(кто раньше авторизовался) просто выкинет как гостя вот и все.
А что касается подмены и так далее,то если злоумышленник получил доступ к пользовательским данным то тут НИКАКАЯ защита не поможет,ибо тот же злоумышленник сможет узнать пароль(при вводе его пользователем)
(Добавление)

И еще маленький нюанс,как известно сессии по умолчанию живут 24 минуты,следовательно,если пользователь не был на сайте 1 час то как бы злоумышленник не смог получить те данные сесии то все равно он не сможет ими уже воспользоваться.
А для пользователя чтоб авторизоваться необходимо просто ввести снова логин пароль вот и все!
Зы,что касается привязки к ип то вот как раз тут наиболее вероятность воровства,не забывайте что та же опера мини имеет 1 ип на всех.
И у многих,в большинстве,ип динамичный.

(Отредактировано автором: 23 Июня, 2012 - 17:54:08)

Ну это тоже самое, только я не вижу смысла хранить это в БД если тока сами сессии там не хранятся..
Можно пользоваться только идентификатором session_id как hash'ом и проверять на наличие этого файла в папках tmp сервера(директория хранения сессий)

-----
Так было, так есть и так будет

[quote=vanicon][/quote]
Не,тут расматривается случай разлогивания одног8о пользователя,если ктото другой вошел под тем же логином.
Я например делаю так,при авторизации пишу в куки логин и хеш,который естественно уже живет именно столько сколько я выставлю.
Возможность своровать куки,это либо дрявый браузер у пользователя,или же кто то получил доступ к кешу браузера дабы вытащить куки.
Ну а про криворукость админа сайта (возможность вставки ява скрипта для воровства кук) это совсем отдельный холивар.

Local
Что-то у Вас тон нездоровый, давайте спокойную дискуссию вести. Не знаю, с чего Вы взяли, что я был где-то резок. Не имею такой привычки.
Начнем с Вашего предложения о записи в $_SESSION некоторого хеша.

Где он будет храниться? Ответ - на сервере.
Как к нему получить доступ в сессии? Ответ - по идентификатору сессии
Где хранится идентификатор-ключ к сессии? Ответ - на клиенте.

Поэтому я до сих пор не понимаю предложенного Вами механизма. Он все равно опирается на то, что передает клиент. Если же имеется ввиду создание чего-либо на стороне клиента, что должно его идентифицировать - то тогда подделать можно указанным мной способом.

vanicon
Если Вы авторизуетесь на ресурсе (через сессии), затем скопируете идентификационный куки на любую другую машину, то Вы получите доступ к сессии и будете авторизованным при условии, что на первой машине не был выполнен выход из сессии. Это очевидное свойство вытекает из устройства самих сессий.

Предлагаю всем - прежде чем спорить - пожалуйста, освежите некоторые тонкости о сессиях в памяти, нет в этом ничего зазорного. При той механике, которая там существует, без некоторого трудно подделываемого признака со стороны клиента (ip-адрес, к примеру) - нельзя однозначно идентифицировать его внутри сессии. Любые же дополнительные ухищрения с куками/дополнительными данными в сессии можно обойти указанным выше способом.

По поводу времени жизни сессии - это в контексте топика темы имеет очень маленькое значение, ведь задача запретить двойную авторизацию.

-----
Есть в мире две бесконечные вещи - это Вселенная и человеческая глупость. Но насчет первой .. я не уверен.

[quote=EuGen][/quote]
Все гораздо проще.
Вы внимательнее читайте мой пост.
Сам хеш,хранится в базе(записывается или обновляется при каждой авторизации)
Далее этот кеш даем клиенту,например записываем его в куки браузера.
Этот хеш будет служить что то типа временного пароля.
Что касаемо кук и их воровства,то тут уже проблемма не админа сайта,а пользователя.

Local
Вы, вероятно, некорректно поняли задачу. Пользователь намеренно пытается дважды авторизоваться. И у него есть все свои данные - и куки и что-либо еще, ведь это его сессия.
Если Вы будете хранить что-либо в БД, то это ровно то же самое, что хранить на сервере. Эти данные - некоторое хранилище, к которому нужен ключ в виде идентификатора сессии, хранящегося на клиенте. И ключ этот пользователь может просто скопировать. Ровно как и Ваш хеш, который по Вашим словам, Вы передаете клиенту в виде куки.
Не понимаю, что здесь трудного - осознать, имею ввиду - что это не приведет к желаемому результату.

-----
Есть в мире две бесконечные вещи - это Вселенная и человеческая глупость. Но насчет первой .. я не уверен.

Я понял Вас, но как другой пользователь узнает этот session_id кроме как кража куков и взлом компа этого пользователя, ну а от этого никто не застрахован. А то что тот кто вошел скопирует эту session_id в другой браузер и войдет, то ничего страшного ведь это все ровно 1 и тот же пользователь.
Поясните если что-то не так...

-----
Так было, так есть и так будет

vanicon
Так это не другой пользователь. Это тот же самый пользователь - в этом и задача. Пользователь пытается зайти с двух разных машин и к первой машине у него есть доступ, ведь он сам оттуда зашел. Задача не в том, чтобы взломать чужую сессию, а в том, чтобы копировать свою. Ведь пользователь оперирует со своей же сессией - внимательнее читайте условия поставленной задачи в топике.

-----
Есть в мире две бесконечные вещи - это Вселенная и человеческая глупость. Но насчет первой .. я не уверен.