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

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

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

установите "проверка подлинности Windows" в "отключено"

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

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

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

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

вы пропали без вести [AllowAnonymous] атрибут при входе в систему действия.

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

2-й возможности, специфичный только для IIS Express: это, если вы создали тот же default 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 <location path="WebApplication1"> упоминалось выше.

---

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

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

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

мне пришлось удалить (Ссылка На Источник):

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

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

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

в IIS выберите веб-сайт и проверьте проверку подлинности, если вы используете проверку подлинности с помощью форм, то -

1. установите "проверка подлинности Windows" в "отключено",
2. установите "анонимная аутентификация" в "включено"
3. установите "проверка подлинности форм" в "включено"

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

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

причина

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

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

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

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

1. украшения AccountController::Authorize с [AllowAnonymous]
2. прокомментируйте вызовы Sammy (), сделанные во время viewmodel строительство.

решение

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

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

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

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

в моем случае: в мой файл _Layout.cshtml, я использую Html.Действия для вызова действий с авторизовать контроллер, например: HTML-код.Действие ("Count", "Product") - > ошибка цикла

исправить: украсьте с помощью атрибута [атрибута allowanonymous] в том, что действие (или удалить следующие HTML-Helper из файл _Layout)

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

для меня это было в запуске.Автор.cs-файл.

этот код, когда его закомментировали, остановил цикл перенаправления.

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

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

Я решил ту же проблему благодаря этому принятому ответу:ASP.NET войти цикл перенаправления, когда пользователь не в роли.

возможно, что контроллер, содержащий действие входа в систему, украшен AuthorizeAttribute (даже пользовательский), пока действие входа не украшено

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

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

1. OWIN Startup

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

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

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

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

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

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

[AllowAnonymous]

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

1. конфигурация файлов cookie OWIN

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

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

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

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

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

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

HTH

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

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

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

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

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

для меня удаление следующий блок исправил это:

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

предположим

<authentication mode="None" />

перейти к вашему applicationhost.конфигурационный файл и набор anonymousauthentication = "true"

<authentication>

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

        </authentication>