Роль аутентификации — Чистая архитектура

#android #mvvm #kotlin #clean-architecture

#Android #mvvm #kotlin #чистая архитектура

Вопрос:

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

В моем приложении есть такая структура (слои): [пользовательский интерфейс] (действия и фрагменты) -> [презентация] (модели просмотра) -> [домен] (вариант использования) -> данные -> [удаленный, кэш, база данных].

Теперь давайте предположим, что я хочу войти в свое приложение, сначала я пройду через экран входа в систему и введу учетные данные пользователей, после этого я вызову LoginViewModel, а затем LoginUseCase, передав адрес электронной почты и пароль. В свою очередь, вариант использования вызовет репозиторий, скажем, для аутентификации, а затем я отправлю запрос на серверную часть с учетными данными, если все в порядке, тогда я получу обратно токен, который я должен каким-то образом сохранить, проблема начинается здесь, я создал перехватчик, который отвечает за получение токена из заголовка, но я должен сохранить его, и для этого мне нужно получить доступ к общим настройкам, правильно ли иметь доступ к нему внутри моего перехватчика? И в каждом запросе мне приходилось отправлять его на свой серверный сервер, какой подход лучше всего?

Я также видел это руководство https://medium.com/@tsaha.cse/advanced-retrofit2-part-2-authorization-handling-ea1431cb86be но я думаю, что неправильно иметь доступ к базе данных внутри вашего класса приложения, я не прав?

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

Комментарии:

1. Возможно ли вернуть новый токен из класса ответа Retrofit? Если да, в модуле репозитория, который предназначен для получения результата модернизации сети, мы можем сохранить такой токен в модуле кэша.

Ответ №1:

на самом деле это не связано с CleanArchitecture . Вот ответы на ваши вопросы:

  1. Я должен сохранить ее, и для этого мне нужно получить доступ к общим настройкам, правильно ли иметь к ней доступ внутри моего перехватчика?

-> Да, вы должны сохранить это в SharedPreferences , но вы не должны получать доступ SharedPreferences к своему interceptor . Вы должны создать свой interceptor синглтон и новую setHeaderToken(String token) функцию в своем interceptor . После авторизации вы можете установить токен заголовка на свой interceptor . Что-то вроде:

 class MyInterceptor{
    String token = null;
    public void setHeaderToken(String token){
         //do set...
    };
    @Override
    public Response intercept(Chain chain) throws IOException {
         if(token == null) //do nothing
         else // do add header
    }
}

// add the singleton Interceptor to your OkHttp Client Builder and use it.
  
  1. Вам не следует напрямую подключать класс приложения к вашей базе данных. Для этого вам следует использовать уровень домена.

Комментарии:

1. Спасибо за ваш ответ, но вопрос в том, как я могу сохранить токен в общих настройках, если я не могу разместить его внутри перехватчика?

2. @Boni не уверен, что ты имеешь в виду. Вместо этого вам следует сохранить токен в общих настройках в вашем token API.

3. Что вы подразумеваете под «в вашем token API», извините, что беспокою вас этим, но мне трудно найти способ решить это