Нормальная поддержка сессий со сбросом всех сессий по изменению пароля и "автологином" - не меньше движений требует. А все перечисленные мной движения - одна строчка в методе расчета хеша. (Добавление)
resik пишет:
Вариант не безопасен?
Относительно безопасен, но следует учитывать несколько вещей. Как контролировать, что пользователь удален или забанен? Сброс всех сессий при смене пароля - полезная функция для безопасности пользователя. Т.е. вам все-равно нужно будет выгребать пользователя из базы, так что писать все его данные в сессию особо смысла нет.
Да там много подводных камней. Например - блокировка файла сессии. Время жизни сессии. Оно короткое, значит начинаем еще "поверх" воротить что-то вроде автологина, что по сути есть некий ключ в куках не связанный с сессией.
Это все можно заменить на хеш с необходимой информацией и секретным ключем, записанный в куку. Считали из кук хеш и user_id, выгребли из базы, построили хеш на основе пароля, секретного ключа приложения, каких-то еще необходимых данных (юзерагент, ipи т.п.), сравнили с тем, что в куке. Равно? Значит все ок.
Поэтому нужно не обсуждать что хуже красть, а сделать так что бы украсть куку было невозможно.
Нет ничего невозможного - троян на комп и куки ушли. Новая 0day дыра в браузере - и куки ушли. Но если говорить о преобладающем способе краж через XSS - то httponly достаточно.
esterio пишет:
Не надо холиварить. Простой сессии и ее ИД в куках в большинстве случаев достаточно, если же это не интернет-банкинг конечно.
А причем тут банк. Это вопрос исключительно архитектуры и тех людей, которые не желают засирать файловую систему файлами сессий только для того, что бы записать туда user_id=99. Вопрос аутентификации действительно решается неплохо доверенным хешом+user_id в куке. Но для тех, кто программирует по учебнику, конечно, ничего кроме сессий и быть не может, они могут не читать написанное ;)
С появлением FTS в InnoDb причин использовать MyISAM осталось менее 1%. И те весьма специфические задачи, о который на стадии изучения мира СУБД можно забыть.
И тут вообще еще надо с терминологией разбираться, что есть в действительности процедурное программирование, а что есть императивное.
Что тут разбираться. Процедурное программирование - императивно. ООП - тоже императивно. Автоматное программирование - это вообще область алгоритмов. В общем это совершенно разные категории странно смешанные в кашу.
Не, я же сказал - есть исключения, как правило для реального хайлоада. Очень нужно понимать, что делаешь. Простой пример: архитектурно верно - нормальная форма данных в БД, в реальности - бывает, делаем денормализацию ;)
Ладно, проехали ;) (Добавление)
LIME пишет:
я категорически знаю что есть штука удобнее
Субъективно удобнее ибо есть знание редиса, но нет - мемкеша ;) Мне вот эта удобность не очевидна, ибо давно и активно знаю мемкеш, а редис - только на некоторые задачи быстрого доступа к данным по ключу, да и то, обычно, вместе с FTS движками типа сфинкса.
Не влезли - пока новые данные, даже если они и супер горячие ;))
eviction policy в конфиге.
LRU вполне умеет. Но дефолтно - да, стоит noeviction.
А, ну отлично ;)
Я в общем не о том, что редис не может работать как кеш - не пробовал, не знаю ;) А о том, что мемкеш покрывает основные задачи кеша вполне даже сегодня, так что нет никаких причин категорически его отвергать.
Если мы хотим прочитать + изменить + записать - в редисе нужно WATCH, разве не так? А watch - это именно что оптимистичная блокировка.
Могу ошибаться про транзакции с редисом почти не использовал.
Цитата:
Цитата:
которому персистентность не только не нужна - она вредна.
вот сейчас вообще не понял
в чем вред?
В том, что, как я говорил, кеш можно выключить - ПО должно работать. Кеш включить - ПО должно начать наполнять кеш. По определению кеша ;) Персистентность тут собаке пятая нога. Вредна именно с точки зрения искажения архитектуры - начинаешь ориентироваться на то, чего быть не должно.
Сори если сумбурно, жена не дает расслабляться ;)
Цитата:
ты о мютексах итп?
Я о CAS.
Цитата:
вообще не серьезно
разогрев кэша это я вообще не понимаю
я знаю что это такое но учитывать разогрев....хмммм
Представь себе, что сайт выдерживает 10к хитов, а с кешом - 40к. Что произойдет в час пик, если будет 30к хитов, пока кеш не разогреется? Все ляжет. Персистент тут может помочь. Но, в более... обыденных случаях - он вреден, ибо поднятый устаревший давно кеш может доставить много больше проблем ;)
Чем мемкеш лучше редиса для кеша? Как минимум вытеснением. Мемкеш сам заботится о том, что бы удалять редко востребованные данные в случае нехватки памяти. В редисе - есть память, есть данные. Не влезли - пока новые данные, даже если они и супер горячие ;))
Тут есть путаница. Есть мемкеш, а есть клиенские библиотеки для общения с мемкеш. Их две - либмемкеш и либмемкешед ;) Вторая просто поддерживает больше фич мемкеша, но блокировка - это все же фича мемкеша, а не библиотеки.
Цитата:
скорее всего путаю раз ты завел об этом речь(кстати просвяти)
Атомарность - это единая неделимая операция относительно других процессов/потоков. Т.е. возьмем банальное - запись в файл. Атомарен он? Наверное, нет - если два процесса пишут в один файл одновременно - будет каша. А как же логи, неужели блокировки? Ан нет, оказывется, в linux запись в файл блока размером одной страницы памяти (4к обычно) - атомарен. Т.е. если мы добавляем в файл строчку небольшую - можно не блокировать, никто в середину этой строчки не влезет.
Другое дело, что не нужно путать просто атамарность, как термин, с ACID (где A == атомарность) - последнее относится к транзакционным СУБД, коим мемкеш не является.
Оптимистичные блокировки в мемкеше - это не атомарность.
Цитата:
но разве и не хорошо что мне не надо знать эти тонкости
инкрементю значение и точно знаю что не будет гонки состояний
а если надо то и транзакции есть
Тонкости знать нужно. Прочитав значение из базы, будь то редис или мускуль, изменив его в ПО и записав - получаешь гонку. Ибо при чтении нужно явно назначить блокировку. А атомарно сделать инкримент можно и в мемкеше - отдельной операцией (т.е. http://php.net/manual/ru/memcached.increment.php)
Цитата:
и персистентность...кстати что там будет с мемкэшед если сервак отключить
Так я и пишу - мемкеш, это тот механизм, которому персистентность не только не нужна - она вредна. Есть всякие решения для крупных систем, где могут быть проблемы на время разогрева кеша... но это исключения.
Никогда. Мемкеш атомарен.
Ты, по ходу, путаешь атомарность и транзакции с блокировками. Типа, "прочитал, а потом записал". Это всегда было вопрос блокировок. Хоть в мемкеше, хоть в редисе, хоть мускуле.
В мемкеше есть замечательные оптимистичные блокировки, что гораздо полезнее, чем пессимистичные _для кеша_.
Еще раз, это разные инструменты. Абсолютно. Мемкеш - это кеш. Редис - это СУБД. У мемкеша есть то, что нужно для кеша, включая оптимистичные блокировки и вытеснение ключей. У Редиса - то, что для СУБД, включая транзакции и "даже персистентность". У мемкеша вообще не может быть "дедблока". Более того, если ПО валится из-за пробелм с мемкешом - это хреновое ПО с хреновой архитектурой. Ибо это кеш - он может быть, его может не быть - ПО должно работать.
Цитата:
MiksIr))) не умничай)) я если говорю то знаю что говорю
В том то и дело, что тут мимо. Возможно, слабый опыт в мемкеше и много хабра про редис?
Главная
Помощь
Поиск
Пользователи
Найдено сообщений: 378
