Дизайн и безопасность учетной записи пользователя

Question

Прежде чем начать, я использую Ruby on Rails и гем Devise для аутентификации пользователей.

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

Я не знаю, правильно ли я объясняю это, поскольку я не видел сообщения в блоге уже несколько месяцев и потерял свою закладку.

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

Спасибо.

Answer 1

Использование различных моделей для обработки User (модель, которая выполняет базовую аутентификацию) и Account (модель, которая содержит всю информацию о , что пользователь может сделать, как , .. .) может дать вам плюс:

1. хранение данных пользователя с использованием системы вторичного хранения, обеспечивающей более высокий уровень безопасности
2. ограничение доступа пользователя к данным другими артефактами приложения (моделями, контроллерами и т. Д.)
3. упрощение проверки кода и аудита безопасности

Я склонен добавлять личные данные (настоящее имя, номер телефона и т. Д.) В модель «Пользователь», в то же время раскрывая оперативные данные о пользователе в модели «Учетная запись» (псевдоним, биография, ...).

Answer 2

Что ж, выглядит хорошим архитектурным решением сохранить эти модели отдельно, потому что они относятся к разным объектам: Модель пользователя принадлежит системе авторизации, а модель Account принадлежит профилю пользователя. система управления. Но все зависит. Если ваши модели действительно крошечные (скажем, 3-5 полей каждая), вы, вероятно, не получите никаких преимуществ от такого разделения, кроме дополнительной головной боли. Но если ваши модели большие и, скажем, модель Пользователь будет использоваться гораздо чаще - тогда вам следует подумать о реализации различных моделей для ясности и производительности.