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