Добрый день. Пишу простой сайт для детского лагеря. Возникла задача в установке пароля для входа в админку. Пароль запрашивается каждый раз, когда попадаешь на главную страницу админки. Как сделать так, что бы в течении определенного времени после ввода пароля, он сохранялся, а потом опять запрашивал?
куки - худший вариант. ибо они никак не шифруются, передаются при КАЖДОМ запросе в открытом виде, и вообще их может подменить юзер. лучше basic_auth или сессия
Бред. Создаешь кеш состоящий из браузера+какая-то строка или IP. Хранишь его в бд и у юзера. Украсть можно только имея доступ к пк. Естественно нельзя хранить в нем сразу user_id. Всё надежно при правильном подходе.
Сессия удаляется при закрытии браузера. Вопрос был - как пароль сохранять. Я назвал не велосипед, а пример надежного хранения пароля, с опревержением его "не шифрования".
Во первых это зависит от того, какое у нее время жизни, а во вторых, вы говорите какую то чушь: И это нам говорит, кто хочет строить безопасность? Зачем хранить пароль в сессиях или куках? Достаточно хранить индификатор, авторизованного пользователя.
Опечатка, офк. Не пароля а хеша юзера. После закрытия браузера сессия сохранится? ПРимер кода пожалуйста
есть функция session_destroy() по теме ini_set('session.gc_maxlifetime', 120960); ini_set('session.cookie_lifetime', 120960); а еще все таки можно написать код который будет дестроить сессии при закрытии вкладки.
сессия определяется двумя вещами: сессионной кукой и файлом. поэтому глупо говорить, что сессия лучше куки, она основана на куке! время жизни сессионной куки задается session_set_cookie_params(), то есть можно задать ненулевое время и сессия не будет умирать при закрытии браузера. а время жизни сессионного файла определяется как вероятность, что по истечении определенного времени с момента последнего обращения файл будет удален: session.gc_maxlifetime, session.gc_probability и session.gc_divisor. так стоит ли завязывать авторизацию, а точнее идентификацию, на сессию или на отдельную куку? тут разные мнения, я считаю отдельная лучше, т.к. * мы управляем временем жизни идентификационной куки отдельно от времени жизни, скажем, корзины или еще какой-нибудь фиг ни. * опция "запомнить меня" не приведет к тому, что мы должны делать сессионные файлы "вечными". а что именно должно быть в такой куке это отдельная интересная тема. конечно пароль в открытом виде там не должен присутствовать.
Тут есть интересный момент, функция session_destroy() не удаляет сессию, а всего лишь очищает содержимое сессионного файла, полностью удаляет сессии механизм под названием php garbage collection, который в свою очередь имеет свою переодичность запуска. но этот момент можно обойти функцией session_regenerate_id() или session_name().
ТС не писал ничего о корзине, функции Запомнить меня и прочей хуйни... ему просто нужна авторизация. но не завязанная на то когда закроют бравзер, а чтоб можно было сделать таймаут. когда авторизация будет сброшена. через сесии это делается элементарно. флаг авторизации и дата окончания действия авторизации. всЁ! и ненужно никакие куки самому выставлять, управлять отдельно временем их жизни, гонять дополнительные данные туда сюда в открытом виде... перфекционисты блин
да дело хозяйское. я никого не агитирую. мне лично непонятно что за "данные в открытом виде", с чего это они более открытые чем идентификатор сессии. Добавлено спустя 4 минуты 37 секунд: только мне кажется, что здесь заявка на "запомнить меня"? Добавлено спустя 3 минуты 8 секунд: топикстартер про*ался после первого же сообщения, а хочется уточнить: а сейчас как сделана авторизация? код в студию!
идентификатор это набор символов, где нет закономерности, порядка и логики. подделать его можно - только на что? или предлагаете вообще отказаться от механизма сесиий - и придумать свой, на базе тех же кук? а вот если засунуть в куки какието свои данные, пароли, логины, ключи доступа, даты окончания действия авториации и т.д. то они будут открыты, понятны для модификации и подделки. да, можно их закодировать, зашифровать и т.д. но нафига создавать себе лишнюю работу на пустом месте? мне лично тоже пох. Кто хочет тратить время на лишние телодвижения - пусть страдает дальше. я подсказал ТСу самый простой вариант решения проблемы. ненадо ничего придумывать нового. решение в пару строк. прислушаться или нет - дело его.
чтобы понять всё про "открытые данные" надо определиться: мы говорим про перехваченные данные или про искуственно сгенерированные данные? если перехваченные, то без разницы насколько "зыкрытая" будет кука — злодей просто скопирует ее и будет выдавать себя за другого. если сгенерированные, то по твоей логике, злоумышленник знает алгоритм, пароль, соль, перец и вообще всё, черт побери, да он спит с нашими данными! от него просто нет спасенья. для меня тема закрыта. для тебя тоже — используй свою пару строк во всех случаях. а топикстартера нет и наверное не было )))
А ты сессию и не подменишь, даже если ты индификатор поменяешь... НЕКАСАЕТСЯ ПЕРЕХВАТЧИКОВ! Он будет не действителен, сразу после запроса и отправки. А собственно в индике не говорится ничего о том, что там хранится, а это нонсенс, мы же можем туда еще и грязи налить. Если бороться с кукой при шифровке, скажем мы храним "хеш пароля+логин+соль+что_то_еще...", а если там <матное слово> гора данных? Далее опять-же получая данные о шифровке нам нужно опять на сервере шифровать в том-же порядке, чтобы сверить данные "<матное слово> гора данных?", каждое обращение... Каждое не верное обращение... <матное слово> оно надо?* Когда уже придумали механизм, который все делает за нас.
Таки да. Подделка ID сессии не приведет к краже сессии, если разработчик не жопой продумывал сей аспект. Нельзя на этой волне не вспомнить наш любимый phpBB, где кража идентификатора сессии равносильна краже сессии, что как бы намекает нам, ну вы поняли.
В phpBB (стандартном, без модов) в админке можно включать/выключать привязку сессии к IP-адресу и к юзер-агенту.