Дизайн аутентификации пользователя, пользователи люди?

Question

Приложение написано на Ruby on Rails, но проблема, с которой я сталкиваюсь, больше связана с дизайном, чем с языком.

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

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

Вопрос в том, как провести рефакторинг приложения, чтобы разрешить это новое требование в?

Одним из простых решений является создание пользователей для каждого человека, которые запрашивают учетные данные для входа и связывают пользователя с объектом, но это не очень СУХО, поскольку некоторые поля, такие как имя, фамилия и т. Д., Относятся к обоим классам и, в частности, именно данные люди смогут изменить. Кроме того, Пользователь и Персона хранятся в отдельных таблицах.

Другая возможность, которую я рассматривал, состоит в том, чтобы заставить одну расширять другую, но наличие данных в отдельных таблицах делает его немного беспорядочным. Кроме того, логическим расширением будет User <- Person, поскольку пользователь (как правило) - это человек, но размышлять над реализацией Person <- User намного проще. </p>

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

Можете ли вы придумать лучшее решение?

Answer 1

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

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

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

Вам необходимо некоторое отслеживание между возможными "правами" и ролью, которую выполняет пользователь. Например. простейшей настройкой может быть Identity или роль с некоторыми логическими свойствами can_edit_profile или can_modify_registry.

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

Для вашего приложения это может включать добавление свойства can_change_registry для ваших пользовательских объектов и проверку, является ли это свойство True для любого кода, обращающегося к этой части сайта.