Как управлять сеансом для пользователя, зарегистрированного в мобильном приложении на PHP?

Я программист PHP по профессии. Итак, я не имею ни малейшего представления о кодировании iOS и Android.

В сценарии есть один веб-сайт, разработанный с использованием программного обеспечения PHP для социальных сетей под названием "PHPFox" .

Теперь есть два похожих мобильных приложения, которые точно воспроизводят функциональность этого веб-сайта. Одно мобильное приложение находится в iOS, а другое - в Android.

Итак, я написал набор API RESTful, где я принимаю запрос от мобильного приложения, анализирую запрос, передаю параметры запроса функции, которая выполняет ту же работу для веб-сайта, получает ответ от этой функции, преобразовать его в формат JSON и отправить обратно в мобильное приложение. Для приложений iOS и Android я использую один и тот же набор файлов REST API.

Когда пользователь входит в систему, вызывается API REST для входа в систему. В конце концов вызывается функция PHPFox для аутентификации, маркер безопасности генерируется вместе с некоторыми другими пользовательскими данными. При каждом входе в систему PHPFox генерирует другой токен безопасности. Эти данные устанавливаются в сеанс. Теперь каждый раз, когда я вызываю какие-либо функции через любой файл API REST, проверяется маркер безопасности, созданный во время входа в систему, и только после успешной проверки токена вызывается функция PHPFox. Этот процесс проверки выполняется внутри PHPFox. Поэтому нет необходимости передавать токен безопасности явно или неявно на любой вызов API REST.

До сих пор все работает отлично.

Мои сомнения начинаются отсюда. Я не знаю, поддерживается ли сеанс в приложении iOS/Android. Итак, если сеанс на сервере, то есть PHPFox, время ожидания, что произойдет с приложением? Это будет крушение? Будет ли пользователь снова войти в систему? Если пользователь убивает приложение на устройстве и снова приходит в приложение, он/она должен снова выполнить процесс входа в систему?

В моем сознании слишком много сомнений. Я полностью смущен этими вещами.

Может кто-нибудь, пожалуйста, сосредоточьтесь на проблеме, с которой я сталкиваюсь? Было бы здорово, если бы вы могли объяснить подробно.

Спасибо.

Ответ 1

REST не имеет сеанса для его природы. Вам нужно сгенерировать токен при входе в систему. Вы должны сохранить этот токен на своем мобильном клиенте. Для каждого запроса вам нужно прикрепить действительный токен в заголовке запроса и проверить его на стороне сервера. Если токен истекает, токен, хранящийся на клиенте, недействителен. Итак, вам нужно снова войти в систему из-за ответа 401. Если токен не правильный, вам нужно ответить 400. Надеюсь, что я помогу вам.

Ответ 2

В отличие от веб-браузеров, приложения iOS и Android не могут поддерживать сеансы. Обычно, как только пользователь вошел в систему (учетные данные для входа подтверждены с сервера), его учетные данные для входа сохраняются на стороне клиента. Затем приложение получает данные с сервера, используя сеанс меньше вызовов REST api. Вот как это делается в мобильных приложениях.

Однако, если вы хотите, чтобы сеанс сервера и мобильное приложение выполнялись рука об руку (что я не думаю, что это хорошая идея), путь

1) Когда пользователь входит в систему, маркер безопасности генерируется на стороне сервера и сохраняется как на стороне сервера, так и на стороне клиента.

2) Мобильное приложение сможет связываться с сервером, пока токен безопасности действителен.

3) По окончании сеанса токен безопасности становится недействительным. Теперь должно быть понимание между сервером и клиентом об ответе, когда срок действия сеанса истек. Теперь мобильное приложение должно перенаправить пользователя на страницу входа еще раз. Пользователь снова войдет в систему, а затем свяжется с сервером. Это должно происходить каждый раз, когда сеанс истек.

Ответ 3

Если вы используете Oauth 2 для аутентификации, вот общая настройка:

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

Надеюсь, что это поможет.

Приветствия

Ответ 4

Ваш сервер должен быть полностью без гражданства, поэтому сеанс не должен храниться. API REST - это просто уровень абстракции данных с дополнительной безопасностью (через токен)

Таким образом, вы API выставляете службу проверки подлинности, которая будет отвечать токеном авторизации, который будет использоваться при последующих запросах в качестве заголовка, этот токен должен быть отношением 1to1 к каждому пользователю и универсальным уникальным. Он также должен иметь истечение времени, после чего ваш сервер отвечает соответствующим ответом на ошибку, запрашивая ваше приложение, чтобы обновить токен, что может быть выполнено либо с помощью отдельной системы токенов обновления, либо с запросом, чтобы пользователь снова входил в систему, чтобы обновить токен.

Это APP, который должен поддерживать состояние, а не сервер. Сервер существует только для целей данных и поэтому не должен полагаться на какую-либо аутентификацию на основе сеанса.

Ответ 5

Вы не должны беспокоиться о сеансе со стороны мобильного разработчика. Я не очень разбираюсь в iOS, но в Android мы используем SharedPrefrence (флаг, который поддерживает сеанс локально).

Ответ 6

Сеанс - это "что-то", которое живет на сервере. Это может быть объект хранения сведений о пользователе (например, идентификатор сеанса, имя пользователя, адрес электронной почты...) или любые другие данные, которые будут необходимы для обработки будущих запросов (например, данные корзины покупок, адрес доставки...).

Это "что-то", как правило, является объектом, который может быть сохранен в памяти, в базе данных или даже сериализован и сохранен в файловой системе (я считаю, что это значение по умолчанию в PHP).

Итак, когда вы говорите: "Я не знаю, поддерживается ли сеанс в приложении iOS/Android", я боюсь, что это не имеет смысла. Только сервер может поддерживать сеансы.

Как правило, единственное, что знал клиент (веб-браузер или мобильное приложение), - это идентификатор сеанса (в виде токена или GUID). Это единственное, что нужно помнить клиенту/приложению, и его нужно отправлять вместе с любым запросом на сервер.

Он может быть сохранен как файл cookie и/или отправлен на сервер в качестве заголовка запроса.

Затем сервер будет считывать идентификатор/токен сеанса из файлов cookie или заголовка и будет извлекать данные сеанса из того места, где он хранит сеансы (файловая система, память или база данных). Это то, что происходит за сценой, когда вы вызываете session_start().

Подробнее о работе с сеансом и о том, как создать собственный обработчик сеанса (который может потребоваться в вашем случае для получения токена из заголовков запроса):
http://php.net/manual/en/function.session-start.php

Ответ 7

У меня нет опыта работы с PHPFox, но вот как интерфейс для мобильных устройств должен идеально справляться с проблемами:

Случай 1: мобильное приложение активно разговаривает с сервером:

Длительность таймаута сеанса продолжает расти, и сеанс остается в живых.

Случай 2: мобильное приложение активно без какой-либо связи с сервером (например, входящий телефонный звонок, перемещение между приложениями и т.д.):

Сегмент сервера может включать или не включать тайм-аут.
Если он истечет, следующий запрос к серверу завершится неудачно и вернет ошибку.
Приложение использует эту ошибку и изящно перенаправляет на экран входа в систему с помощью тоста, призывающего пользователя войти в систему. (Это происходит в моем банковском приложении)

Случай 3: Пользователь убивает приложение на устройстве и перезагружает его:

Приложение должно хранить токен либо в sqllite, либо в общих настройках. (Всегда входящие в систему приложения используют этот подход).
После перезапуска приложение может запросить сервер с помощью назначенного токена.
Если сеанс жив, связь проходит, и пользователь может Продолжать. Если нет, пользователь переходит на экран входа в систему, как в случае 2.

Ответ 8

Для этого требуется новый способ аутентификации и авторизации. Раньше только в дизайне системы на основе браузера мы заботились обо всех этих аспектах с точки зрения сеансов и файлов cookie. Здесь нам нужно подумать о том, что (или, может быть, что-то внизу). JSON WEB TOKEN - это способ, с помощью которого каждый запрос обрабатывается с использованием концепции токена, несущего связь.

https://jwt.io/

Подробнее о JWT аналогичной процедуре.