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

Question

Я создаю мобильное приложение и сервисную службу ServiceStack. Материалы аутентификации в ServiceStack выглядят великолепно, но легко теряются в своей гибкости - руководство очень ценится. Я буду использовать свои собственные таблицы db для хранения пользователей и т. Д. В веб-службе. Я хотел бы иметь процесс регистрации и последующей аутентификации что-то вроде этого:

• пользователь изначально содержит только адрес электронной почты, мой веб-сервиса, то электронные почты ключ регистрации пользователю
• пользователь вводит ключ , Приложение отправляет на веб-службу для регистрации: email, key & уникальный идентификатор устройства.
• веб-сервис проверяет ключ и сохраняет адрес электронной почты &. Он откликается на токен аутентификации, который приложение будет использовать для последующей аутентификации.

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

Вопрос 1: Должен ли я подключиться к API регистрации ServiceStack или добавить несколько пользовательских вызовов веб-сервисов? например без регистрации ServiceStack я бы:

• Опубликовать в веб-службу регистрации с адресом электронной почты и идентификатором устройства. Мой веб-сервис отправит регистрационное письмо с ключом и добавит запись в таблицу пользователя db.
• Когда пользователь вводит ключ, он снова отправляется на веб-службу регистрации, на этот раз также с ключом. Мой веб-сервис будет проверять ключ и обновлять таблицу пользователя, помеченную пользователем как зарегистрированную, создавая и записывая токен аутентификации &, возвращая его вызывающему абоненту
• последующие запросы будут отправляться с использованием http basic auth с идентификатором устройства как имя пользователя и auth token как пароль. Служба не очень чата, поэтому с каждого запроса будут отправляться запросы.
• Я реализую CredentialsAuthProvider, который получит creds с httpRequest.GetBasicAuthUserAndPassword() и проверит их против данных db.

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

Вопрос 2: Что случилось с передачей данных аутентификации с каждым запросом? Это упростило бы составление моих запросов приложений, но это не кажется «выполненным» на основе примеров ServiceStack. Предположительно, это потому, что это неэффективно, если у вас много запросов на повторную аутентификацию каждого звонка - по каким-либо другим причинам? Мое приложение будет делать только один веб-запрос максимум каждые несколько минут, поэтому кажется, что проще избегать сеансов и просто повторять каждый запрос.

Вопрос 3: Я нахожусь на правильной дорожке подклассификации CredentialsAuthProvider?

Вопрос 4: Есть ли смысл использовать токен auth для генерации хэша вместо отправки токена auth каждый раз? Все сообщения будут превышать https.

Answer 1

Ответ 1: Все будет в порядке. если вы даете множественный вызов согласно требованию. Обычно аутентификация работает на основе cookie, теперь вы можете хранить ее на клиенте и/или на сервере и сопоставлять с ней пользователя. Опять же здесь, если вы используете устройство, вы всегда можете использовать устройство вместо пользователя для сопоставления и аутентификации пользователя. Исходя из вашего требования.

Я предпочту использовать поставщика, поскольку он скрывает многие детали, которые вам нужно сделать вручную. Вы на правильном пути. Существует множество блогов, специально предназначенных для аутентификации, и способов создания пользовательской проверки подлинности с помощью стека служб. Если вам нравится, дайте мне знать, что у меня есть книга, которую некоторые могут вам дать. Лучший способ поиска последних - проверка учетной записи Twitter на Servicestack.

Ответ2: Это снова, я говорю, согласно требованию. Теперь, если ваш пользователь будет только в зоне WIFI. (В основном это верно для бизнес-пользователей), то для вызовов нет ограничений. Просто дайте API-запрос и выполните проверку подлинности в фоновом режиме. Простой токен JSON не повредит, это всего лишь несколько байтов. Но опять же, если у вас есть большая пользовательская база, которая не использует хорошее интернет-соединение, тогда будет лучше хранить данные аутентификации на устройстве и проверить на это. Просто для сохранения сетевого вызова. В любом случае сетевой вызов тяжелый ресурс.

Ответ3: Да, вы на правильном пути. Все еще проверяйте записи в блогах для более подробной информации. Я не помню фрагмент кода и то, как он работает с последним обновлением, поэтому я не размещаю код здесь.

Ответ4: Ответ на этот вопрос немного сложный. Передача данных по https и сохранение пользователя от мошенничества с идентификацией - это совсем другое. Теперь, если вы не создаете токен аутентификации (значение хэша), вы можете передать пользователя также через http или https. Теперь это может использоваться другим пользователем для издевки первого пользователя и отправки данных. Даже данные передаются через https, но все же данные обманываются. Значение хэширования используется для предотвращения этой ситуации. А также есть несколько других случаев использования бизнеса, которые могут быть покрыты с помощью токена auth.

Пожалуйста, дайте мне знать, правильно ли вы поняли вопросы и ответили им ?? или Если требуется какая-либо дополнительная информация?