Вам нужны пользователи и роли, т. Е. Вы хотите аутентифицировать пользователей и авторизовать их с привилегиями, используя роли. Я очень рекомендую не кататься самостоятельно, как в PHP. Вместо этого я рекомендую использовать .NET-провайдеры. В частности, MembershipProvider (для аутентификации) и RoleProvider (для авторизации).
Вы по-прежнему можете использовать провайдеров со своими собственными БД, они не являются эксклюзивными или эксклюзивными с кодом в первую очередь. Тем не менее, я бы порекомендовал НЕ хранить пользовательскую информацию о приложении в таблицах пользователей или членов Поставщика. Вместо этого вы можете иметь свой собственный код сначала User и связать его с системой членства через имя пользователя.
Причина, по которой я рекомендую это, заключается в том, что это уменьшает объем работы, которую вы должны выполнить. Вам не нужно беспокоиться о шифровании или хешировании паролей - поставщик сделает это за вас. У вас есть полный API для управления вашими пользователями и ролями через пространство имен System.Web.Security.
Что касается Profile s, это отдельная услуга провайдера, которую вам не нужно использовать. Это позволяет вам хранить информацию о пользователях, независимо от того, зарегистрированы ли они для учетной записи пользователя в вашей системе. Технически вы можете иметь «анонимных пользователей», но любой, кто создал логин на основе пароля, вместо этого упоминается как «участник».
Что касается файлов cookie, аутентификация пользователя в .NET осуществляется через класс FormsAuthentication. После того как вы аутентифицировали пользователя, используя System.Web.Security.Membership, вы можете позвонить FormsAuthentication.SetAuthCookie, чтобы написать его куки аутентификации. Это полностью интегрирует как User, так и их Roles в свойство Controller.User, которое реализует интерфейс IPrincipal. Вы можете использовать этот объект, чтобы получить имя пользователя и выяснить, в каких ролях он играет.
Ответ на комментарий
I ответил на очень похожий вопрос здесь . По сути, это зависит от вас, иметь ли членство в совершенно отдельной базе данных, чем ваше приложение, но я считаю, что это хорошая практика, потому что я сделал это совсем немного, и у меня нет претензий. Особенно, если вы сначала используете код, так как вы можете потерять всю БД, если используете инициализаторы DropCreateDatabaseIfModelChanges или DropCreateDatabaseAlways.
Также существует новый поставщик членства. Я думаю, что пакет NuGet называется «Универсальные провайдеры ASP.NET», и они находятся в пространстве имен System.Web.Providers вместо старого пространства имен System.Web.Security. У меня еще не было возможности поработать с ними, но, насколько я понимаю, они в первую очередь более совместимы с кодом. Во-первых, таблицы не названы как aspnet_Foo, и в БД нет представлений или хранимых процедур. Имена таблиц обычные dbo.Users, dbo.Roles и т. Д.
Что касается связывания пользователей провайдера с сущностями пользователя вашего приложения (контента), см. Ответ, на который я ссылался выше. Самый простой способ сделать это - просто указать в вашей базе данных поле для UserName и связать его с базой данных поставщика UserName. Внешние ключи не нужны, поскольку вы интегрируете их на уровне приложения, а не на уровне базы данных.