Используйте идентификатор asp.net на бизнес-уровне и добавьте свойства

Я создаю финансовое приложение. Я использую идентификатор asp.net. Когда пользователь входит в систему, он просто видит записи своей компании. У меня есть GetRecords (int userID), он возвращает все записи для компании пользователя.

public List<FinanceData> GetRecords(int userID){
       int companyID = userService.GetCompanyID(userID);
       financeService.GetFinanceData(companyID);
 }

Мои вопросы:

1- На уровне asp.net mvc я могу достичь User.Identity.Name, но на бизнес-уровне (класс lib.) Я не могу получить доступ к этому свойству данных. Как этого достичь?

2- Могу ли я добавить такие свойства, как User.Identity.CompanyID, и как я могу заполнить его, когда пользователь входит в систему. Потому что я не хочу обращаться к базе данных для каждого запроса.

Я хочу использовать свой метод так:

public List<FinanceData> GetRecords(){
         financeService.GetFinanceData(User.Identity.CompanyID);
     }

c# asp.net asp.net-mvc asp.net-identity
person user1924375    schedule 25.03.2015    source источник
comment
Невозможно добиться этого, не обращаясь к базе данных. Только определенные данные пользователя извлекаются при аутентификации. Каждый раз нужно будет запрашивать что-то вроде CompanyID. Даже использование утверждений требует повторного запроса к базе данных для получения претензий.   -  person Chris Pratt    schedule 25.03.2015
comment
@ChrisPratt, это неправда   -  person MichaC    schedule 25.03.2015
comment
Извините, но это так. На самом деле они хранятся в базе данных, и для Entity Framework есть расширения Identity, которые извлекают их из базы данных. Используйте что-то вроде Glimpse для отслеживания запросов, отправляемых к базе данных, когда вы используете утверждения. Вы увидите, как появятся запросы.   -  person Chris Pratt    schedule 25.03.2015

Ответы (1)


arrow_upward
4
arrow_downward

Удостоверение Asp.net использует утверждения для хранения информации о пользователе, эта модель очень гибкая, и вы можете полностью добавлять в нее собственные утверждения, например CompanyId. Вам нужно будет реализовать это в вашем ApplicationUser или там, где когда-либо будет создан ClaimsIdentity, и добавить к нему свои собственные утверждения.

(следующий код скопирован из шаблона MVC)

public class ApplicationUser : IdentityUser
{
    public async Task<ClaimsIdentity> GenerateUserIdentityAsync(UserManager<ApplicationUser> manager)
    {
        // Note the authenticationType must match the one defined in CookieAuthenticationOptions.AuthenticationType
        var userIdentity = await manager.CreateIdentityAsync(this, DefaultAuthenticationTypes.ApplicationCookie);
        // **Add custom user claims here**
        return userIdentity;
    }
}

Тогда ClaimsPrincipal будет доступен через Thread.CurrentPrinciapl везде в вашем приложении, которое работает в том же домене приложений. Поэтому, если ваш другой уровень не работает как служба где-то еще, вы можете полностью использовать

var principal = Thread.CurrentPrincipal as ClaimsPrincipal

проверьте, не является ли он нулевым и аутентифицирован ли он, и все будет в порядке.

Чтобы сделать его еще более удобным, вы можете написать методы расширения для ClaimsPrincipal, например, для .CompanyId.

person MichaC    schedule 25.03.2015
comment
Утверждения можно использовать для хранения дополнительной информации о пользователях, но на практике я не думаю, что это хороший подход. Поскольку фактический пользовательский объект является расширяемым в Identity, вам лучше просто добавить к нему дополнительные свойства. Единственная информация, которую я храню в заявках пользователей, временна, как токен аутентификации Facebook - это то, что не применимо к каждому пользователю, не нуждается в открытии для редактирования (например, в представлении профиля пользователя) и может иметь определенный Фактор срока службы или устаревания. - person Chris Pratt; 25.03.2015
comment
Что ж, вы можете сохранить в заявке все, что вы не хотите каждый раз запрашивать из базы данных. Таким образом, вы можете работать с текущим аутентифицированным пользователем, не получая снова и снова дополнительную информацию на всех уровнях вашего приложения. Мы используем его, например, для хранения ролей, что довольно удобно. Конечно, вы не должны хранить там все ... все эти данные могут оказаться в файле cookie, если вы используете cookie auth ^^ - person MichaC; 25.03.2015
comment
Эмм ... Нет. Не уверен, что, по вашему мнению, происходит с претензиями, но они запрашиваются из базы данных каждый раз, когда вы их отправляете. Они как-то не сохраняются между запросами. - person Chris Pratt; 25.03.2015
comment
Нет, они не каждый раз запрашиваются из базы данных, вот какие претензии справедливы? Должен хранить простую информацию о пользователе вместе с защищенным сеансом. Так, если вы, например, используете cookie auth, пока cookie действителен и каждый запрос на вашем веб-сайте получает cookie, этот cookie будет источником данных пользователя, а база данных будет доступна только для проверки токена проверки. Например. Вы можете легко проверить это, создав пустую страницу MVC 5 со сгенерированным логином и т. Д. И поставив точку останова в GenerateUserIdentityAsync и посмотрите, как часто этот парень вызывается. - person MichaC; 25.03.2015