Новый проект Asp.Net MVC5 создает бесконечный цикл для входа в систему

Ответ 1

Помните, что это потенциально опасный совет, редко рекомендуется изменять конфигурационный файл приложенияhosthost, обычно есть инструменты, которые сделают это для вас безопасно (например, из Visual Studio. ) Прежде чем продолжить, обязательно создайте резервную копию этого файла в случае, если ваш IIS Express будет поврежден.

Чтобы устранить эту проблему, я взял файл конфигурации IIS по умолчанию, расположенный здесь:

C:\Windows\System32\inetsrv\config\applicationHost.config

В мой документ

%userprofile%\documents\iisexpress\config\applicationhost.config

И это сработало.

Это было связано с тем, что у меня установлен набор Authentification для Windows, а не анонимная учетная запись.

Ответ 2

Выделите проект в Visual Studio

Откройте панель "Свойства" справа (или нажмите F4)

Установите "Аутентификация Windows" на "Отключено"

Установите "Анонимная аутентификация" на "Включено"

Ответ 3

Эта проблема возникает из-за выбранного режима проверки подлинности (по умолчанию) шаблона MVC 5, который запускает стиль перенаправления ReturnUrl, который может привести к бесконечному циклу, если он не настроен правильно.

Чтобы отключить обнаружение запуска OWIN, добавьте этот ключ в свой файл webconfig.

<add key="owin:AutomaticAppStartup" value="false"/>

Ответ 4

Вам не хватает атрибута [AllowAnonymous] при действии входа.

[AllowAnonymous]
public ActionResult Login(string returnUrl)
{
    // code....
}

Вторая возможность, специфичная только для IIS Express: это то, что если вы создали один и тот же проект по умолчанию WebApplication1 несколько раз, играя с разными настройками аутентификации, IIS Express сохранил дополнительные параметры аутентификации в этом файле конфигурации, Что-то вроде:

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

Конфигурации находятся в папке "Документы пользователя" Documents\IISExpress\config\, и вы должны искать:

applicationhost.config

Затем просто удалите xml node <location path="WebApplication1">, упомянутый выше.

Обновление для VS 2015 +

Если вы используете Visual Studio 2015 или выше, проверьте этот путь для файла конфигурации: $(solutionDir)\.vs\config\applicationhost.config

Каждое решение будет иметь свой собственный файл конфигурации.

Ответ 5

Мне пришлось удалить (Source Link):

<authorization>
  <deny users="?" />
</authorization>

Ответ 6

Я знаю, что могу опаздывать, и это не относится непосредственно к вопросу ОП. Но если кто-нибудь в будущем придет сюда, еще одна проверка атрибута AllowAnonymous и Authorize заключается в том, что вы должны также проверить все дочерние действия.

Например, у меня был мой макет (который также использует страница входа), которые вызывают 2 дочерних действия для панировочных сухарей и боковых панелей, и у них не было атрибута AllowAnonymous (у атрибута Controller был атрибут Authorize).

Надеюсь на эту помощь.

Ответ 7

В IIS выберите веб-сайт и проверьте наличие аутентификации. Если вы используете аутентификацию форм, тогда -

• Установите "Аутентификация Windows" на "Отключено",
• Установите "Анонимная аутентификация" на "Включено"
• Установите "Аутентификация форм" на "Включено"

Ответ 8

Я столкнулся с той же проблемой, потому что мой проект MVC был настроен для .Net 4.5, но я использовал .Net 4.0 как пул приложений в IIS. Включил его в пул приложений .Net 4.5, и проблема была исправлена. Надеюсь, это поможет кому-то еще!

Ответ 9

TL: DR? Не вызывайте защищенный веб-API (любой веб-API, который требует авторизации) с страницы авторизации, такой как ~/Account/Login (которая сама по себе НЕ делает этого.). Если вы это сделаете, вы войдете в бесконечный цикл перенаправления на стороне сервера.

Причина

Я обнаружил, что виновник был, косвенно, AccountController::Authorize и тот факт, что AccountController украшен [Authorize].

Основная причина заключалась в том, что Sammy() вызывается из HomeViewModel() (строка 6 home.viewmodel.js), к которому обращался "защищенный веб-API". Это делалось для /Account/Login, в результате чего /Account/Login перенаправлялся на себя.

Подтверждение

Вы можете подтвердить, что это является причиной вашей проблемы несколькими способами:

• Украсьте AccountController::Authorize с помощью [AllowAnonymous]
• Прокомментируйте вызовы Sammy(), сделанные при построении viewmodel.

Решение

Решение должно было только выпустить пакет приложений (a.k.a "~/bundles/app" ) для просмотров, которые уже требовали авторизации. По моим сведениям/учетные записи/представления являются классическими представлениями на основе MVC и не являются частью приложения datamodel/viewmodel, но я ошибочно перевел вызов пакета Scripts.Render(@"~/bundles/app") в _Layout.cshtml(вызывающий вызовы защищенного веб-API для все виды MVC, включая/Account/.)

Ответ 10

Шаблон ASP.Net MVC 5 добавляет в проект Microsoft.Owin и связанные с ним библиотеки. Поскольку для инфраструктуры Owin не требуется проверка подлинности с помощью форм, шаблон также вводит следующий ключ в web.config.

<system.webServer>
  <modules>
    <remove name="FormsAuthentication" />
  </modules>
</system.webServer>

Наличие этого ключа может быть причиной нежелательного перехода на страницу входа. Комментируя это может помочь решить проблему для некоторых людей.

Ответ 11

в моем случае: в моем _layout.cshtml я использую Html.Action для вызова Action из Authorize Controller: ex: Html.Action( "Count", "Product" ) → ошибка цикла

fix: украсить атрибутом [AllowAnonymous] в этом Action (или удалить этот хелпер Html из _layout)

Ответ 12

Я просто занимался этой проблемой в течение нескольких часов подряд.

Для меня это было в файле Startup.Auth.cs.

Этот код при комментировании остановил цикл перенаправления.

        app.UseCookieAuthentication(new CookieAuthenticationOptions
        {
            AuthenticationType = DefaultAuthenticationTypes.ApplicationCookie,
            LoginPath = new PathString("/Account/Login")
        });

Ответ 13

Убедитесь, что в конвейере нет действий, имеющих атрибут authorize. В моем случае у моего макета был диспетчер меню навигации, в котором отсутствовал атрибут allowAnonymous.

Ответ 14

Я решил ту же проблему благодаря принятому ответу: Реферирование входа в ASP.NET, когда пользователь не участвует в роли.

Возможно, что контроллер, содержащий действие входа, украшен AuthorizeAttribute (даже обычным), в то время как действие входа не украшено атрибутом AllowAnonymous. Извлечение AuthorizeAttribute из контроллера и добавление AllowAnonymous к действию входа в систему может быть возможным решением.

Ответ 15

Эти ответы - более или менее части одной и той же головоломки; Я постараюсь положить все в одном месте. Проблема, описанная в OP, поразила мое приложение в тот момент, когда я реализовал конвейер OWIN и идентификатор AspNET.

Итак, посмотрим, как это исправить...

• Запуск OWIN

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

[assembly: OwinStartupAttribute(typeof(YourApp.Probably_App_Start.SomethingLikeAuthConfig))]

... или строка конфигурации...

<add key="owin:AppStartup" value="YourApp.Probably_App_Start.SomethingLikeAuthConfig" />

2. Ограничение доступа к контроллерам

Теперь мы очистили это, вам нужна аутентификация. Это означает, что каждому из ваших контроллеров нужен атрибут [Authorize], или вы можете сделать то же самое со всеми контроллерами в одном месте, зарегистрировав предмет в глобальном масштабе (например, в RegisterGlobalFilters(), добавьте строку filter.Add(new AuthorizeAttribute())). В первом случае (при закреплении каждого контроллера отдельно) пропустите эту часть, просто перейдите к следующей. В последнем случае все ваши контроллеры будут защищены от несанкционированного доступа, поэтому вам нужна точка входа для этого разрешения - незащищенного действия Login(). Просто добавьте...

[AllowAnonymous]

... и вы должны быть хорошими.

3. Конфигурация cookie OWIN

Когда ваш пользователь входит в систему, его браузер хранит зашифрованный (надеюсь,!) файл cookie, чтобы упростить работу системы. Итак, вам нужен файл cookie - не удаляйте строку, которая говорит UseCookieAuthentication.

4. Вам действительно нужно отключить встроенный механизм аутентификации IIS для вашего веб-приложения. Это означает отключение Windows Authentication (Отключено) и включение доступа к любому пользователю, по крайней мере, до тех пор, пока IIS Express в настоящее время обеспокоен установкой Anonymous Authentication (Enabled).

Когда вы запустите свой веб-сайт, это, в свою очередь, скопирует эти настройки в конфигурацию IIS Express (applicationhost.config), и там вы увидите две строки:

<windowsAuthentication enabled="false" />
<anonymousAuthentication enabled="true" />

5. У вас может быть конфиг авторизации в вашем web.config, который говорит deny users="?". Это означает, что подсистема авторизации получает указание запретить анонимным пользователям вводить данные. С OWIN это все еще работает так, как было разработано. Вам либо нужно удалить это, либо сделать ваш анонимный пользователь доступным для входа на страницу входа, используя что-то вроде...

   <location path="Account/Login"> <system.web> <authorization> <allow users="*" /> </authorization> </system.web> </location>

НТН

Ответ 16

У меня были аналогичные проблемы, когда он был в бесконечном цикле при обратном вызове на сайт. Оказывается, при локальной локализации он перенаправлял порты. Я обновил номера портов на экране свойств проекта, но оставил определение Azure одинаковым в облачном проекте, и все начало работать, как ожидалось.

Ответ 17

У меня была такая же проблема с моим проектом Asp.Net MVC 4. Я решил это, перейдя в Startup.cs и закомментировав строку для ConfigureAuth (app)

    public void Configuration(IAppBuilder app)
    {
        //ConfigureAuth(app);
    }

Я также удостоверился, что в моем IIS для моего проекта включена проверка подлинности Windows, а все другие параметры проверки отключены.

Ответ 18

Для меня это оказалось вызвано моим LoginViewModel, содержащим ссылки на файлы ресурсов перевода, которые, по-видимому, защищены аутентификацией. Я удалил эти ссылки, и проблема была решена.

Ответ 19

Для меня удаление следующего блока исправлено:

<authorization>
  <deny users="?" />
  <allow users="*" />
</authorization>

Предположим

<authentication mode="None" />

Ответ 20

Для меня я конвертировал проект, который раньше был Windows-аутентификацией, в проект, в котором использовалась структура идентификации с учетными записями. После нескольких часов борьбы с этой бесконечной проблемой перенаправления и пробуя каждое предложение здесь, оказалось, что мне просто нужно было очистить мои куки в браузере, и тогда все работало как ожидалось.

Ответ 21

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

Ответ 22

Перейдите в свой файл applicationhost.config и установите anonymousauthentication = "true"

<authentication>

            <anonymousAuthentication enabled="true" userName="" />
            <windowsAuthentication enabled="true">
                <providers>
                    <add value="Negotiate" />
                    <add value="NTLM" />
                </providers>
            </windowsAuthentication>

        </authentication>