Как переопределить аутентификацию для определенных веб-страниц ....? - PullRequest
Новая
       32

Как переопределить аутентификацию для определенных веб-страниц ....?

0 голосов
/ 04 мая 2011

Ну, у меня следующий код, написанный на главной странице: - 

<authentication mode="Forms">
    <forms loginUrl="Loginpage.aspx" />
</authentication>

Теперь он будет перенаправлен на «Loginpage.aspx», если аутентификация не удалась.

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

Есть ли способ переопределить аутентификацию для нескольких страниц aspx?

-Anil

Ответы [ 3 ]

3 голосов
/ 04 мая 2011

Ответ Хенрика хороший и должен работать, если правильно реализован. Тем не менее, это еще один вариант, который решает проблему более с точки зрения конфигурации. Я знаю, что вы упомянули, что вы не будете знать имена страниц заранее, поэтому вы не можете включить запись в web.config для каждой страницы, НО web.config также позволяет вам защищать папки. Вы можете разместить все страницы, требующие аутентификации, в папке с именем «AuthRequired», а все страницы, которые не требуют аутентификации, размещать, например, в папке с именем «Anonymous». Тогда в вашей веб-конфигурации у вас могут быть следующие записи: 

<location path="AuthRequired">
  <system.web>
    <authorization>
      <deny users="?" />
      <allow users="*" />
    </authorization>
  </system.web>
</location>
<location path="Anonymous">
  <system.web>
    <authorization>
      <allow users="*" />
    </authorization>
  </system.web>
</location>
1 голос
/ 04 мая 2011

Вы можете прослушать событие AuthorizeRequest и действовать соответственно.Для этого создайте свой собственный Http-модуль.

Три варианта:

  • используйте указанные выше параметры конфигурации вместе с созданием папок с записями web.config.Это довольно скудный способ сделать это.

  • прослушать событие AuthenticateRequest, код выглядит примерно так: 

    public class UserAuthenticationModule : IHttpModule
{
private HttpApplication _Context;
private RoleManagerModule _RoleManager;

public void Init(HttpApplication context)
{
    _Context = context;
    context.AuthenticateRequest += AuthenticateUser;
    _RoleManager = (RoleManagerModule)context.Modules["RoleManager"];
    _RoleManager.GetRoles += roleManager_GetRoles;
}

// /1087947/kak-sohranit-roleprovider-ot-pereopredeleniya-polzovatelskih-rolei
private void roleManager_GetRoles(object sender, RoleManagerEventArgs e)
{
    if (_Context.User is UserPrincipal)
        e.RolesPopulated = true; // allows roles set in AuthenticateUser to stick.
}

private static void AuthenticateUser(object sender, EventArgs e)
{
    var app = (HttpApplication) sender;
    if (app.Context == null) return;

    var user = app.Context.User;

    // not signed in, forms authentication module takes care of redirecting etc.
    if (user == null) return;
    // we're done then.
    if (user is IUser) return;

    var userEntity = IoC.Resolve<IUserRepository>().FindByUserName(user.Identity.Name);

    // we can't find the user in the database.
    if (userEntity == null)
        throw new ApplicationException(string.Format("User \"{0}\" deleted from, or renamed in, database while logged into application.", 
            user.Identity.Name));

    // signed in, assigning user, which should assign Thread.CurrentPrincipal as well (it wouldn't do this on PostAuthenticateRequest).
    app.Context.User = new UserPrincipal(userEntity);
    userEntity.SetAuthenticated();
}

//Implement IDisposable.
public void Dispose()
{
}
}

Если ваш UserPrincipal реализует IPrincipal, то IsInRole используется для предоставления доступа к вашим страницам на основе ролей.

  • Сервис-ориентированный способ;настроить небольшой прозрачный прокси-сервер.Перечислите свои конечные точки / uri-ы в динамическом хранилище, как то, что вы описываете.Настройте службу авторизации, такую ​​как Rhino Security;выставить свои сервисные интерфейсы как REST-API или интерфейс запроса / ответа или что-то еще.Предположим, с точки зрения веб-приложения, что каждый запрос разрешен, и позаботьтесь о том, куда вы перенаправляете.На прокси-сервере, например, nginx, который является очень хорошим асинхронным прокси-сервером на основе C в Linux, вызовите службу авторизации из фильтра / модуля.«Глубокая безопасность», и вы можете поделиться настройкой безопасности в службе авторизации.

Принцип, которым вы следуете, заключается в том, что если что-то не разрешено в веб-приложении, вы делаете throw new HttpException(405, "The current operation you are trying to perform is now allowed for your role or user or chosen path in life")в событии AuthorizeRequest. Обратите внимание, что есть AuthenticateRequest и другое событие AuthorizeRequest

0 голосов
/ 05 мая 2011

У вас обычно должно быть один балл, где пользователи могут быть аутентифицированными - получите подтверждение того, что они являются теми, кем они себя считают. Далее, вы, вероятно, говорите о авторизации , которая заключается в том, чтобы разрешить / запретить выполнение определенной операции для пользователя, такой как отправка запроса GET. Правила авторизации в простых сценариях могут быть настроены в web.config через элемент location , представленный Томом.

...