Como configurar el intercambio de recursos de origen cruzado (CORS) en DreamObjects

Generalidades

Este artículo describe cómo configurar las capacidades de uso compartido de recursos de origen cruzado (CORS) de DreamObjects tal como se implementa en Ceph, y está destinado a cualquier usuario que necesites configurar DreamObjects para su uso en varios dominios, como WebFonts, o cargas entre dominios. 

Antecedentes y casos de uso

El intercambio de recursos de origen cruzado (CORS) es un mecanismo que permite que los recursos restringidos (por ejemplo, fuentes) de una página web estén disponibles para otro dominio fuera del dominio desde el que se originó el recurso. Un recurso restringido es cualquier que viole la política del mismo origen del navegador.

En términos sencillos, una solicitud de política CORS es la forma en que el navegador determina si realmente se te permite realizar solicitudes no triviales de un dominio a otro. Algunos ejemplos canónicos de estos son WebFonts y cargas basadas en JavaScript (XMLHttpRequest) a un servicio de almacenamiento externo.

Caso de uso: cargas entre dominios

Históricamente, si un sitio tenía la función de carga de archivos, la carga (a través de un formulario) podía ocurrir en cualquier sitio. El navegador no consideró ninguna implicación de seguridad del POST en otro sitio. Sin embargo, el código JavaScript estaba sujeto a la política del mismo origen y no se le permitía contactar con otro dominio. Los formularios de carga elegantes que utilizan JavaScript y XMLHttpRequest estaban muy limitados por la política del mismo origen, especialmente a medida que los servicios de almacenamiento en la nube aumentaron en popularidad. Una política de CORS para cargar archivos mediante XMLHttpRequest debe especificar que el navegador puede POST/PUT un archivo si proviene de un sitio web determinado.

Caso de uso: uso de WebFont

WebFonts utiliza la política del mismo origen como parte de una respuesta a las necesidades de DRM para evitar que las fuentes se utilicen fuera de sus términos de licencia. Dejando a un lado cualquier discusión sobre la efectividad de esta política, las fuentes web deben poder funcionar en sitios web con necesidades específicas de diseño gráfico. La política de CORS para una WebFont debe especificar que está permitido descargar (solicitud GET) WebFont para su uso en un sitio web determinado.

Esta política del mismo origen es un mandato de la especificación CSS3-Fonts.

Uso de DreamObjects CORS

DreamObjects proporciona respuestas de política CORS a las solicitudes del navegador, según la configuración de CORS.

Una configuración de CORS en DreamObjects:

  • Incluye para qué sitio es una solicitud y también qué tipo de solicitud,
  • Se maneja individualmente para cada bucket, y
  • Usa la sintaxis de Amazon S3 para la configuración de CORS.

Construir una configuración CORS

Reglas para las políticas CORS

Las siguientes son las reglas generales para realizar una configuración CORS:

  • Una configuración CORS válida consta de 0 a 100 reglas CORS.
  • Cada regla debe incluir al menos un origen.
  • Un origen puede contener como máximo un wildcard *
  • Cada regla debe incluir al menos un método.
  • Los métodos admitidos son: GET, HEAD, PUT, POST, DELETE.
  • Cada regla puede contener una cadena de identificación de hasta 255 caracteres.
  • Cada regla puede especificar cero o más encabezados de solicitud permitidos (que el cliente puede incluir en la solicitud).
  • Cada regla puede especificar cero o más encabezados de respuesta expuestos (que se envían desde el servidor al cliente).
  • Cada regla puede especificar un tiempo de validez de caché de cero o más segundos. Si no se incluye, el cliente debe proporcionar su propio valor predeterminado.

Ejemplo de política de WebFont

Si necesitas alojar una Webfont en DreamObjects, querrás incluir una política como la del siguiente ejemplo (suponiendo que tu sitio es www.example.com y también funciona en example.com):

<CORSConfiguration>
<CORSRule>
    <ID>Allow WebFont for example.com</ID>
    <AllowedOrigin>https://www.example.com</AllowedOrigin>
    <AllowedOrigin>http://www.example.com</AllowedOrigin>
    <AllowedOrigin>https://example.com</AllowedOrigin>
    <AllowedOrigin>http://example.com</AllowedOrigin>
    <AllowedMethod>GET</AllowedMethod>
    <AllowedMethod>HEAD</AllowedMethod>
    <AllowedHeader>Content-*</AllowedHeader>
    <AllowedHeader>Host</AllowedHeader>
    <ExposeHeader>ETag</ExposeHeader>
    <MaxAgeSeconds>86400</MaxAgeSeconds>
</CORSRule>
</CORSConfiguration>

Ejemplo de política de AWS S3 JS

La siguiente política permite a los usuarios del AWS S3 JavaScript SDK, tanto en example.com como en www.example.com, tanto en HTTP como en HTTPS, cargar en DreamObjects, con los métodos PUT y POST:

<CORSConfiguration>
<CORSRule>
    <ID>example.com: Allow PUT & POST with AWS S3 JS
    SDK</ID>
    <AllowedOrigin>https://www.example.com</AllowedOrigin>
    <AllowedOrigin>http://www.example.com</AllowedOrigin>
    <AllowedOrigin>https://example.com</AllowedOrigin>
    <AllowedOrigin>http://example.com</AllowedOrigin>
    <AllowedMethod>PUT</AllowedMethod>
    <AllowedMethod>POST</AllowedMethod>
    <AllowedHeader>Origin</AllowedHeader>
    <AllowedHeader>Content-Length</AllowedHeader>
    <AllowedHeader>Content-Type</AllowedHeader>
    <AllowedHeader>Content-MD5</AllowedHeader>
    <AllowedHeader>X-Amz-User-Agent</AllowedHeader>
    <AllowedHeader>X-Amz-Date</AllowedHeader>
    <AllowedHeader>Authorization</AllowedHeader>
    <ExposeHeader>ETag</ExposeHeader>
    <MaxAgeSeconds>1800</MaxAgeSeconds>
</CORSRule>
<CORSRule>
    <ID>example.com: Allow GET with AWS S3 JS SDK</ID>
    <AllowedOrigin>*</AllowedOrigin>
    <AllowedMethod>GET</AllowedMethod>
    <AllowedMethod>HEAD</AllowedMethod>
    <AllowedHeader>*</AllowedHeader>
    <ExposeHeader>ETag</ExposeHeader>
    <MaxAgeSeconds>1800</MaxAgeSeconds>
</CORSRule>
</CORSConfiguration>

Ejemplo de política de wildcard (INSEGURO!)

La siguiente política, aunque es completamente insegura, permite TODOS los métodos de cualquier origen. Sin embargo, NO expone encabezados personalizados:

<CORSConfiguration>
<CORSRule>
    <ID>Allow
    everything</ID>
    <AllowedOrigin>*</AllowedOrigin>
    <AllowedMethod>GET</AllowedMethod>
    <AllowedMethod>HEAD</AllowedMethod>
    <AllowedMethod>PUT</AllowedMethod>
    <AllowedMethod>POST</AllowedMethod>
    <AllowedMethod>DELETE</AllowedMethod>
    <AllowedHeader>*</AllowedHeader>
    <MaxAgeSeconds>30</MaxAgeSeconds>
</CORSRule>
</CORSConfiguration>

Implementar una configuración CORS

Una minoría de clientes de S3 admite la implementación de configuraciones CORS. Consulta los enlaces en la sección Clients a continuación para ver ejemplos de implementación de una configuración CORS en varios clientes. Otros clientes que no figuran en la lista también pueden admitir las políticas de CORS, y la lista no debe considerarse exhaustiva o correcta garantizada (algunos clientes han experimentado un soporte CORS roto en algunos puntos).

s3cmd (1.6.0 y recientes)

Desde 1.6.0, S3cmd soporta la configuración o eliminación de una configuración CORS; sin embargo, no admite recuperarlo excepto como parte de una solicitud de "información".

Asegúrate de tener una instalación funcional de S3cmd antes de continuar.

# Set the CORS rules
s3cmd setcors rules.xml s3://bucketname
# Delete the CORS rules
s3cmd delcors s3://bucketname
# Get bucket info including CORS rules
s3cmd info s3://bucketname

Notas de compatibilidad

  • La funcionalidad wildcard que permite el uso de CUALQUIER origen no está disponible.
  • Los usuarios que necesitan la funcionalidad CORS DEBEN implementar su propia configuración CORS en los depósitos relevantes.

Ver también

 

¿Este artículo ha respondido sus preguntas?

Última actualización el PST.

¿Aún no encuentra lo que busca?