Как лучше хранить данные клиента между его запросами?

Question

[P P]

клиент общается с сервером через post-запросы, получает ответ в виде json.
Есть авторизация через пользователь/пароль.

Answer 1

[Дмитрий Энтелис]

1) Не надо использовать встроенные сессии вообще нигде и никогда.
В api можно использовать свои собственные токены, описать в документации api процесс их получения и передачи.

2) Почитайте документацию любого api крупного проекта: fb, https://developers.facebook.com/tools/explorer/?me... twitter https://dev.twitter.com/rest/public итд
Так или иначе (oauth, своя авторизация, еще как то) клиент получает access token который далее явно передает.

3) Если вся эта история нужна Вам для авторизации/разграничения прав - ок.
Но если Вы хотите для каждой сессии хранить какие то состояния на сервере - хорошо подумайте насколько это необходимо. Работать со stateless api гораздо приятней и понятней.

Comments

[P P]

а можно узнать, почему не стоит пользоваться сессиями?

[Дмитрий Энтелис]

Кадыр Атаханов: потому что они:
1) не явно для остального проекта хранят состояние, что провоцирует людей писать хреновый код и крайне усложняет отладку проекта в ситуации когда хранение состояний действительно нужно
2) омерзительно работают по быстродействию (решается переносом в sql/redis )
3) не поддаются нормальному контролю из приложения (blackbox: всегда грузятся все переменные)

[FanatPHP]

аффтар - кремень, задачу так и не описал. Причем предполагаю типичный нубострах "ещё раз в базу лезть!!!". Который особенно смешно смотрится на форме (совершенно правильной) рекомендации хранить сессии в БД.

[Дмитрий Энтелис]

Анатолий K: судя по реакции Вы как раз $_SESSION активно используете)

[Дмитрий Энтелис]

Анатолий K: ясно, спасибо, вопросов нет.

Answer 2

[FanatPHP]

А зачем?
Когда тебе нужно что-то необычное, всегда описывай не только свои затруднения, но и исходную задачу.
Скорее всего ты хочешь чего-то ненужное

Comments

[P P]

ну, как бы первым предложением я попытался описать исходную задачу...

[P P]

ок, понял

[Дмитрий Энтелис]

Кадыр Атаханов: Вы описали не задачу. Вы описали выбранное Вами решение задачи. Грубо говоря напишите что вы хотите сделать с точки зрения логики приложения. Не "как можно использовать сессии" или "нужно хранить такие то данные клиента между запросами, как лучше?", а ЗАЧЕМ Вам это нужно

Answer 3

[Александр]

Куки + сессии. Все современные фреймворки умеют работать с различными хранилищами данных сессии: бд, файлы, мемкеш (имхо для сессий самое то). НО не надо сохранять всю инфу пользователя в сессию, она для этого не предназначена. Можно хранить в сессии ID пользователя и остальные ключи, что бы в нужный момент легко выдернуть нужные данные из бд. Если данных много и они не менятся каждый раз, при запросе от пользователя, то можно кешировать данные, например в мемкеш, при этом данные пользователей которые давно не посещали сервис должны вытесняться данными пользователей, посетившими сервис только что.

Answer 4

[Павел Тузов]

Если я правильно понял вопрос, то достаточно клиенту добавить возможность работы с куками

Comments

[P P]

вот как раз таки, возможности использовать куков нету

[Евгений Петров]

а localStorage или sessionStorage можете?

[Александр]

Если нет возможности использовать куки, а следовательно сессии, то можно просто подменять все запросы после авторизации, добавляя туда ID пользователя, например /articles/show подменить на /articles/show/user123/password123 или на /articles/show?user=123&password=123, но в этом случае нужно будет каждый раз проверять авторизацию.

Возможно сделать следующим образом: выдать пользователю токе на основе логина, пароля и, допустим, таймстампа времени авторизации, тогда ссылка будет ввида /articles/show?token=<?= md5($password . $login . $time) ?>, и писать этот токен бд, со временем последнего запроса от пользователя. Если пользователь не заходил, долгое время то токен не действительный, если зашел то просто обновляем время в таблице.

[P P]

Александр: вот поставил бы ваш комментарии как лучший ответ, спасибо очень помогли!