независимые аутентифицированные сеансы с ASP.NET MVC 2 и областями - PullRequest
Новая
       21

независимые аутентифицированные сеансы с ASP.NET MVC 2 и областями

0 голосов
/ 31 августа 2011

Я занимаюсь разработкой небольшого веб-сайта CMS (область интерфейса), где пользователи могут видеть новости, исследовать продукты и т. Д. и на том же сайте у меня есть бэкэнд-область, где управляются контент и функции ERP CMS, это только для сотрудников компании Итак, мой сайт разделен на 2 области: http://WEBSITEURL/Frontend/ и http://WEBSITEURL/Backend/

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

Я бы использовал атрибут Authorize в моих контроллерах, но я хочу знать, возможно ли иметь и поддерживать аутентификацию в сеансе 2

я хочу иметь ОДИН проект mvc, а не 2, один для внешнего интерфейса, а другой для внутреннего

1 Ответ

1 голос
/ 01 сентября 2011

Нет, вам не нужно заново изобретать MembershipProvider. Вам также не нужно заново изобретать аутентификацию форм. На самом деле, вы не должны. Правильное обеспечение безопасности невероятно сложно, даже для экспертов. Будет ли ваш новый провайдер уязвим для атаки оракула, как встроенные провайдеры были ?

Давайте сделаем один шаг за раз.

Во-первых, чтобы иметь отдельные билеты аутентификации (куки) для каждой области, вы используете перегрузку SetAuthCookie, которая позволяет вам указать путь к куки. Установите путь для каждого куки, чтобы браузер отправляет только правильный файл cookie для каждой области на основе корня пути URI (Frontend/ или Backend/, в вашем случае).

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

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

Что касается «аутентификации» в хранилище, не путайте аутентификацию и авторизацию. Аутентификация означает "кто ты?" Пусть формы auth делают это. Авторизация означает "что тебе разрешено делать?" Здесь вы проверяете свои репозитории.

Итак, в конце концов, вы будете делать что-то вроде этого в области персонала / бэкэнда: 

    [HttpPost]
    public ActionResult LogOn(LogOnModel model, string returnUrl)
    {
        if (ModelState.IsValid)
        {
            if (Membership.ValidateUser(model.UserName, model.Password))
            {
                if (StaffRepository.AuthorizedUser(model.UserName))
                {
                    FormsAuthentication.SetAuthCookie(model.UserName, model.RememberMe, pathForBackend);
                    return RedirectTo....
                }
                else
                {
                    return MyUnauthorizedAction();
                }
            }
...