bestxpsession_start();
session_write_close();
sleep(100);
echo 'hello i\'m very long operation';
или использовать memcached, но тут нет блокировок на сессию и можно потерять данные. Для авторизации очень подходит, один раз записал - потом только читаем и если нужно уничтожаем.
Или
killer8080 вы про другое?
_____________
Все будет офигенно. Кому-то сразу, кому-то постепенно.
Если все молчат, значит для авторизации нужно использовать сессии + memcached?
_____________
Все будет офигенно. Кому-то сразу, кому-то постепенно.
RootPM
13.11.2016 - 11:01
Вот такой вариант:
| Цитата |
Записываем id в session (memcached), логин в cookie.
Если имеется сессия, значит авторизирован, в вёрстку логин подставляем из cookie (чтобы не доставать из таблицы user).
Дальше из таблицы блокировок проверяем текущего пользователя.
При добавлении или удалении контента проверяем пару id и логин в таблице user (подстраховка от подбора идентификатора сессии). |
Нормальный вариант? Какие будут слабые места?
_____________
Все будет офигенно. Кому-то сразу, кому-то постепенно.
killer8080
15.11.2016 - 22:18
| Цитата (RootPM @ 8.11.2016 - 16:35) |
session_start();
// записали данные в переменную
session_write_close();
sleep(100);
echo 'hello i\'m very long operation';
или использовать memcached, но тут нет блокировок на сессию и можно потерять данные. Для авторизации очень подходит, один раз записал - потом только читаем и если нужно уничтожаем.
Или killer8080 вы про другое? |
Совершенно верно, если в контексте текущего запроса не требуется ничего сохранять в сессию, дескриптор следует высвобождать сразу после получения данных из сессии. Кстати в PHP7 появилась возможность задавать параметры аргументом в session_start(), и помимо обычных ini параметров есть read_and_close, чтоб не вызывать вручную session_write_close()
session_start([
'read_and_close' => true
]);
| Цитата (RootPM @ 9.11.2016 - 15:26) |
Если все молчат, значит для авторизации нужно использовать сессии + memcached?
|
можно и мемкеш, не факт что запросы к мемкешу будут быстрее, чем чтение файла с RAM диска. Можешь поэкспериментировать и сравнить, интересно увидеть результаты тестов :)
| Цитата (RootPM @ 13.11.2016 - 11:01) |
Если имеется сессия, значит авторизирован, в вёрстку логин подставляем из cookie (чтобы не доставать из таблицы user).
Дальше из таблицы блокировок проверяем текущего пользователя. |
вообще не понял смысла этих движений. То есть дергать таблицу юзеров - смертный грех, а таблицу блокировок - это в порядке вещей. Зачем вообще нужна таблица блокировок? Не проще хранить статус юзера в самой таблице users?
RootPM
18.11.2016 - 06:36
| Цитата (killer8080 @ 15.11.2016 - 22:18) |
| Не проще хранить статус юзера в самой таблице users? |
Согласен
_____________
Все будет офигенно. Кому-то сразу, кому-то постепенно.
RootPM
21.11.2016 - 12:58
Что-то не получается придумать нормальный алгоритм самой авторизации. Решил остановиться на сессиях, которые хранятся в памяти. Для авторизации используем логин и пароль, если верно ставим сессию - id пользователя, если стоит галочка - запомнить меня, записываем в куку id и хеш.
Допустим у нас стоит кука и сессия, а что дальше? Сначала проверить есть или нет сессия, потом если нету проверять куку. Получается если правильная кука, то ставим сессию и делаем переадресацию на эту же страницу. Или остальной функционал после авторизации сделать в виде функции и подключать при необходимости после проверки сессии или куки?
И ещё прозвучало `использование сессий + аякс`, а подробнее можно?
_____________
Все будет офигенно. Кому-то сразу, кому-то постепенно.
brevis
21.11.2016 - 13:16
Шож ты так убиваешься? Тыж так не убьешься.
Проведи исследование. Возьми популярные CMS и посмотри как там сделано. Ну и нам потом расскажи.
Будет больше толку.
_____________
Чатик в телеге
почему вы привязались к хранению сессий в памяти? это не самое лучшее решение. а на больших проектах с большим кол-вом посещений, можно сказать, даже, худшее.
Все одно и потому же, сто раз уже пояснили
- юсер вводит логин и пароль, если правильно, то записываем id в сессию
- если пожелал запомнить его, то делаем хеш, в хеш можно писать что тебе нравиься id , маил или еще чего, этот хеш пишем в бд к юсеру и его же записываем в куки
- если юсер заходит снова на сайт, к примеру на след день, то делаем проверку, если нет сессии и есть кука то лезим в бд, сверяем хеш куки и достаем id этого пользователя чей хеш и создаем сессию с его id , и тут же обновляем хеш этого юсера в бд и куках, ну а далее показывай ему че хочешь
- если нет сессии и нет кук, то показываем авторизацию
Что здесь непонятного, ты ходишь вокруг до около
RootPM
21.11.2016 - 15:32
depp
Поясни почему хранить сессии в памяти хуже чем на дисках? При этом в сессии хранится только id пользователя.
P.S. Крупные проекты переходят именно на ОЗУ, у нас в одном проекте на сервере 128 гигов оперативной памяти.
_____________
Все будет офигенно. Кому-то сразу, кому-то постепенно.
RootPM
21.11.2016 - 15:34
| Цитата (brevis @ 21.11.2016 - 13:16) |
| Тыж так не убьешься. |
Я хочу это от вас услышать ) А у меня давно уже всё сделано
Просто знакомые спрашивают, а так дал ссылку с мнениями разных программистов - пусть изучают ))
_____________
Все будет офигенно. Кому-то сразу, кому-то постепенно.
RootPM
21.11.2016 - 15:42
| Цитата (Astin @ 21.11.2016 - 15:10) |
| и тут же обновляем хеш этого юсера в бд и куках |
Вот это не правильно, если авторизация на нескольких устройствах?
Вопрос больше в чём, сначала проверяем наличие сессии, а потом уже печеньки, правильно? Потом ставим сессию и тут два варианта, сделать переадресацию или использовать функцию, которая подключается в блоках сессии и после проверки куки, функция извлекает данные о пользователе.
Вы какой вариант выберите или свой предложите?
_____________
Все будет офигенно. Кому-то сразу, кому-то постепенно.
| Цитата (RootPM @ 21.11.2016 - 15:32) |
depp
Поясни почему хранить сессии в памяти хуже чем на дисках? При этом в сессии хранится только id пользователя.
P.S. Крупные проекты переходят именно на ОЗУ, у нас в одном проекте на сервере 128 гигов оперативной памяти. |
потому что данные теряться будут. я вообще не вижу у вас никакой проблемы использовать БД для сессий. тем более с таким кол-вом памяти. хотя и с мемкеш проблем возникнуть не должно.
крупные проекты переходят на ОЗУ. чего? для чего? для использования мемкеш?
есть вариант разместить виртаульный жесктий на озу и на нем раскатить базу. такие решения имеют место быть.
RootPM
21.11.2016 - 15:49
| Цитата (depp @ 21.11.2016 - 15:42) |
потому что данные теряться будут.
крупные проекты переходят на ОЗУ. чего? для чего? для использования мемкеш? |
Перед тем как перезагрузить сервер мы снимаем данные с памяти.
Что касается DB + сессии:
| Цитата (killer8080 @ 2.11.2016 - 21:58) |
| Цитата (depp @ 2.11.2016 - 18:01) | | я бы сессии в том варианте php, который есть - вообще не использовал. слишком накладно. проще всего писать в куку id и хэш. а саму сессию хранить в базе. нет ничего накладного в том, чтобы дергать постоянно инфу о пользователе из базы. |
то есть схема:
php->файл_сессии
очень затратна по ресурсам, по сравнению с:
php->БД->файл_бд
|
_____________
Все будет офигенно. Кому-то сразу, кому-то постепенно.
RootPM
вы хотите сказать, что вообще не открываете коннект с базой при использовании своей программы?
Быстрый ответ:
Powered by dgreen
Здесь расположена полная версия этой страницы.