Android — Как управлять сессией для пользователя, вошедшего из мобильного приложения на PHP?
Я Программист PHP по профессии. Итак, я не имею никакого представления о кодировании iOS и Android.
Сценарий таков, что есть один веб-сайт, разработанный с использованием программного обеспечения PHP для социальных сетей под названием «PHPFox».
Теперь есть два похожих мобильных приложения, которые точно повторяют функциональность этого сайта. Одно мобильное приложение для iOS, а другое для Android.
Итак, я написал набор API RESTful, где я принимаю запрос от мобильного приложения, анализирую запрос, передаю параметры запроса в функцию, которая выполняет ту же работу для веб-сайта, получает ответ от этой функции, конвертирует его в формате JSON и отправил его обратно в мобильное приложение. Для приложений iOS и Android я использую один и тот же набор файлов REST API.
Когда пользователь входит в систему, вызывается REST API для входа. В конце концов вызывается функция PHPFox для аутентификации, генерируется токен безопасности и некоторые другие пользовательские данные. При каждом входе в систему PHPFox генерирует разный токен безопасности. Эти данные устанавливаются в сеанс. Теперь каждый раз, когда я вызываю любую функцию через любой файл REST API, проверяется токен безопасности, сгенерированный во время входа в систему, и только после успешной проверки токена вызывается функция PHPFox. Этот процесс проверки выполняется внутри PHPFox. Поэтому нет необходимости явно или неявно передавать маркер безопасности любому вызову REST API.
До сих пор все работает абсолютно нормально.
Мои сомнения начинаются отсюда. Я не знаю, поддерживается ли сеанс в приложении iOS / Android. Итак, если время сеанса на сервере, т.е. PHPFox истекло, то что будет с приложением? Это потерпит крах? Придется ли пользователю снова войти в систему? Если пользователь убивает приложение на устройстве и снова входит в него, должен ли он / она снова выполнить процесс входа в систему?
В моей голове слишком много сомнений. Я полностью запутался с этими вещами.
Может кто-нибудь, пожалуйста, уделите больше внимания проблеме, с которой я сталкиваюсь? Было бы здорово, если бы вы могли объяснить подробно.
Благодарю.
Решение
ОТДЫХ бессессионный по своей природе. Вам необходимо сгенерировать токен, когда пользователь вошел в систему. Вы должны сохранить этот токен на своем мобильном клиенте.
К каждому запросу необходимо прикрепить действительный токен в заголовке запроса и проверить его на стороне сервера.
Если токен истекает, токен, хранящийся на клиенте, недействителен. Итак, вам нужно снова войти в систему из-за ответа 401. Если токен неправильный, вам нужно ответить 400.
Я надеюсь, что я помогу тебе.
Другие решения
В отличие от веб-браузеров, приложения для iOS и Android не могут поддерживать сеансы. Обычно, когда пользователь входит в систему (учетные данные проверены с сервера), его учетные данные сохраняются на стороне клиента. Затем приложение получает данные с сервера, используя сеансы без REST API-вызовов. Так в основном это делается в мобильных приложениях.
Однако, если вы хотите, чтобы серверный сеанс и мобильное приложение шли рука об руку (что я не считаю хорошей идеей), то путь
1) Когда пользователь входит в систему, токен безопасности генерируется на стороне сервера и сохраняется как на стороне сервера, так и на стороне клиента.
2) Мобильное приложение сможет обмениваться данными с сервером, пока токен безопасности действителен.
3) По истечении сеанса токен безопасности становится недействительным. Теперь между сервером и клиентом должно быть понимание ответа по окончании сеанса. Теперь мобильное приложение должно перенаправить пользователя на страницу входа снова. Пользователь снова войдет в систему и затем свяжется с сервером. Это должно происходить каждый раз, когда сеанс истекает.
Если вы используете Oauth 2 для аутентификации, вот общая настройка:
- Пользователь входит в мобильное приложение
- Если учетные данные в порядке, сервер возвращает токен доступа, токен обновления и время жизни токена
- Мобильное приложение хранит эти значения + текущую метку времени
- На стороне сервера сборщик мусора настроен для очистки устаревших токенов.
- Перед выполнением любого вызова API мобильное приложение проверяет, не истекает ли токен (с помощью сохраненных значений). Если срок действия токена истекает, приложение отправляет токен обновления, который указывает серверу сгенерировать новый токен доступа.
- Если вы хотите, чтобы пользователи оставались на связи, приложение можно настроить для периодической проверки токена доступа и запроса нового, если он устарел
Надеюсь это поможет.
ура
Ваш сервер должен быть полностью сохранен без сохранения состояния, поэтому сеанс не должен храниться. REST API — это фактически просто уровень абстракции данных с дополнительной защитой (через токен)
Таким образом, ваш API предоставляет сервис аутентификации, который будет отвечать токеном авторизации, который будет использоваться для последующих запросов в качестве заголовка, этот токен должен быть отношением 1 к 1 с каждым пользователем и универсально уникальным. Он также должен иметь время истечения, после чего ваш сервер отвечает соответствующим сообщением об ошибке, запрашивая ваше приложение обновить токен, что можно сделать либо через отдельную систему обновления токенов, либо запрашивая, чтобы пользователь снова вошел в систему, чтобы обновить токен. ,
Это приложение, которое должно поддерживать состояние, а не сервер. Сервер существует только для целей передачи данных и поэтому не должен полагаться на какую-либо аутентификацию на основе сеанса.
Вам не стоит беспокоиться о сессии со стороны разработчиков мобильных приложений. Я не очень разбираюсь в iOS, но в Android мы используем SharedPrefrence (Флаг, который поддерживает сеанс локально).
У меня нет никакого опыта работы с PHPFox, но вот как мобильный интерфейс должен в идеале решать проблемы:
Случай 1: мобильное приложение активно общается с сервером:
- Отметка времени ожидания сеанса продолжает увеличиваться, и сеанс остается живым.
Случай 2: мобильное приложение активно без какого-либо взаимодействия с сервером (например, входящий телефонный звонок, перемещение между приложениями и т. Д.):
- Сеанс сервера может или не может тайм-аут.
- Если время ожидания истекло, следующий запрос к серверу завершится неудачно и вернет ошибку.
- Приложение использует эту ошибку и изящно перенаправляет на экран входа в систему с сообщением тост, призывающим пользователя войти в систему.
(Это происходит в моем банковском приложении)
Случай 3: пользователь убивает приложение на устройстве и перезапускает его:
- Приложение должно хранить токен либо в sqllite, либо в общих настройках. (Всегда вошедшие в приложения используют этот подход)
- После перезапуска приложение может запросить сервер с постоянным токеном.
- Если сеанс жив, связь проходит, и пользователь может
Продолжить. Если нет, пользователь переходит к экрану входа в систему, как в случае 2.
Сеанс — это «нечто», которое живет на сервере. Это может быть объект, хранящий сведения о пользователе (например, идентификатор сеанса, имя пользователя, адрес электронной почты …) или любые другие данные, которые потребуются для обработки будущих запросов (например, сведения о корзине, адрес доставки …).
Это «что-то», как правило, является объектом, который может быть сохранен в памяти, в базе данных или даже сериализован и сохранен в файловой системе (я считаю, что это PHP по умолчанию).
Поэтому, когда вы говорите: «Я не знаю, поддерживается ли сеанс в приложении iOS / Android», я боюсь, что это не имеет смысла. Только сервер может поддерживать сеансы.
Как правило, единственное, что клиент должен знать (веб-браузер или мобильное приложение), это идентификатор сеанса (в форме токена или GUID). Это единственное, что клиент / приложение должны помнить, и его нужно отправлять вместе с любым запросом на сервер.
Он может быть сохранен в виде файла cookie и / или отправлен на сервер в качестве заголовка запроса.
Затем сервер считывает идентификатор / токен сеанса из файлов cookie или заголовка и извлекает сведения о сеансе из места, где он хранит сеансы (файловая система, память или база данных). Вот что происходит за кулисами, когда вы звоните session_start(),
Чтобы узнать больше об обработке сеанса и о том, как создать собственный обработчик сеанса (что может потребоваться в вашем случае для получения токена из заголовков запроса):
http://php.net/manual/en/function.session-start.php