Живое тестирование ASP.NET настраиваемого поставщика ролей - PullRequest
Новая
       35

Живое тестирование ASP.NET настраиваемого поставщика ролей

0 голосов
/ 29 сентября 2018

Использование ASP.NET Webforms + VB / C #

Мне было поручено ограничить доступ к страницам ASP.NET пользователям, не имеющим определенных ролей.И мне нужно иметь возможность протестировать свое решение вживую (в отличие от модульного тестирования, где я мог бы использовать макеты или подделки).Наш сайт довольно сложный, поэтому я сомневаюсь, что смогу найти все «ошибки» только с помощью модульного тестирования.

У меня есть кое-что на моем компьютере для разработки, я уверен, что он будет работать в Production: у меня естьпользовательский поставщик ролей, подключенный к файлу web.config.Он инициализируется и вызывается при отладке веб-сайта, поэтому я уверен, что он работает нормально.У меня есть папка («Администрирование»), помеченная только для конкретной роли.Наши роли определены в нашей собственной базе данных и не связаны с ролями / разрешениями Microsoft или Windows.

Проблема в том, что я не могу войти в систему как пользователь, с которым хочу отлаживать.Я могу «смоделировать» это с помощью специальной только для разработки стартовой страницы.Это работает нормально для наших пунктов меню / навигации, которые построены из базы данных ролей, но, конечно, не ограничивая страницы (с поставщиком ролей или чем-то подобным), вы все равно можете вручную ввести страницу, и она будет отображена.На этой стартовой странице, предназначенной только для разработчиков, имя пользователя, которое я передаю, задается как файл cookie авторизации FormsAuthentation. 

FormsAuthentication.Initialize()
FormsAuthentication.SignOut()
FormsAuthentication.SetAuthCookie(simUserName, True)

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

В любом случае - есть ли способ проверить роли локально во время разработки или нам просто нужно поместить это в производство и надеяться на лучшее.

Я не знал, какой код или настройки будут полезны в настоящее время, поэтому дайте мне знать, что вам нужно.Спасибо!

1 Ответ

0 голосов
/ 04 октября 2018

Я думаю, что нашел решение своей проблемы.Я решил поработать с некоторыми образцами в гл.7 из Начало ASP.NET Security Барри Дорранса (опубликовано Wrox) в надежде, что работа с аутентификацией и авторизацией в простых примерах может привести к решению, и оно имело место.

Один изПримеры использования проверки подлинности с помощью форм (стр. 155-157) показали простую страницу login.aspx, похожую на мою страницу запуска разработки.Код, который был у меня на начальной странице разработки (показан выше), был неверным.Это должно было быть: 

FormsAuthentication.Authenticate(simUserName, simUserPassword)
FormsAuthentication.RedirectFromLoginPage(simUserName, False)

Я также определил своих смоделированных пользователей в моем файле разработки web.config: 

<authentication mode="Forms">
  <forms defaultUrl="default.aspx" loginUrl="mystart.aspx">
    <credentials passwordFormat="Clear">
      <user name="GeorgeWashington" password="password"/>
      <user name="AndrewJackson" password="password"/>
      <user name="AbrahamLincoln" password="password"/>
      <user name="TeddyRoosevelt" password="password"/>
      <user name="JackKennedy" password="password"/>
    </credentials>
  </forms>
</authentication>

Когда вызывается FormsAuthentication.Authenticate и проверяет подлинность, кто когда-либо из имитированных пользователейЯ выбираю, похоже, это заставляет ASP.NET теперь всегда использовать это имя пользователя в вызовах к поставщику ролей.По крайней мере, похоже, что это работает при отладке веб-сайта.

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

Любой, кто хочет использовать это решение, ПРЕДУПРЕЖДЕНИЕ : запуск вашей разработкистраница НИКОГДА не должна использоваться для веб-сайта Production .Аналогично, НИКОГДА не используйте имена пользователей и пароли в файле web производства .config.Это ТОЛЬКО для отладки и тестирования.В зависимости от того, как вы управляете версией кода разработки и производства, вам может потребоваться вручную объединить некоторые изменения, переходящие от разработки к производству, чтобы избежать отправки этого кода отладки в Production.

Я также понимаю, что Microsoft хочет, чтобы мы использовалиПоставщик членства вместо класса FormsAuthentication.И в производственном коде мы должны.Но для моих целей (обеспечение того, чтобы я мог взаимодействовать с веб-сайтом с разными пользователями / ролями во время отладки), это, кажется, самое простое решение.

РЕДАКТИРОВАТЬ - еще одна часть головоломкиЯ все еще получал странные вызовы методов в моем провайдере пользовательских ролей.Несколько раз вызывался метод с именем пользователя, с которым я вошел на мою страницу входа (это то, что я ожидал);чаще всего это было мое имя пользователя Windows, которое заставило меня поверить, что ASP.NET где-то все еще использует авторизацию Windows.После дополнительных исследований (спасибо ТАК !!!) я обнаружил, что в моем файле applicationhost.config для моего проекта для проверки подлинности Windows было установлено значение True, которое, как мне кажется, вызывало конфликт с моим файлом web.config.Установка значений в applicationhost.config на: 

<location path="MyWebSite">
    <system.webServer>
        <security>
            <authentication>
                <anonymousAuthentication enabled="true" />
                <windowsAuthentication enabled="false" />
            </authentication>
        </security>
    </system.webServer>
</location>

, похоже, решила эту проблему.

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

...