tutorial tag net mvc asp asp.net asp.net-mvc visual-studio-2013 asp.net-mvc-5

asp.net - tag - razor mvc



El nuevo proyecto Asp.Net MVC5 produce un bucle infinito para ingresar a la página (20)

Acabo de tratar este tema durante horas y horas.

Para mí, estaba en el archivo Startup.Auth.cs.

Este código, cuando se comentó, detuvo el bucle de redireccionamiento.

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

Estoy creando un nuevo proyecto con Visual Studio 2013, elijo Asp.Net MVC y el framework 4.5.1. El proyecto se crea; luego, no hago más que F5 para iniciar la página web predeterminada. Desafortunadamente, produce un redireccionamiento a la página de inicio de sesión que también está redireccionando a la página de inicio de sesión. Aquí hay una versión corta de la url que tengo en el navegador:

http://localhost:5285/Account/Login?ReturnUrl=%2FAccount%2FLogin%3FReturnUrl%3D%252FAccount%252FLogin%253FReturnUrl%253D%25252FAccount%25252FLogin%25253FReturnUrl%25253D%2525252FAccount%2525252FLogin%2525253FReturnUrl%2525253D%252525252FAccount%252525252FLogin%252525253FReturnUrl%252525253D%25252525252FAccount%25252525252FLogin%25252525253FReturnUrl%25252525253D%2525252525252FAccount%2525252525252FLogin%2525252525253FReturnUrl%2525252525253D%252525252525

No tengo ningún error en el Visor de eventos. Pero en la pantalla veo:

"HTTP Error 404.15 - No encontrado El módulo de filtrado de solicitudes está configurado para denegar una solicitud cuando la cadena de consulta es demasiado larga".

El sitio web se está ejecutando con la configuración predeterminada en IIS Express. ¿Como puedo solucionar este problema? ¿Supongo que algo está mal con mi Visual Studio 2013?

Editar

Funciona si creo un nuevo sitio web y lo hospedo en IIS. Pero si creo un nuevo sitio web (sin modificar nada) y simplemente presiono play (que inicia IIS Express por defecto), no lo hace.

Editar 2

He eliminado todos los sitios web en Documents / IISExpress / config / applicationhost.config. He recompilado todo, y creó esta entrada:

<siteDefaults> <logFile logFormat="W3C" directory="%IIS_USER_HOME%/Logs" /> <traceFailedRequestsLogging directory="%IIS_USER_HOME%/TraceLogFiles" enabled="true" maxLogFileSizeKB="1024" /> </siteDefaults> <applicationDefaults applicationPool="Clr4IntegratedAppPool" /> <virtualDirectoryDefaults allowSubDirConfig="true" /> </sites>

Todavía estoy obteniendo el error con IIS Express, no con IIS.


Asegúrese de no tener acciones en la tubería que tengan un atributo de autorización. En mi caso, mi diseño tenía un controlador de menú de navegación al que le faltaba el atributo allowAnonymous.


En IIS, seleccione su sitio web y busque Autenticación. Si usa Autenticación de formularios, entonces -

  1. Establezca ''Autenticación de Windows'' en ''Desactivado'',
  2. Establezca ''Autenticación anónima'' en ''Habilitado''
  3. Establezca ''Autenticación de formularios'' en ''Habilitado''

Estas respuestas son más o menos piezas del mismo rompecabezas; Trataré de poner todo en un solo lugar. El problema que OP describió golpeó mi aplicación en el momento en que implementé la interconexión OWIN y AspNET Identity.

Entonces veamos cómo solucionarlo ...

  1. OWIN Startup

Supongo que lo necesitas, porque si no lo haces, entonces no necesitas autenticación, y creo que sí. Excepto que estás usando una autenticación antigua, y supongo que no. Por lo tanto, no elimine el atributo de inicio de OWIN ...

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

... o la línea de configuración ...

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

  1. Restricción de acceso a los controladores

Ahora aclaramos esto, necesitas la autenticación. Esto significa que cada uno de sus controladores necesita el atributo [Authorize] , o puede hacer lo mismo con todos los controladores en un solo lugar registrando la cosa globalmente (por ejemplo, en RegisterGlobalFilters() , agregue filter.Add(new AuthorizeAttribute()) de filter.Add(new AuthorizeAttribute()) ) . En el primer caso (al asegurar cada controlador por separado) omita esta parte, simplemente vaya a la siguiente. En este último caso, todos sus controladores estarán protegidos contra el acceso no autorizado, por lo que necesita un punto de entrada para esa autorización: acción de Login() desprotegida Login() . Solo agrega...

[AllowAnonymous]

... y deberías ser bueno.

  1. Configuración de cookies OWIN

Cuando el usuario inicia sesión, su navegador almacena cookies cifradas (¡con suerte!) Para simplificar las cosas para el sistema. Por lo tanto, necesita cookies: no elimine la línea que dice UseCookieAuthentication .

  1. Lo que realmente tiene que hacer es desactivar el mecanismo de autenticación integrado de IIS para su aplicación web. Esto significa desconectar la Windows Authentication (Deshabilitado) y permitir el acceso de cualquier usuario, al menos mientras IIS Express esté involucrado, configurando la Anonymous Authentication (Habilitada).

Cuando inicie su sitio web, esto a su vez copiará estas configuraciones en la configuración de IIS Express ( applicationhost.config ), y allí debería ver estas dos líneas:

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

  1. Puede tener la configuración de autorización en su web.config que dice deny users="?" . Significa que el subsistema de autorización tiene instrucciones para evitar la entrada de usuarios anónimos. Con OWIN, esto sigue funcionando como está diseñado. Debe eliminar esto o hacer que su usuario anónimo pueda acceder a la página de inicio de sesión utilizando algo como ...

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

HTH


Este problema se debe al modo de autenticación seleccionado (por defecto) por la plantilla MVC 5, que desencadena el estilo ReturnUrl de redirección que podría conducir a un bucle infinito si no está configurado correctamente.

Para deshabilitar el descubrimiento de inicio de OWIN, agregue esta clave a su archivo webconfig.

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


Falta el atributo [AllowAnonymous] en la acción de inicio de sesión.

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

Segunda posibilidad , específica solo para IIS Express: si creó varias veces el mismo proyecto WebApplication1 predeterminado, jugando con diferentes configuraciones de autenticación, IIS Express almacenó configuraciones de autenticación adicionales en su archivo de configuración. Algo como:

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

Las configuraciones se encuentran en la carpeta Documents/IISExpress/config/ del usuario Documents/IISExpress/config/ , y debe buscar:

applicationhost.config

A continuación, simplemente elimine el nodo xml <location path="WebApplication1"> mencionado anteriormente.

Actualización para VS 2015+

Si está usando Visual Studio 2015 o una versión superior, consulte esta ruta para el archivo de configuración: $(solutionDir)/.vs/config/applicationhost.config

Cada solución tendrá su propio archivo de configuración.


La plantilla ASP.Net MVC 5 agrega Microsoft.Owin y bibliotecas relacionadas al proyecto. Como la infraestructura de Owin no requiere autenticación de formularios, la plantilla también introduce la siguiente clave en web.config.

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

La presencia de esta clave podría ser una razón para un indeseable retorno a la página de inicio de sesión. Comentarlo puede ayudar a solucionar el problema para algunas personas.


Me enfrenté al mismo problema porque mi proyecto MVC se configuró para .Net 4.5 pero estaba usando .Net 4.0 como mi grupo de aplicaciones en IIS. Lo cambié al grupo de aplicaciones .Net 4.5 y se solucionó el problema. ¡Espero que esto ayude a alguien más!


Para mí, eliminar el siguiente bloque lo solucionó:

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

Asumir

<authentication mode="None" />


Para mí, esto resultó ser causado por mi LoginViewModel que contiene referencias a archivos de recursos de traducción, que aparentemente están protegidos por autenticación. Eliminé esas referencias y el problema fue resuelto.


Resalta el proyecto en Visual Studio

Abra el panel ''Propiedades'' a la derecha (o presione F4)

Establezca ''Autenticación de Windows'' en ''Desactivado''

Establezca ''Autenticación anónima'' en ''Habilitado''


Resolví el mismo problema gracias a esta respuesta aceptada: ASP.NET Login Redirect Loop cuando el usuario no está en función .

Es posible que el controlador que contiene la acción de inicio de sesión esté decorado con un atributo AuthorizeAttribute (incluso uno personalizado) mientras que la acción de inicio de sesión no está decorada con el atributo AllowAnonymous . Quitar AuthorizeAttribute del controlador y agregar AllowAnonymous a la acción de inicio de sesión puede ser una posible solución.


Sé que puedo llegar tarde, y esto no es directamente para la pregunta del OP. Pero si alguien en el futuro viene aquí, un control más sobre el AllowAnonymous y Authorize es que, también debe verificar todas las acciones del niño .

Por ejemplo, tenía mi Layout (que también usa la página de inicio de sesión) que llama a 2 acciones secundarias para las AllowAnonymous y la barra lateral, y no tenían el atributo AllowAnonymous (el controlador tenía el atributo Authorize ).

Espero que esto ayude.


Tuve el mismo problema con mi proyecto Asp.Net MVC 4. Lo resolví yendo a Startup.cs y comentando la línea de ConfigureAuth (aplicación)

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

También me aseguré de tener habilitada la Autenticación de Windows en IIS para mi proyecto y todas las demás opciones de autenticación deshabilitadas.


Tuve problemas similares cuando estaba en un ciclo infinito cuando volví a llamar al sitio web localmente. Resulta que al depurar localmente redirigía los puertos. Actualicé los números de puerto en la pantalla de propiedades del proyecto, pero dejé la definición de Azure igual en el proyecto de la nube y todo comenzó a funcionar como se esperaba.


Tuve que eliminar ( Source Link ):

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


Vaya a su archivo applicationhost.config y configure anonymousauthentication = "true"

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


en mi caso: en mi _layout.cshtml, utilizo Html.Action para llamar a Action desde Authorize Controller: ej .: Html.Action ("Count", "Product") -> loop error

corregir: decorar mediante el atributo [AllowAnonymous] en esa Acción (o eliminar estos Html helper de _layout)


TL: ¿DR? No llame a una API web protegida (cualquier API web que requiera Autorización) desde una página de autorización como ~ / Cuenta / Iniciar sesión (que, por sí sola, NO hace esto). Si lo hace, ingresará en un bucle de redirección infinito en el lado del servidor.

Porque

Descubrí que el culpable era, indirectamente, AccountController::Authorize y el hecho de que AccountController está decorado con [Authorize] .

La causa principal fue que se llamó a Sammy () desde HomeViewModel () (Línea 6 de home.viewmodel.js), que estaba accediendo a una "API web protegida". Esto se estaba haciendo para / Account / Login, que resultó en / Account / Login redireccionando a sí mismo.

Confirmación

Puede confirmar que esta es la causa de su problema a través de varios métodos:

  1. Decorar AccountController::Authorize con [AllowAnonymous]
  2. Comente las llamadas de Sammy () realizadas durante la construcción del modelo de vista.

Solución

La solución fue emitir solo el paquete de aplicaciones (también conocido como "~ / bundles / app") para las vistas que ya requerían autorización. Según mi conocimiento, la cuenta / vistas son vistas clásicas basadas en MVC, y no son parte del modelo de datos / vista de la aplicación, pero erróneamente moví el paquete Scripts.Render(@"~/bundles/app") llamada a _Layout.cshtml (lo que provoca que se realicen llamadas API web protegidas para todas las vistas MVC, incluida / Account /.)


Tenga en cuenta que este es un consejo potencialmente dañino, rara vez es una buena idea modificar directamente un archivo de configuración de applicationhost, normalmente hay herramientas que lo harán por usted, de forma segura (por ejemplo, desde Visual Studio). Antes de continuar, asegúrese para crear una copia de seguridad de este archivo en caso de que su IIS Express se convierta en basura.

Para solucionar este problema, tomé el archivo de configuración de IIS predeterminado que se encuentra aquí:

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

A mi documento

%userprofile%/documents/iisexpress/config/applicationhost.config

Y funcionó.

Esto se debía a que tenía algún conjunto de autenticación de Windows y no la cuenta anónima.