Mopidy: Falta el encabezado de respuesta CORS para activos de archivos estáticos
Describe el error
Al controlador de http le faltan los encabezados adicionales para Access-Control-Allow-* . Esto ya está hecho correctamente para el controlador JSON-RPC.
El problema es que no es posible obtener activos estáticos debido a problemas de CORS, incluso el origen de la solicitud está en la lista blanca.
Como reproducir
Asegúrese de que el dominio que está utilizando esté incluido en la lista blanca en la configuración:
[http]
allowed_origins = localhost:8080
Inicie el cliente, abra la consola e intente recuperar un activo que conozca:
fetch('http://localhost:6080/local/feecccb956b1764b8245244611a61e15-600x600.jpeg')
Esto dará el siguiente tipo de error:
Access to fetch at 'http://localhost:6680/data/local/feecccb956b1764b8245244611a61e15-600x600.jpeg' from origin 'http://localhost:8080' has been blocked by CORS policy: No 'Access-Control-Allow-Origin' header is present on the requested resource. If an opaque response serves your needs, set the request's mode to 'no-cors' to fetch the resource with CORS disabled.
Comportamiento esperado
Las solicitudes de origen cruzado deberían funcionar para activos estáticos si el origen de la solicitud está incluido en la lista blanca.
Medio ambiente
Por favor complete la siguiente información:
- Sistema operativo:
5.9.4-arch1-1 - ¿Ejecuta Mopidy como servicio o en la terminal?
service - Su configuración (salida de
sudo mopidyctl config): el comando falla - Versiones de software (salida de
sudo mopidyctl deps): el comando falla
Contexto adicional
Creo que el problema debería ser bastante fácil de resolver ampliando la función set_extra_headers () de StaticFileHandler como ya se hizo aquí . ¿Es eso correcto?
weilbith
Todos 7 comentarios
Desafortunadamente, el encabezado Access-Control-Allow-Origin solo permite un valor único. Se vuelve un poco más complicado cuando queremos admitir varios valores de nuestra lista configurada:
Limitar los posibles valores de Access-Control-Allow-Origin a un conjunto de orígenes permitidos requiere un código en el lado del servidor para verificar el valor del encabezado de solicitud de Origin, compararlo con una lista de orígenes permitidos y luego si el valor de Origin está en la lista, para establecer el valor de Access-Control-Allow-Origin en el mismo valor que el valor de Origin.
Y es aún peor porque, según tengo entendido, no puede confiar en que sea un encabezado de solicitud de Origin a menos que sea una solicitud CORS . Y tampoco puede confiar en que haya un encabezado Referer para ninguna solicitud HTTPS (que sería el encabezado alternativo a usar). Esto es lo que llevó al código de protección CSRF bastante complicado que garantiza que todo haga un baile CORS antes del vuelo (nota: creo que esto ha cambiado desde entonces y todos los POST del navegador ahora tienen un encabezado de origen). Dudo que lo queramos aquí.
Dado que StaticFileHandler solo se ocupa de solicitudes GET 'seguras', tal vez esté bien establecer el encabezado de respuesta "Access-Control-Allow-Origin: *"?
kingosticks
en 1 ene. 2021
Pensando en esto más (a pesar de no querer), es seguro decir que cualquier navegador preocupado por mantener la política CORS habrá enviado un encabezado de Origin. Entonces, podemos hacer condicionalmente check_origin() función del encabezado Origin que se está configurando, y luego, si está permitido, copiar el valor del encabezado en el encabezado de respuesta Access-Control-Allow-Origin como de costumbre. Si no hay encabezado de origen, nuestro comportamiento puede permanecer sin cambios.
kingosticks
en 1 ene. 2021
Pensando más en esto (a pesar de no querer)
Lo siento. :no ver el mal:
Bien, entonces, ¿qué tienen ahora de especial los activos estáticos? ¿Por qué no podemos simplemente reutilizar toda la lógica genial que ya existe? Me refiero a que todas las comprobaciones del encabezado de origen, etc. pp ya están allí si no me equivoco. ¿No podemos usarlo y establecer condicionalmente los encabezados? :pensando:
weilbith
en 2 ene. 2021
Solo que las solicitudes GET y la política CORS no son lo mismo que la protección CRSF para métodos 'inseguros' con efectos secundarios como POST. Son problemas diferentes y la solución no es exactamente la misma.
Pero podemos reutilizar la mayor parte, sí, eso es lo que estaba tratando de decir en mi segundo mensaje.
kingosticks
en 2 ene. 2021
¿Tenía sentido mi último mensaje? ¿Le apetece implementar la solución o debo agregarla a la lista de cosas por hacer?
kingosticks
en 7 ene. 2021
Sí, tiene sentido. : smiley:
Sería genial si pudieras agregarlo a la lista. Aunque pude examinar el código y comprender lo que falta, tengo muy menos conocimiento del marco que se usa aquí y de lo que tendría que ocuparme. Perdón. :no ver el mal:
weilbith
en 7 ene. 2021
Creo que es una solución bastante aislada, pero sí, requiere un vistazo a Tornado, así que no se preocupe, gracias por informarlo.
kingosticks
en 7 ene. 2021
Temas relacionados
jodal
·
15Comentarios
kingosticks
·
12Comentarios
handsomegui
·
12Comentarios
simonsmiley
·
9Comentarios
voidmann
·
11Comentarios
Comentario más útil
Creo que es una solución bastante aislada, pero sí, requiere un vistazo a Tornado, así que no se preocupe, gracias por informarlo.