node.js - headers - CORS en el problema de IIS con credenciales y comodines en Access-Control-Allow-Origin

habilitar cors

Question

Heredé un sitio bastante básico que sirve datos y maneja algunas conexiones de socket. Está ejecutando NodeJS detrás de IIS usando iisnode como un puente. Todo está funcionando bien desde la perspectiva de "servir páginas normales".

Parte del problema es que las conexiones reales al servidor provienen de clientes de escritorio donde el contenido se carga a través de una aplicación diferente como un gadget y de partes potencialmente cambiantes y variables de la red, dispositivos móviles, etc., etc. número desconocido de dominios de cliente

Ya configuré Access-Control-Allow origin to * para simplemente abrir las puertas del granero pero ahora obtengo el siguiente error en el cliente:

11: 29: 57.668 Solicitud de origen cruzado bloqueada: la misma política de origen no permite leer el recurso remoto en '' http: //server/socket.io/? EIO = 3 & transport = polling & t = 1486150196479-0 ''. (Motivo: la credencial no es compatible si el encabezado CORS ''Access-Control-Allow-Origin'' es ''*''). 1 (desconocido)

Intenté establecer Access-Control-Allow-Credentials explícitamente como falso (y verdadero, así como también omitirlo por completo), pero ninguno de mis intentos me permitió superarlo.

Los encabezados de respuesta sin formato se ven así actualmente:

Access-Control-Allow-Credentials: false
Access-Control-Allow-Headers: Origin,Content-Type,Accept
Access-Control-Allow-Methods: GET,HEAD,PUT,POST,DELETE,OPTIONS
Access-Control-Allow-Origin: *
Cache-Control: no-cache
Content-Encoding: gzip
Content-Length: 969
Content-Type: text/html
Date: Fri, 03 Feb 2017 19:30:21 GMT
Server: Microsoft-IIS/8.5
Vary: Accept-Encoding
X-Powered-By: ASP.NET

Parece que no puedo resolver después de ver MUCHOS sitios y artículos de CORS en los últimos días por qué todavía se queja sobre las credenciales, y más específicamente, ¿cómo puedo evitar esto?

¡Gracias!

ACTUALIZACIÓN 2017-02-06

El código del cliente no es terriblemente emocionante. Dado que el servidor es NodeJS detrás de IIS, todo lo que realmente estoy haciendo para esto es implementar una conexión de socket:

var socket = io(''http://'' + currentServer, {path: ''/broadcast/socket.io'', reconnection: false, forceNew: true});
socket.on(''update message'', function (data) {
// do some fancy things
}

Esto funciona desde dentro del mismo dominio.

También he estado investigando un poco más en base a los comentarios de sideshowbarker que me llevaron a este artículo. Hay algunos pasos adicionales para agregar las variables y algunas otras cosas para que funcione.

Mi applicationHost.config actualmente contiene esta sección:

<location path="Default Web Site">
    <system.webServer>
        <rewrite>
            <allowedServerVariables>
                <add name="CAPTURED_ORIGIN" />
                <add name="RESPONSE_Access-Control-Allow-Origin" />
            </allowedServerVariables>
        </rewrite>
    </system.webServer>
</location>

y mi web.config está aquí:

<?xml version="1.0" encoding="UTF-8"?>
<configuration>
<system.webServer>
    <rewrite> 
        <rules>
            <rule name="Fail bad requests">
                <match url="." />
                <conditions>
                    <add input="{HTTP_HOST}" negate="true" pattern="localhost" />
                </conditions>
                <action type="AbortRequest" />
            </rule>
            <rule name="Capture Origin Header"> 
                <match url=".*" /> 
                <conditions> 
                    <add input="{HTTP_ORIGIN}" pattern=".+" /> 
                </conditions> 
                <serverVariables> 
                    <set name="CAPTURED_ORIGIN" value="{C:0}" /> 
                </serverVariables> 
                <action type="None" /> 
            </rule>
        </rules>
        <outboundRules> 
            <rule name="Set-Access-Control-Allow-Origin for known origins"> 
                <match serverVariable="RESPONSE_Access-Control-Allow-Origin" pattern=".+" negate="true" /> 
                <!--<action type="Rewrite" value="{C:0}" /> -->
            </rule> 
        </outboundRules> 
    </rewrite>
    <tracing>
        <traceFailedRequests>
            <add path="*">
                <traceAreas>
                    <add provider="ASP" verbosity="Verbose" />
                    <add provider="ASPNET" areas="Infrastructure,Module,Page,AppServices" verbosity="Verbose" />
                    <add provider="ISAPI Extension" verbosity="Verbose" />
                    <add provider="WWW Server" areas="Authentication,Security,Filter,StaticFile,CGI,Compression,Cache,RequestNotifications,Module,FastCGI,WebSocket" verbosity="Verbose" />
                </traceAreas>
                <failureDefinitions statusCodes="400-599" />
            </add>
        </traceFailedRequests>
    </tracing>
</system.webServer>
</configuration>

en las filas de salida, actualmente tengo la línea de tipo de acción = "Reescribir" comentada porque cuando la habilito, arroja un error.

HTTP Error 500.52 - URL Rewrite Module Error.

The page cannot be displayed because an internal server error has occurred.

Most likely causes:
•IIS received the request; however, an internal error occurred during the processing of the request. The root cause of this error depends on which module handles the request and what was happening in the worker process when this error occurred.
•IIS was not able to access the web.config file for the Web site or application. This can occur if the NTFS permissions are set incorrectly.
•IIS was not able to process configuration for the Web site or application.
•The authenticated user does not have permission to use this DLL.
•The request is mapped to a managed handler but the .NET Extensibility Feature is not installed.

Detailed Error Information:
Module: RewriteModule 
Notification: SendResponse 
Handler: StaticFile 
Error Code: 0x80070585 

Requested URL: http://localhost:80/iisstart.htm 
Physical Path: C:/inetpub/wwwroot/iisstart.htm 
Logon Method: Anonymous 
Logon User: Anonymous 
Request Tracing Directory: C:/inetpub/logs/FailedReqLogFiles 

Los registros de solicitud fallidos no son demasiado útiles, muestran lo siguiente para la advertencia:

411.  -MODULE_SET_RESPONSE_ERROR_STATUS 
ModuleName: RewriteModule 
Notification: SEND_RESPONSE 
HttpStatus: 500 
HttpReason: URL Rewrite Module Error. 
HttpSubStatus: 52 
ErrorCode: Invalid index. (0x80070585) 
ConfigExceptionInfo: 

Answer 1

La pregunta no muestra el código del cliente que está enviando la solicitud que causa ese error, pero:

El código del cliente debe estar usando XHR o la API de obtención (o usando jQuery u otra biblioteca que llame a uno de ellos), y ese código establece la propiedad XHR withCredentials en true o llama al constructor de Fetch Request con un objeto de opciones que tenga el opción de credentials configurada para include .

Cuando ese es el caso y la respuesta del servidor tiene un encabezado Access-Control-Allow-Origin: * , su navegador registrará el error citado en la pregunta.

Entonces, una solución es cambiar el código del cliente de JavaScript para que no establezca XHR withCredentials en true y no llame al constructor de Fetch Request con credentials: ''include'' .

Otra solución es hacer que su código del lado del servidor tome el valor del encabezado de solicitud de Origin y hacer eco en el valor del encabezado de respuesta de Access-Control-Allow-Origin .

Para IIS, puede hacer eso con el Módulo de reescritura de URL agregando lo siguiente a su archivo de configuración de IIS (archivo Web.config o ApplicationHost.config en %SystemDrive%/inetpub/wwwroot/ ).

<configuration> 
    <system.webServer> 
        <rewrite> 
            <rules> 
                <rule name="Capture Origin Header"> 
                    <match url=".*" /> 
                    <conditions> 
                        <add input="{HTTP_ORIGIN}" pattern=".+" /> 
                    </conditions> 
                    <serverVariables> 
                        <set name="CAPTURED_ORIGIN" value="{C:0}" /> 
                    </serverVariables> 
                    <action type="None" /> 
                </rule> 
            </rules> 
            <outboundRules> 
                <rule name="Set-Access-Control-Allow-Origin for known origins"> 
                    <match serverVariable="RESPONSE_Access-Control-Allow-Origin"
                           pattern=".+" negate="true" /> 
                    <action type="Rewrite" value="{CAPTURED_ORIGIN}" /> 
                </rule> 
            </outboundRules> 
        </rewrite> 
    </system.webServer> 
</configuration>

A continuación, elimine cualquier otro código / configuración existente que esté configurando Access-Control-Allow-Origin: * .

Nota: Lo anterior es una versión modificada del archivo de configuración de ejemplo en la guía paso a paso Habilitar CORS para dominios específicos en IIS usando Reescritura de URL .

Answer 2

Tuve el mismo problema, tenía enlaces http y https en un sitio web con Access-Control-Allow-Origin: * en este caso, la solicitud http fallará con el error anterior. puede crear un sitio web independiente para el enlace HTTP y eliminar el encabezado Access-Control-Allow-Origin.

Answer 3

Solo para cerrar el ciclo de esto. Las respuestas y sugerencias publicadas anteriormente funcionaron bien para un sitio web exclusivo de IIS con respecto a este tema.

Mi problema fue un error en la biblioteca IIS-Node que finalmente me obligó a migrar toda la pila a NodeJS y ejecutar todos los módulos de forma nativa en Nodo.