role based security - перехватить неавторизованный доступ
От: Аноним  
Дата: 21.07.05 16:00
Оценка:
Добрый день.

Вероятно, простой вопрос. В приложении используется forms authentication + role based security. В случае, если уже залогиненный пользователь запрашивает ресурс, к которому его роль не имеет доступа (например, вручную набрав в адресной строке браузера url страницы), его выкидывает обратно на login page.

Я хочу перехватывать отказ в доступе и вместо редиректа на login page показывать пользователю собственное сообщение (что-нибудь в духе "недостаточно прав для доступа к ресурсу").

Как правильно это делается?

Пока вижу следующий вариант: при загрузке login.aspx проверять, если это redirect, и пользователь аутентифицирован и выставлена роль, то делать вывод, что редирект произошел вследствии попытки доступа к ресурсу, куда прав нет. Правильно ли это?

Спасибо,
Игорь
Re: role based security - перехватить неавторизованный досту
От: Козьма Прутков Россия  
Дата: 22.07.05 05:50
Оценка:
Здравствуйте, Аноним, Вы писали:

А>Добрый день.


А>Вероятно, простой вопрос. В приложении используется forms authentication + role based security. В случае, если уже залогиненный пользователь запрашивает ресурс, к которому его роль не имеет доступа (например, вручную набрав в адресной строке браузера url страницы), его выкидывает обратно на login page.


так, стоп, если его бросает на логин, то значит пользователь не залогинен. Отказ в доступе так действовать не лдолжен. Каким образом ты разделяешь доступ? Плюс версию FW плиз.

А>Пока вижу следующий вариант: при загрузке login.aspx проверять, если это redirect, и пользователь аутентифицирован и выставлена роль, то делать вывод, что редирект произошел вследствии попытки доступа к ресурсу, куда прав нет. Правильно ли это?


скорее всего нет, это подпорка а не решение...
Да хранит вас господь в сухом прохладном месте...
Re[2]: role based security - перехватить неавторизованный до
От: Аноним  
Дата: 22.07.05 07:27
Оценка:
КП>так, стоп, если его бросает на логин, то значит пользователь не залогинен. Отказ в доступе так действовать не лдолжен. Каким образом ты разделяешь доступ? Плюс версию FW плиз.

Используется .NET Framework 1.1 SP1. Доступ разделяется следующим образом:

web.config
<authentication mode="Forms"> 
    <forms name="my.authform" loginUrl="login.aspx" />
</authentication>
<authorization>
    <deny users="*" />
</authorization>
...
<location path="login.aspx">
    <system.web><authorization><allow users="*" /></authorization></system.web>
</location>
<location path="logoff.aspx">
    <system.web><authorization><allow users="*" /></authorization></system.web>
</location>    
<location path="default.aspx">
    <system.web><authorization><allow roles="admin,user" /></authorization></system.web>
</location>

<!-- выставляем права на доступ к подпапкам admin и user сайта  -->

<location path="admin">
    <system.web><authorization><allow roles="admin" /></authorization></system.web>
</location>
<location path="user">
    <system.web><authorization><allow roles="admin,user" /></authorization></system.web>
</location>

// login.aspx.cs

// валидация реквизитов пользователя. в случае успеха:

FormsAuthenticationTicket ticket =
  new FormsAuthenticationTicket(1, login, DateTime.Now, DateTime.Now.AddMinutes(30), true,
      // user information, in this case user id and user role (e.g. "123,admin")
      userInfo,
      FormsAuthentication.FormsCookiePath);

string ticketHash = FormsAuthentication.Encrypt(ticket);
HttpCookie cookie = new HttpCookie(FormsAuthentication.FormsCookieName, ticketHash);

Response.Cookies.Add(cookie);
Response.Redirect(returnUrl);

// global.asax.cs

protected void Application_AuthenticateRequest(Object sender, EventArgs e)
{
    if (HttpContext.Current.User != null)
    {
        if (HttpContext.Current.User.Identity.IsAuthenticated)
        {
            if (HttpContext.Current.User.Identity is FormsIdentity)
            {
                FormsIdentity id = (FormsIdentity)HttpContext.Current.User.Identity;
                FormsAuthenticationTicket ticket = id.Ticket;
                // получаем информацию о пользователе, сохраненную при создании ticket'а на login странице
                string[] userData = ticket.UserData.Split(new char[] {';'});

                long userId = Convert.ToInt64(userData[0]);
                UserRole userRole = (UserRole)Enum.Parse(typeof(UserRole), userData[1], true);
                // подменяем principal на наш CustomPrincipal.
                HttpContext.Current.User = new CustomPrincipal(User.Identity, userId, userRole);
            }
        }
    }
}


На сколько я могу судить, это шаблонное решение для организации role-based security в asp.net, однако если что-то вызывает вопросы -- постараюсь ответить.
Re[3]: role based security - перехватить неавторизованный до
От: Козьма Прутков Россия  
Дата: 22.07.05 10:14
Оценка:
Здравствуйте, Аноним, Вы писали:

Да, похоже, такова реакция FW на статусный код 401... И если для модуля аутентификации это правильное поведение, то для авторизации не очень В принципе, мне кажется вполне нормально будет сделать так (в Global.asax.cs):
protected void Application_EndRequest(Object sender, EventArgs e)
{
    if(
        Context.Response.StatusCode == 401 || 
        Context.Response.StatusCode == 302 && Context.Response.RedirectLocation.IndexOf("ReturnUrl=") > 0
    )
    {
        Response.Redirect("WebForm3.aspx", true);
    }
}


То есть если мы получили код 401 (до того, как его обработал FormsAuthenticationModule, отлично работает с WindowsAuthenticationModule) либо 302 (после того, как FormsAuthenticationModule сделал свое крамольное дело, о чем мы дополнительно выясняем по характерному куску урла, что это не прикладной редирект) мы сами делаем редирект туда, куда нам надо, и прекращаем обработку запроса (чтобы FormsAuthenticationModule не сработал после нас и все не сломал.
Хотя тоже подпорка в своем роде только поуниверсальнее и беготни между клиентом и сервером меньше...
Да хранит вас господь в сухом прохладном месте...
Re[4]: role based security - перехватить неавторизованный до
От: Аноним  
Дата: 22.07.05 15:51
Оценка:
КП>Да, похоже, такова реакция FW на статусный код 401... И если для модуля аутентификации это правильное поведение, то для авторизации не очень В принципе, мне кажется вполне нормально будет сделать так (в Global.asax.cs):

Спасибо, попробую так.
 
Подождите ...
Wait...
Пока на собственное сообщение не было ответов, его можно удалить.