Представление и сохранение пользователей (которые входят в систему с именем пользователя и паролем И социальными логинами) в базе данных (MySQL)

Я использую Play Framework (v2.2.x), SecureSocial (v2.1.3) и scala (v2.10) для создания шаблона входа в игровые приложения. Я хочу, чтобы шаблон входа поддерживал как вход в социальные сети (Twitter, Facebook, Github и т. д.), так и вход в систему с помощью имени пользователя и пароля. Мне трудно представлять оба типа пользователей (социальных и локальных) для настойчивости.

Я использую MySQL (v 5.6.x) в качестве моей базы данных и squeryl (v0.9.6) в качестве ORM для сохранения.

Мне нужна помощь в моделировании как SocialUser, так и LocalUser (аутентификация пользователей с использованием имени пользователя и пароля) для сохранения.

Я просмотрел https://github.com/jaliss/securesocial/tree/master/samples/scala/demo. У меня запущена эта демонстрация (с дополнительной настройкой для mysql и squeryl. Кроме того, этот пример расширен для работы с Facebook и Github).

Я еще не написал никакого кода, но планировал моделировать следующим образом:

Класс пользователя:

+-------------------+---------------+------------+---------------+-------------+-------------+-----------+
| provider_user_id  | providerType  |    email   |   avatarUrl   | passwordInfo| oauth1Info  | oauth2Info|
+-------------------+---------------+------------+---------------+-------------+-------------+-----------+

Аутпровидерфорусер:

+-------------------+----------------------+--------------+
| provider_user_id  | application_user_id  | providerType |
+-------------------+----------------------+--------------+

Класс токена:

+------+--------+---------------+-----------------+-----------+------------+
| uuid |  email |  creationTime |  expirationTime |  isSignUp |  isExpired |
+------+--------+---------------+-----------------+-----------+------------+

В UserService я должен просто получить информацию из этих моделей, подготовить экземпляр удостоверения и вернуть/использовать его?

OR

Мне лучше иметь один класс User (класс SocialUser) с чертой Identity и сохранять его?

Вы можете думать об этом как о расширении для https://stackoverflow.com/a/16389116/2343569. В принципе, с точки зрения дизайна, лучше ли сохранить PlatformUser или разбить PlatformUser на классы (например, User и AuthProviderForUser), а затем сохранить их?

Какой вариант лучше? Любое другое предложение?


mysql scala playframework-2.0 securesocial
person Abhishek Shukla Ravishankara    schedule 04.03.2014    source источник
comment
Что у вас есть до сих пор? Покажи код...   -  person yǝsʞǝla    schedule 04.03.2014
comment
Я отредактировал вопрос с некоторой дополнительной информацией   -  person Abhishek Shukla Ravishankara    schedule 04.03.2014

Ответы (1)


arrow_upward
1
arrow_downward

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

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

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

Сказав, что если вы будете использовать, например, MongoDB, которая позволяет довольно легко вставлять документы (строки), вы можете обсудить, следует ли хранить данные пользователя и аутентификации как единый объект/строку/документ в БД. Даже в этом случае оба варианта, на мой взгляд, будут иметь одинаковое предпочтение. Но так как вы храните данные в реляционной БД - MySQL, вы обязательно должны нормализовать их в разумных пределах, и разбить их на 2 таблицы - лучший вариант.

person yǝsʞǝla    schedule 04.03.2014