asp.net-mvc forms-authentication http-status-code-302

asp.net mvc - Forms auth redirigir css/script incluye a la página de inicio de sesión con HTTP 302



asp.net-mvc forms-authentication (5)

Última respuesta aquí, pero quería ayudar a arrojar algo de luz sobre este IISsue. (mira lo que hice?)

En primer lugar, quiero decir que la respuesta de David Conlisk es la respuesta segura, clava la uña en la cabeza, arregla cada vez. Pero en caso de que usted sea como yo y haya desplegado muchas aplicaciones con formularios y autenticación anónima donde la Identidad de autenticación anónima está configurada en IUSR y, de repente, estoy viendo este problema ahora , entonces escuche cómo reproduje el problema y con suerte salvado de la misma situación difícil.

Mi práctica habitual es ejecutar el AppPoolIdentity de mi aplicación web como servicio de red . Luego, solo voy al directorio real en el disco al que apunta el directorio virtual -> clic derecho -> Propiedades -> Ficha Seguridad -> Editar -> Agregar el usuario del servicio de red -> Otorgar permisos de lectura / escritura.

Luego habilito la autenticación anónima en los directorios que necesito (js, css, etc.) La identidad del grupo de aplicaciones es IUSR de forma predeterminada.

DE ACUERDO. Ahora, de repente, en mi entorno de desarrollo, comienzo a obtener 302 auth redirects de formularios en todos mis css y js. ¿Que pasó? Hice un interruptor SVN en mi aplicación web a una rama diferente en control de fuente . Ugh. Completamente conectó todos mis permisos de disco para cada archivo. La única forma en que alguna vez pude solucionarlo es eliminar toda la aplicación web, hacer un nuevo checkout y volver a aplicar los permisos de lectura del servicio de red (o aplicar permisos en cada archivo ... y sí, lo he intentado). eliminando y volviendo a agregar los permisos en la carpeta de nivel principal).

Así que esta vez, decido "diablos, estoy ejecutando mi aplicación web como sistema local . Eso mostrará los permisos de disco cuyo jefe. Esto me ha funcionado de vez en cuando como una solución a corto plazo". Pero, por desgracia, hoy no. Te juro que ante mis ojos estoy viendo dos implementaciones de una aplicación web de autenticación de formularios con exactamente la misma configuración y el problema 302 solo se está reproduciendo en mi máquina de desarrollo. La única diferencia es el interruptor SVN reciente en mi máquina.

Tan pronto como inicie sesión y obtenga una cookie de autenticación de formularios, la descarga de js y css está muy bien.

Tenga paciencia, acabo de hacer un descubrimiento sorprendente. Todos los servidores en los que tengo implementado tienen permisos de lectura otorgados a MACHINE_NAME / Users . Y mi máquina de desarrollo no. Una vez que agregué eso a mi máquina de desarrollo, pude descargar mi CSS.

TLDR;

La moraleja de la historia es que puede mantener la Identidad de autenticación anónima como IUSR, pero luego debe otorgar a todos los usuarios permisos de lectura en su aplicación web en el disco.

Como esta es una mala idea (por razones de seguridad), voy a utilizar mi nueva práctica para adoptar la respuesta de David C y hacer que la Identidad de autenticación anónima se ejecute como la identidad del grupo de aplicaciones.

Tengo algunos incluye en una página de inicio de sesión, un archivo css y un archivo js.

<link rel="stylesheet" type="text/css" href="../../ext/resources/css/ext-all.css" /> <script type="text/javascript" src="../../ext/bootstrap.js"></script>

Desafortunadamente, las solicitudes que hace el navegador para estas obtienen la respuesta 302. La autenticación de formularios está viendo la solicitud como no autorizada y redirigiéndola a la página de inicio de sesión. No se da cuenta de que la solicitud proviene de la página de inicio de sesión en primer lugar.

GET http://localhost:50880/ext/resources/css/ext-all.css HTTP/1.1 HTTP/1.1 302 Found <html><head><title>Object moved</title></head><body> <h2>Object moved to <a href="/Account/LogOn?ReturnUrl=%2fext%2fresources%2fcss%2fext-all.css">here</a>.</h2> </body></html>

Pensé que tal vez configurar los permisos de la carpeta incluye (ext) a todos podría ayudar.

No he tenido este problema en otros proyectos.


Debe excluir que los archivos CSS e imágenes se autentiquen como se muestra en el archivo de configuración. Usando la etiqueta de ubicación puede excluir un solo archivo o directorio.

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


El problema que tuve al respecto fue que había descargado un complemento de jquery de Internet y lo copié en mi directorio de contenido en el servidor web y Windows tenía todos los archivos debajo de él bloqueados para que el servidor web no pudiera acceder correctamente. Desbloquear los archivos en Windows resolvió el problema.


Entonces, esto es lo que hice que resolvió completamente el problema.

Primero, realicé el cambio en la web.config como todos los demás dijeron que hiciera.

Estoy usando Autenticación anónima en IIS, y como se menciona en este número, entré en IIS> Grupos de aplicaciones> Haciendo clic con el botón derecho en mi grupo de aplicaciones> Editar> cambié el grupo de aplicaciones para usar la identidad del grupo de aplicaciones.

ENTONCES - Fui a la carpeta principal que contiene mi sitio, ingresé a los permisos para esa carpeta y agregué la cuenta de servicio de red del servidor para acceder a la carpeta. Eso lo hizo por mí. Es porque el grupo de aplicaciones se ejecuta bajo ApplicationPoolIdentity, que es la cuenta de servicio de red en el equipo local.

¡Espero que esto ayude a alguien!


Yo tuve el mismo problema. Así es como lo resolví.

En IIS7, haga clic en su sitio web, luego haga doble clic en el botón Autenticación. Haga clic en Autenticación anónima, luego haga clic en el enlace Editar ... en el lado derecho. Asegúrese de que la casilla de verificación "Identidad del grupo de aplicaciones" esté marcada.

Mi grupo de aplicaciones se ejecuta bajo el usuario "Servicio de red" (no "ApplicationPoolIdentity"). Puede elegir Identidad en la Configuración avanzada de su grupo de aplicaciones en IIS. Este usuario ha tenido acceso completo al sistema de archivos para el sitio web.