Блог

Я пытаюсь создать приложение для IOS с интерфейсом, закодированным на swift, и обратно на python, используя api rest django. У меня есть контроллер панели вкладок, настроенный с двумя вкладками, одна из которых в конечном итоге подключена к контроллеру HomeViewController. Я использовал FirebaseAuth, в котором я обычно использовал бы функцию firebase, которая выглядела примерно так

 if firebase.Auth.currentUser != nil {
   let vc = HomeViewController()
   present(vc, animated:True)
}
 

Однако, насколько мне известно, rest api django не имеет такой функции, и поэтому я застрял на несколько часов, пытаясь понять это.
В настоящее время я планирую использовать кэшированный токен доступа, полученный при регистрации/входе в систему, и отправить запрос get, который возвращает информацию о пользователях. (имя пользователя и адрес электронной почты). Затем создайте функцию для декодирования данных, которая возвращает логическое значение.
Я планирую создать структуру

 struct AuthenticatedUser: Codable, Hashable {
let username: String
let email: String
}
 

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

 if decodeData == false {
   let vc = HomeViewController()
   present(vc, animated:True)
}
 

Я уверен, что это сработает, но даже как новичок в программировании я могу сказать, что этот код кажется давним, запутанным и, скорее всего, считается плохим кодом.
Мне было интересно, у кого-нибудь есть какие-либо улучшения/новые методы (предпочтительно новые методы) для борьбы с этой проблемой.
Любая помощь будет очень признательна!

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

Механизм, необходимый для выполнения этой работы, может быть полностью прозрачно встроен в «код клиентской сети», и вашим представлениям и другим частям вашего приложения, которые выполняют «защищенный доступ к данным», не нужно ничего знать о схеме входа в систему или о том, зарегистрирован ли пользователь или вошел в систему.

В любом случае, что такое вход в систему?

Что зарегистрировано?

Что такое пользователь?

Предполагая, что вы используете более распространенные схемы входа в систему (OpenID Connect или пользовательскую схему, основанную на OAuth), которая основана на аутентификации пользователя, согласии пользователя и токене на предъявителя, на эти вопросы можно ответить следующим образом:

Пользователь, представляющий собой структуру, содержащую некоторые данные о реальном пользователе, — это личность, которая была успешно аутентифицирована. Эта информация доступна после аутентификации и авторизации пользователя, которые обычно являются первыми двумя шагами в потоке «регистрация пользователя». Это может произойти на стороннем поставщике удостоверений, но также может быть включено в ваш сервер домена.

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

Пользователь также может «отменить регистрацию», и его личные данные, и особенно запись «пользователь» на сервере домена, будут удалены или помечены как «незарегистрированные».

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

Теперь сразу должно стать ясно, что при наличии определенного приложения на определенном устройстве и просто путем запроса локального состояния приложение никогда не сможет априори определить, зарегистрирован пользователь или нет, даже если у приложения есть информация о пользователе.

Теперь предположим, что в приложении есть информация о «текущем пользователе» и что пользователь зарегистрирован, но еще не «вошел в систему».

Вход в систему означает, что приложение получает токен обновления и токен доступа. Маркер доступа — это ключ для доступа к защищенным пользовательским ресурсам. При этом информация о пользователе не требуется, маркер доступа неявно связан с этим пользователем.

Токен обновления действует как ключ для получения нового токена доступа, срок действия которого намного больше, возможно, довольно длительный, так что он буквально никогда не истекает (не рекомендуется).

Срок действия токена доступа обычно исчисляется минутами. Таким образом, довольно часто срок действия токена доступа истекает все время.

Маркер доступа потребуется при доступе к защищенному ресурсу, поэтому он будет необходим для каждого защищенного доступа.

Когда срок его действия истекает, сервер отправляет очень конкретный однозначный код состояния. Таким образом, ваш клиентский код может действовать соответствующим образом, что означает:

1. поместите запрос в очередь
2. используйте токен обновления и запросите новый токен доступа на определенной конечной точке с токеном обновления
3. Повторите запрос с обновленным маркером доступа

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

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

В этом случае понятно, что делать:

1. Потребуйте, чтобы пользователь снова вошел в систему
2. Первый шаг возвращает токен обновления области, а также токен доступа
3. Повторите запрос.

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

В идеале этот поток «повторный вход» может быть перенесен поверх любого другого потока, который получает доступ к защищенному ресурсу. В качестве альтернативы, просто позвольте запросу на токен обновления завершиться неудачно, не открывая поток входа, показывая четкое сообщение об ошибке, намекающее на то, что пользователю необходимо снова войти в систему.

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

Все это должно быть реализовано в коде клиентской сети. Удачи! 😉