Чего то меня переклинило, сделал посмотрите безопасно будет?
1 Проверяем логин и пароль
2 Генерируем хеш записав в DB, записываем в куки: id, логин, хеш,
3 На каждой странице достаём логин из кук и вставляем в вёрстку
4 При редактировании информации (добавление, удаление) залезаем в DB и проверяем по id, хеш
P.S.
То что пользователь может поменять себе логин в браузере, на сервере никак не отобразится.
Использовал куки чтобы снять нагрузку при использовании сессий (кто то скажет ерунда, но когда сервер уже нагружен - чувствуется разница)
Теперь не нужно при каждой загрузке страницы залезать в DB, тоже немного снизил нагрузку
В целом вариант безопасен для сервера?
_____________
Все будет офигенно. Кому-то сразу, кому-то постепенно.
Полная Версия: Авторизация
Время жизни кук зависит от того, поставил или нет пользователь галочку - запомнить.
_____________
Все будет офигенно. Кому-то сразу, кому-то постепенно.
_____________
Все будет офигенно. Кому-то сразу, кому-то постепенно.
В случае наличия в куках id и хеша, при этом неправильных - блокировка IP на некоторое время (защита от перебора)
_____________
Все будет офигенно. Кому-то сразу, кому-то постепенно.
_____________
Все будет офигенно. Кому-то сразу, кому-то постепенно.
Вот так и появляются "высоконагруженные" проекты. 
А всего-то навсего нет денег, что само по себе вызывает много вопросов о целесообразности проекта и работы над ним. Просто по-товарищески советую подумать над таким вопросом: оно тебе надо? Это твой проект?
А всего-то навсего нет денег, что само по себе вызывает много вопросов о целесообразности проекта и работы над ним. Просто по-товарищески советую подумать над таким вопросом: оно тебе надо? Это твой проект?| Цитата |
| оно тебе надо? Это твой проект? |
Да. Нет.
| Цитата (Ron @ 31.10.2016 - 20:25) |
| Вот так и появляются "высоконагруженные" проекты. |
Не совсем понял
_____________
Все будет офигенно. Кому-то сразу, кому-то постепенно.
| Цитата (RootPM @ 31.10.2016 - 06:44) |
| Чего то меня переклинило, сделал посмотрите безопасно будет? |
делай лучше как выше inpost говорит.
Так и в yii2 вся эта кухня сделана.
Ну смысл в том что при каждой загрузке страницы для авторизованного(есть id в сессии) все равно будет дергаться таблица user чтобы получить актуальную сущность текущего пользователя.
_____________
There never was a struggle in the soul of a good man that was not hard
Насколько знаю в больших проектах авторизация на куках сделана. Кто может назвать плюсы и минусы разных подходов (сессии, куки)?
Если позволите мысли вслух, а вы поправьте если ошибаюсь.. Авторизация нужна чтобы аутентифицировать конкретного пользователя, для чего имеется логин и пароль, но чтобы не вводить данные на каждой странице, мы должны сохранить идентификационную информацию на стороне клиента (сервера).
Можно сохранить в cookie id пользователя, но тогда пользователь может изменить это значение и выдать себя за другого. Или сохранить id пользователя в сессии на сервере, а данные о сессии сохранятся в cookie у пользователя, при таком подходе уже можно доверять этим данным, но если много пользователей, то нужно сессии перемещать в память..
Вот я и подумал немного нагрузки переложить на пользователя, сохранить в cookie - id пользователя и хеш (сгенерированное число + user_agent + login). При таком подходе, даже если изменить куки можно добиться изменения только в браузере у этого пользователя, а при действиях вроде редактирования, сохранения и удаления залазить в DB и проверять значения id пользователя и хеш, которые будут храниться в таблице online пользователей.
_____________
Все будет офигенно. Кому-то сразу, кому-то постепенно.
Если позволите мысли вслух, а вы поправьте если ошибаюсь.. Авторизация нужна чтобы аутентифицировать конкретного пользователя, для чего имеется логин и пароль, но чтобы не вводить данные на каждой странице, мы должны сохранить идентификационную информацию на стороне клиента (сервера).
Можно сохранить в cookie id пользователя, но тогда пользователь может изменить это значение и выдать себя за другого. Или сохранить id пользователя в сессии на сервере, а данные о сессии сохранятся в cookie у пользователя, при таком подходе уже можно доверять этим данным, но если много пользователей, то нужно сессии перемещать в память..
Вот я и подумал немного нагрузки переложить на пользователя, сохранить в cookie - id пользователя и хеш (сгенерированное число + user_agent + login). При таком подходе, даже если изменить куки можно добиться изменения только в браузере у этого пользователя, а при действиях вроде редактирования, сохранения и удаления залазить в DB и проверять значения id пользователя и хеш, которые будут храниться в таблице online пользователей.
_____________
Все будет офигенно. Кому-то сразу, кому-то постепенно.
RootPM
у вас такая каша в голове.
"сессии перемещать в память.." - это вообще как?
у вас такая каша в голове.
"сессии перемещать в память.." - это вообще как?
| Цитата (RootPM @ 1.11.2016 - 08:30) |
| Не совсем понял |
Денег не выделяют, нагрузка растет, проект становится "высоконагруженным". Ну кто помнит моё мнение об этом термине, тот поймет.
| Цитата (Guest @ 1.11.2016 - 05:54) |
| Да. Нет. |
Беги оттуда, либо зарплату требуй, которую не дадут, раз на железо жмотятся. Наверняка там можно обойтись очень небольшими вложениями.
| Цитата (depp @ 1.11.2016 - 23:53) |
| у вас такая каша в голове. "сессии перемещать в память.." - это вообще как? |
Сессии. Обучение и правильное использование (Как устроены сессии: где хранится информация)
_____________
Все будет офигенно. Кому-то сразу, кому-то постепенно.
| Цитата (RootPM @ 1.11.2016 - 19:41) |
| Можно сохранить в cookie id пользователя, но тогда пользователь может изменить это значение и выдать себя за другого. Или сохранить id пользователя в сессии на сервере |
Сессия недолго существует.
А куку можно поставить без ограничения.
Например я вошел на этом форуме, и следующий раз через 2 недели вошел и все также зареган.
Чтоб id не меняли, ну так секретный ключ еще хранят, хеш завязанный на сущности пользователя, если менять то id аутентификация не произойдет.
Ну т.е. как и с паролями когда, тот же смысл.
_____________
There never was a struggle in the soul of a good man that was not hard
| Цитата (Michael @ 2.11.2016 - 08:09) |
| Чтоб id не меняли, ну так секретный ключ еще хранят, хеш завязанный на сущности пользователя, если менять то id аутентификация не произойдет. Ну т.е. как и с паролями когда, тот же смысл. |
Про это и говорю, так нормально же будет?
| Цитата |
| Вот я и подумал немного нагрузки переложить на пользователя, сохранить в cookie - id пользователя и хеш (сгенерированное число + user_agent + login). |
_____________
Все будет офигенно. Кому-то сразу, кому-то постепенно.
ну да, нормально. Только о какой нагрузке "переложенной на пользователя" речь? О значении в login? Про это выше вроде говорили, что всегда нужна актуальная инфа.
_____________
There never was a struggle in the soul of a good man that was not hard
_____________
There never was a struggle in the soul of a good man that was not hard
Michael
Может и правда показаться, что я играю на мелочах (но если таких мелочей много), всего навсего хотел услышать мнение местных программистов, но чего то все молчат..
При таком подходе id пользователя, его логин и хеш запишутся в cookie, а это дополнительное место на диске или в памяти сервера * на количество пользователей. Кроме того мне не придётся каждый раз без необходимости залезать в DB, если пользователь просто ходит по сайту и нужно показать только его логин в шапке. Самое главное при таком подходе не потерять бдительность и обеспечить возможную безопасность, предложил такой вариант хеша: сгенерированное число + user_agent + login.
_____________
Все будет офигенно. Кому-то сразу, кому-то постепенно.
Может и правда показаться, что я играю на мелочах (но если таких мелочей много), всего навсего хотел услышать мнение местных программистов, но чего то все молчат..
При таком подходе id пользователя, его логин и хеш запишутся в cookie, а это дополнительное место на диске или в памяти сервера * на количество пользователей. Кроме того мне не придётся каждый раз без необходимости залезать в DB, если пользователь просто ходит по сайту и нужно показать только его логин в шапке. Самое главное при таком подходе не потерять бдительность и обеспечить возможную безопасность, предложил такой вариант хеша: сгенерированное число + user_agent + login.
_____________
Все будет офигенно. Кому-то сразу, кому-то постепенно.
Здесь расположена полная версия этой страницы.