Стоит ли использовать встроенную профильную систему ASP.Net?

Question

Я только что обнаружил, что ASP.net использует свою собственную систему профилей для регистрации пользователей, и, похоже, в качестве бонуса доступно множество функций (таких как безопасная аутентификация).Однако кажется довольно специфичным иметь такую ​​функцию для среды разработки общего назначения и вещей, которые работают в фоновом режиме, как система профилей, и я не знаю, как (например, где хранятся пользовательские данные) меня пугает.

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

Моя любимая вещь в профилях - вы можете создавать собственные разрешения в файлах Web.config, используя их (), и избегать необходимости вводить один и тот же код в верхней части всех ваших исходных файлов aspx для выполнения аутентификации.check.

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

Но это не так кажется, что действительно большая сделка.Я просто не понимаю, как обстоят дела с профилями в разработке ASP.Net и для чего они предназначены.

Answer 1

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

Мои потребности не соответствовали предоставленным API, и мне действительно нужна была только часть Членства. Проблема в том, что у меня был кусок, где мне нужно было использовать одинаковую аутентификацию и авторизацию для веб-приложения и настольного приложения. Мои потребности довольно уникальны, но они предназначены для классной комнаты.

Получить членство, чтобы работать для моих нужд не было так сложно. Я просто должен был реализовать API членства. Есть несколько функций, которые мне просто не нужны в API-интерфейсе членства, такие как самостоятельная регистрация и т. Д. Конечно, это поставило меня перед задачей управления ролями. Как правило, если ваш пользовательский объект реализует IPrinciple, его можно использовать напрямую, но существуют проблемы с сериализацией пакетов Visual Studio веб-сервера разработки, если ваш пользовательский класс не определен в той же сборке. Эти проблемы связаны с сериализацией, и ваш выбор включает помещение объекта в GAC или ручную сериализацию между доменами самостоятельно с объектами в GAC, такими как GenericPrincipal и GenericIdentity. Этот последний вариант - то, что я должен был сделать.

Суть в том, что если вы не возражаете против того, чтобы API выполнял все управление за вас, то он будет работать просто отлично. Это немного умная инженерная работа, и она пытается сбить вас с пути приличных мер безопасности. Я работал с несколькими различными API-интерфейсами аутентификации / авторизации (большинство из которых не основаны на CLR), и API действительно немного ограничен. Однако, если вы хотите избежать ловушек с управлением сессиями / состоянием / кэшем, вам действительно нужно использовать API и подключать своих собственных провайдеров по мере необходимости.

В вашей базе данных, если вам нужно связать пользователя с каким-либо элементом базы данных, вы сохраните идентификатор входа пользователя (Context.User.Identity.Name).

Answer 2

Вы, похоже, перепутали API поставщика профиля / членства / роли.Но чтобы ответить на ваш вопрос: почему бы не использовать его?Я бы использовал его, если нет реального ограничения, которое делает его непригодным для использования ...