El motor de reglas ofrece una interfaz gráfica de usuario para configurar reglas condicionales. Estas reglas analizan los parámetros de las solicitudes de los usuarios y determinan si aplica una configuración específica. De este modo, usted obtiene un control flexible y preciso sobre la aplicación de las políticas de configuración de CDN DCDN.
Contexto
La consola de CDN DCDN de Alibaba Cloud ofrece funciones básicas, como configurar la caducidad de la caché y reescribir los parámetros de obtención en origen. Estas opciones cubren la mayoría de los requerimientos generales. Sin embargo, para necesidades específicas, como obtener solicitudes cuya ruta contenga /example desde una dirección de origen determinada, debe usar el motor de reglas para implementar configuraciones personalizadas. Además, CDN DCDN de Alibaba Cloud proporciona la función EdgeScript, que admite una personalización muy flexible.
|
Capacidades |
Funciones básicas |
Funciones básicas y motor de reglas |
EdgeScript |
|
Implementación de funciones |
Configuraciones de uso general |
Permite crear reglas de filtrado condicional mediante una interfaz gráfica. Admite varios tipos de coincidencia, como URI, Header, Cookie y Query String, además de combinaciones lógicas AND/OR. |
Ofrece una personalización altamente flexible. Es ideal para escenarios avanzados que requieren scripts personalizados. |
|
Escenarios |
Escenarios de uso general |
Escenarios personalizados avanzados |
Escenarios totalmente personalizados |
|
Facilidad de uso (conocimientos técnicos necesarios) |
Alta |
Media |
Baja |
|
Flexibilidad de configuración |
Baja |
Media |
Alta |
Lógica compleja y EdgeScript
El motor de reglas admite combinaciones lógicas AND/OR básicas, por lo que resulta adecuado para la mayoría de los escenarios de filtrado condicional. No obstante, los siguientes casos le ayudarán a decidir si conviene utilizar EdgeScript:
Coincidencia compleja con expresiones regulares: El operador de expresiones regulares del motor de reglas está deshabilitado de forma predeterminada. Debe enviar un ticket para solicitar su habilitación. Si necesita usar expresiones regulares con frecuencia, EdgeScript admite este tipo de coincidencias de forma nativa, lo cual resulta más práctico.
Combinaciones multidimensionales precisas: Configurar evaluaciones complejas que combinan varios criterios resulta engorroso en el motor de reglas. Un ejemplo es hacer coincidir tanto la IP del cliente como el User-Agent mediante expresiones regulares (por ejemplo, bloquear solicitudes de un rango de IP específico donde el User-Agent contiene una palabra clave concreta). EdgeScript le permite combinar varias condiciones de manera flexible mediante lógica de scripts.
Control de acceso por IP granular en varios directorios: EdgeScript le permite otorgar acceso a distintos rangos de direcciones IP sobre diferentes directorios. Por ejemplo, puede permitir que un rango de direcciones IP acceda a todos los directorios, que una dirección IP específica acceda solo a uno y denegar el resto. Utilice
match_repara hacer coincidir las direcciones IP y las rutas URI. Usereturn truepara permitir la solicitud yexit(403)para denegarla.
Límites
Se pueden crear hasta 50 condiciones de regla por nombre de dominio.
Cada condición de regla puede contener un máximo de 20 subreglas.
No es posible usar los operadores de coincidencia o no coincidencia de expresiones regulares al configurar condiciones de regla en la consola o mediante openapi. Sin embargo, sí se pueden consultar las configuraciones existentes que utilicen estos operadores. Para emplearlos, use ESA.
Una condición de regla se puede referenciar hasta cinco veces entre todas las funciones de un mismo nombre de dominio.
Las condiciones de regla admiten hasta tres niveles de anidamiento. Cada nivel puede tener sus propias relaciones lógicas independientes.
Si una función, como establecer el tiempo de caducidad de la caché o modificar los encabezados de solicitud salientes, referencia una condición de regla, la prioridad de dicha condición determina el orden de ejecución, no el orden de configuración de la función.
-
Entre los límites anteriores, los máximos de 50 condiciones de regla, 20 subreglas y 3 niveles de anidamiento son estrictos y no se pueden aumentar bajo solicitud. El número total máximo de referencias a condiciones de regla entre todas las funciones de un único nombre de dominio acelerado, que es 5 de forma predeterminada, sí se puede incrementar previa solicitud.
Para aumentar el número total de veces que se pueden referenciar las condiciones de regla en un solo nombre de dominio (cinco de forma predeterminada), envíe un ticket. Incluya la siguiente información en el ticket: el nombre de dominio acelerado para el que desea aumentar el límite, el número objetivo de referencias y una descripción de su escenario de negocio.
Al agregar otro nombre de dominio acelerado, envíe un ticket independiente para aumentar el número de referencias a condiciones de regla de ese dominio. El proceso es el mismo que en la primera solicitud.
Cada condición admite un máximo de 32 valores de coincidencia para tipos como la IP del cliente, el URI, la extensión de archivo, el nombre de archivo y el User-Agent. Si cuenta con una lista de permitidos de IP de clientes extensa, agrupe varias direcciones IP en bloques CIDR (por ejemplo,
120.209.XXX.X/24) para configurarlas y aprovechar mejor la capacidad de valores de coincidencia.Se pueden configurar hasta 32 valores de coincidencia de User-Agent. Los valores que superen este límite se ignoran. Para hacer coincidir una gran cantidad de User-Agents, utilice un comodín (
*) que agrupe valores similares. Por ejemplo,*Chrome*coincide con todas las versiones del navegador Chrome. También puede usar EdgeScript para aplicar una lógica de coincidencia más flexible.
Prioridad de funciones y lógica de ejecución
Al configurar el motor de reglas, tenga en cuenta las siguientes prioridades de funciones y la lógica de ejecución:
La protección contra hotlinking por Referer tiene prioridad sobre el motor de reglas: Cuando una solicitud incluye un encabezado Referer, el sistema primero la evalúa frente a las listas de bloqueo y de permitidos de Referer. Si coincide con la lista de permitidos, se autoriza su paso y se omite el motor de reglas. Si no coincide, el sistema la bloquea de inmediato. Cuando el encabezado Referer está vacío, la solicitud omite esta lógica y el motor de reglas la evalúa directamente.
Orden de ejecución de las funciones que usan condiciones de regla: Cuando funciones como Cache Expiration o Modify Outbound Request Header utilizan condiciones de regla, el sistema las ejecuta según la prioridad de dichas condiciones, no según el orden en que se configuraron. Por ejemplo, si Cache Expiration y Back-to-Origin Parameter Rewrite emplean condiciones de regla con distintas prioridades, el sistema las ejecutará de mayor a menor prioridad.
-
Solución de conflictos entre la autenticación de URL y la caché: Si observa un comportamiento inesperado tras configurar la autenticación de URL, como solicitudes accesibles sin parámetros de autenticación o enlaces válidos bloqueados por error, compruebe lo siguiente en este orden:
Compruebe si hay una lista de permitidos de WAF configurada. Esta lista podría omitir la lógica de autenticación de CDN DCDN y dejar pasar las solicitudes directamente.
Compruebe que la función Ignore URL Parameters no esté eliminando los parámetros de autenticación, como
auth_key. Si la configuración de ignorar parámetros de URL los filtra, se omite la validación de autenticación en los aciertos de caché.Confirme que Cache Key Rule no ignore el parámetro de autenticación. De ser así, las solicitudes con distintos parámetros de autenticación podrían recibir el mismo contenido almacenado en caché, lo que invalidaría la autenticación.
Sintaxis de las condiciones de regla
Una condición de regla combina una o más expresiones condicionales mediante operadores lógicos. A continuación se describe la sintaxis.
Operadores lógicos
Los operadores lógicos evalúan las condiciones del mismo nivel, incluidos los conjuntos de condiciones anidadas. Los operadores compatibles son and y or.
and(AND): Operador lógico AND. La coincidencia se produce únicamente si todas las condiciones son verdaderas.or(OR): Operador lógico OR. La coincidencia se produce si alguna condición es verdadera. Por ejemplo, al configurar varias condiciones de regla para el mismo encabezado de respuesta, puede agregar dicho encabezado bajo distintas condiciones. Ejemplo: cuando el URI contiene/path-aor el URI contiene/path-b, agregue el encabezado de respuesta.
Parámetros de una expresión condicional
Una expresión condicional es la unidad más detallada de una regla e incluye los siguientes parámetros:
|
Parámetro |
Parámetro de configuración correspondiente en la función condition para la configuración del nombre de dominio |
Descripción |
Obligatorio |
|
Coincidencia condicional |
match |
Especifica la expresión de coincidencia condicional. |
Sí |
|
Operador lógico |
logic |
Especifica el operador lógico de la expresión de coincidencia condicional. Los valores válidos son |
Sí |
|
Criterios |
criteria |
Especifica la matriz de expresiones condicionales que se evaluarán. |
Sí |
|
Tipo de coincidencia |
MatchType |
Especifica el tipo de información de la solicitud del cliente que se va a comparar. |
Sí |
|
Objeto de coincidencia |
MatchObject |
Precisa aún más el tipo de coincidencia. Por ejemplo, una dirección IP de cliente se puede definir como POP connection IP o XFF IP. |
No |
|
Operador de coincidencia |
MatchOperator |
Especifica la comparación que se va a ejecutar. |
Sí |
|
Valor de coincidencia |
MatchValue |
El valor con el que se comparan los datos de la solicitud del cliente. |
Sí |
|
Negar condición |
negate |
Especifica si se debe negar el resultado de la expresión condicional. Los valores válidos son true y false. |
Sí |
|
Distinción entre mayúsculas y minúsculas |
caseSensitive |
Especifica si el valor de coincidencia distingue entre mayúsculas y minúsculas. |
No |
|
Nombre de la condición de regla |
name |
Especifica el nombre de la condición de regla. |
Sí |
|
Estado |
status |
Especifica el estado de la condición de regla. |
Sí |
Configuración de expresiones condicionales
Tipo de coincidencia | Parámetro de configuración correspondiente en la función condition para la configuración del nombre de dominio | Descripción | Objeto de coincidencia | Operador de coincidencia | Valor de coincidencia | Distinción entre mayúsculas y minúsculas | Variable de nginx/tengine correspondiente |
Protocolo | scheme | El protocolo que utiliza la solicitud del cliente, como HTTP o HTTPS. | No aplicable |
|
| No aplicable | $scheme |
Método de solicitud | method | El método que utiliza la solicitud del cliente, como GET o PUT. | No aplicable |
|
| No aplicable | $request_method |
URI (ruta) | uri | La ruta en la URL de la solicitud del cliente, sin incluir los parámetros de solicitud. Por ejemplo: | No aplicable |
| Se admiten los comodines |
| $raw_uri o $uri |
Nombre de archivo | basename | El nombre del archivo que solicita el cliente. Por ejemplo: name1. | No aplicable |
| Se admiten los comodines |
| - |
Extensión de archivo | extension | La extensión del archivo que solicita el cliente. El sistema identifica la extensión como la subcadena que va desde el último punto (.) hasta el final del nombre de archivo. Por ejemplo: | No aplicable |
| Se admiten los comodines |
| - |
Nombre de host | hostname | El nombre de host en la solicitud del cliente. Orden de coincidencia: host en la URL de la solicitud > host en el encabezado de solicitud Host. | No aplicable |
| El host de la solicitud del cliente. Puede introducir varios valores. |
| $host o $http_host |
Dirección IP del cliente | clientip | La dirección IP del cliente. Se admiten IPv4 (por ejemplo, |
Nota Para obtener más información sobre POP connection IP y XFF IP, consulte . |
| Se admiten direcciones IPv6, como 240e:XXX:3004:2:3:0:0:3f7, y bloques CIDR, como 120.209.XXX.XXX/31. Puede introducir varios valores. | No aplicable | $remote_addr |
Versión de IP del cliente | clientipVer | La versión de IP de la dirección del cliente: IPv4 o IPv6. |
Nota Para obtener más información sobre POP connection IP y XFF IP, consulte . |
|
| No aplicable | - |
Proveedor de servicios de Internet (ISP) | geolocation | El ISP al que pertenece la dirección IP del cliente. |
Nota Para obtener más información sobre POP connection IP y XFF IP, consulte . |
| Puede seleccionar un ISP de la lista desplegable o introducir caracteres para filtrar las opciones. Se admite la búsqueda aproximada por ID o nombre. Puede introducir varios valores. | No aplicable | $ip_isp_id |
Geolocalización de IP | geolocation | La ubicación geográfica de la dirección IP del cliente. |
Nota Para obtener más información sobre POP connection IP y XFF IP, consulte . |
| Puede seleccionar una ubicación de la lista desplegable o introducir caracteres para filtrar las opciones. Se admite la búsqueda aproximada por ID o nombre. Puede introducir varios valores. | No aplicable | $ip_country_id |
Parámetro de solicitud | querystring | Un parámetro en la URL de la solicitud. | Introduzca el nombre del parámetro. |
| Se admiten los comodines |
| $arg_{name} |
Encabezado de solicitud | header | Un encabezado en la solicitud del cliente. | Puede introducir un nombre de parámetro o seleccionarlo de la lista desplegable. |
| Puede introducir varios valores. |
| $http_{name} |
Cookie | cookie | La cookie en la solicitud del cliente. | Introduzca el nombre de la cookie. |
| Se admiten los comodines |
| $cookie_{name} |
User-Agent | useragent | El User-Agent en el encabezado de la solicitud. | No aplicable |
| Puede seleccionar un valor de la lista desplegable o introducir un valor de User-Agent, como |
| $http_user_agent |
Range bucket | range | Hace coincidir un porcentaje específico de las solicitudes del cliente. | No aplicable |
| Introduzca un valor porcentual. | No aplicable | - |
Hora | time | La hora en que se produce la solicitud del cliente. Se expresa en UTC+8. Por ejemplo, 09:10~14:22. | No aplicable |
| Introduzca un intervalo de tiempo, como 09:10~14:22, que representa el periodo de 09:10 a 14:22. | No aplicable | - |
Nginx var | ngxvar | Utilice variables de Nginx si las anteriores no satisfacen sus necesidades. Para consultar la lista de variables compatibles, revise la documentación oficial de Nginx. | Puede seleccionar una variable de la lista desplegable o introducir un nombre de variable. Se admite la concatenación, como |
| Puede introducir varios valores. | No aplicable | ${name} |
Notas comunes de configuración para expresiones condicionales
Punto de inicio de la coincidencia de URI (ruta): En la coincidencia de URI, el valor corresponde a la parte de la ruta que comienza con el primer
/después del nombre de dominio, sin incluir el propio dominio ni los parámetros de solicitud. Por ejemplo, para la solicitudhttps://example.com/path/file.html?key=value, el valor de URI que realmente se compara es/path/file.html. El valor de coincidencia debe comenzar con/.Formato de coincidencia de extensión de archivo: Al configurar una coincidencia de extensión de archivo, el valor debe incluir un punto (
.). Por ejemplo, para hacer coincidir archivos.txt, introduzca.txten lugar detxt; de lo contrario, la coincidencia podría fallar.-
Ejemplos de uso de comodines: Las coincidencias de URI y de extensión de archivo admiten los comodines
?(coincide con cualquier carácter individual) y*(coincide con cualquier cantidad de caracteres). Ejemplos comunes:/*.pdf: coincide con todos los archivos PDF del directorio raíz./api/*/data: coincide con las rutas/api/que contienendataen cualquier subruta..??: coincide con todas las extensiones de archivo de dos caracteres, como.jsy.ts.
Modo de verificación de direcciones IP
El motor de reglas ofrece dos modos de verificación de direcciones IP. El modo seleccionado afecta la forma en que los POP de CDN DCDN identifican la dirección IP del cliente:
POP connection IP: este modo compara la dirección IP que el cliente usa para conectarse a un POP de CDN DCDN. Si el tráfico entre el cliente y el POP de CDN DCDN pasa por un servidor proxy, la IP de conexión del POP corresponde a la dirección IP del servidor proxy.
XFF IP: este modo compara la dirección IP más a la izquierda en el encabezado de solicitud x-forwarded-for. Independientemente de si se utiliza un servidor proxy entre el cliente y el POP de CDN DCDN, la XFF IP siempre es la dirección IP real del cliente.
La elección del modo de verificación depende de si la solicitud del cliente pasa por un servidor proxy antes de llegar a un POP de CDN DCDN.
Tenga en cuenta que la ubicación dentro de un POP de CDN DCDN donde surte efecto una función que hace referencia a una condición de regla también influye en el modo de verificación de direcciones IP que debe seleccionar. En las funciones de recuperación de origen que se aplican en los POP L2, el POP L1 por el que pasa la solicitud del usuario actúa como un servidor proxy intermedio.
Por ejemplo, suponga que la dirección IP real del cliente es 10.10.10.10 y la dirección IP del proxy es 192.168.0.1.
-
Sin servidor proxy:
El valor del encabezado de solicitud x-forwarded-for es
10.10.10.10.La dirección IP real del cliente (la IP más a la izquierda en el encabezado x-forwarded-for) = la dirección IP utilizada para establecer la conexión entre el cliente y el POP de CDN DCDN =
10.10.10.10.
-
Con servidor proxy:
El valor del encabezado de solicitud x-forwarded-for es
10.10.10.10,192.168.0.1.La dirección IP real del cliente (la IP más a la izquierda en el encabezado x-forwarded-for) =
10.10.10.10.La dirección IP utilizada para establecer la conexión entre el cliente y el POP de CDN DCDN = la dirección IP del servidor proxy =
192.168.0.1.La dirección IP real del cliente (la IP más a la izquierda en el encabezado x-forwarded-for) ≠ la dirección IP utilizada para establecer la conexión entre el cliente y el POP de CDN DCDN.
En algunas regiones, ciertos proveedores de servicios de Internet (ISP) asignan direcciones IP privadas a los usuarios finales. Como consecuencia, el nodo de CDN DCDN recibe la dirección IP privada del usuario.
Las direcciones IP privadas pertenecen a los tres rangos siguientes:
Direcciones IP privadas clase A:
10.0.0.0–10.255.255.255. Máscara de subred:10.0.0.0/8.Direcciones IP privadas clase B:
172.16.0.0–172.31.255.255. Máscara de subred:172.16.0.0/12.Direcciones IP privadas clase C:
192.168.0.0–192.168.255.255. Máscara de subred:192.168.0.0/16.
Operadores de coincidencia (matchOperator)
Operador | Parámetro de configuración correspondiente en la función condition para la configuración de nombres de dominio | Descripción |
equal to | El matchOperator se establece en equals. | La condición se cumple únicamente cuando la variable es exactamente igual o distinta del valor de comparación especificado. |
not equal to | El matchOperator se establece en equals y el parámetro negate se establece en true. | |
exists | El matchOperator se establece en exists. | La condición se cumple según si la variable especificada existe en la solicitud. |
not exists | El matchOperator se establece en exists y el parámetro negate se establece en true. | |
contains any | El matchOperator se establece en contains. | La condición se cumple si la variable contiene (o no contiene) cualquiera de los valores de comparación especificados. Se admite un máximo de 32 valores de comparación. Se admiten dos tipos de coincidencias de contenido:
|
does not contain any | El matchOperator se establece en contains y el parámetro negate se establece en true. | |
greater than | El matchOperator se establece en gt. | Es decir, |
less than | El matchOperator se establece en lt. | Es decir, |
greater than or equal to | El matchOperator se establece en ge. | Es decir, |
less than or equal to | El matchOperator se establece en le. | Es decir, |
regular expression match | El matchOperator se establece en regex. | Compara la variable con una expresión regular. Nota Si configura reglas en la consola o mediante OpenAPI, no puede utilizar estos operadores de expresiones regulares. Sin embargo, sí puede consultar las configuraciones existentes. Para usar los operadores de coincidencia relacionados con expresiones regulares, |
regular expression mismatch | El matchOperator se establece en regex y el parámetro negate se establece en true. |
Comodines
|
Comodín |
Descripción |
Ejemplo de coincidencia de ruta |
|
|
Coincide con cualquier carácter individual. |
|
|
|
Coincide con cero o más caracteres. |
|
Funciones que admiten condiciones de regla
Categoría | Función |
Configuración básica | |
Configuración de caché | |
Configuración de origen | |
Control de acceso | |
Optimización de rendimiento | |
Configuración de video | |
Limitación de tráfico |
Gestión de la configuración
Dónde consultar las acciones de ejecución: la página Rules Engine define únicamente las condiciones de regla, pero no configura directamente las acciones de ejecución. Debe consultar y gestionar las acciones específicas, como la expiración de caché, la reescritura de URL y la limitación de tráfico, en la página de la función que hace referencia a la regla. Por ejemplo, si una configuración de expiración de caché hace referencia a una condición de regla, deberá consultarla y modificarla en Cache Settings > Cache Expiration.
Remote Authentication no admite condiciones de regla: la función de autenticación remota no puede hacer referencia a condiciones de regla. Por lo tanto, no es posible usar el motor de reglas para controlar el alcance en el que esta función surte efecto.
Límite de tiempo de espera de autenticación: el campo Timeout de la función Remote Authentication acepta un valor máximo de 3000 milisegundos (3 segundos). El valor predeterminado es de 500 milisegundos, mientras que 3000 milisegundos representan el límite máximo que admite el sistema.
Casos de uso avanzados
Con el motor de reglas puede implementar las siguientes configuraciones avanzadas:
Limitación de velocidad diferenciada: si necesita limitar la velocidad de ciertas solicitudes y dejar otras sin restricción (por ejemplo, limitar las URL con parámetros de autenticación, pero no el resto), o bien configurar un límite alternativo, cree condiciones de regla que distingan las características de cada solicitud en el módulo Rules Engine. Después, en Rate Limiting for a Single Request, haga referencia a las distintas condiciones de regla y establezca un límite de velocidad diferente para cada una.
Enrutamiento canario de origen basado en IP: para implementar una versión canary basada en las direcciones IP de los clientes, o para dirigir las solicitudes de ciertas IP a distintos orígenes, cree una condición de coincidencia de IP en el motor de reglas. Luego, haga referencia a esa condición de regla en "Conditional origin" y especifique diferentes direcciones de origen.
Recomendación para arquitecturas de origen mixto: si requiere usar WAF y OSS como orígenes de manera simultánea, evite configurar varios orígenes principales directamente. En su lugar, utilice el motor de reglas para crear condiciones de coincidencia basadas en las rutas de URL. Posteriormente, especifique dinámicamente la dirección de origen para cada ruta en "Conditional origin" y así evitar conflictos entre múltiples orígenes.
Procedimiento
Inicie sesión en la consola de CDN.
En el panel de navegación izquierdo, haga clic en Domain Names.
En la página Domain Names, busque el nombre de dominio deseado y haga clic en Manage en la columna Actions.
En la barra de navegación izquierda del nombre de dominio especificado, haga clic en Rules Engine.
Haga clic en Add Rule.
En la página Add Rule, configure Rule Name y Rule Content.
Haga clic en Submit para completar la configuración.
Escenarios de configuración típicos
A continuación se describe cómo implementar tres escenarios de configuración comunes.
Escenario 1: control de acceso con lista de permitidos de IP y redirección del resto
Requisito: permitir el acceso al sitio web únicamente desde direcciones IP específicas y redirigir automáticamente todas las demás a una página de mantenimiento.
Enfoque de configuración:
En el módulo Rules Engine, cree una condición de regla. Establezca el tipo de coincidencia en Client IP address, el operador de coincidencia en does not contain any e introduzca las direcciones IP de la lista de permitidos como valores de comparación.
En "Cache configuration" > "Access URL rewrite", haga referencia a esta condición de regla y redirija las solicitudes coincidentes (es decir, aquellas provenientes de direcciones IP fuera de la lista de permitidos) hacia la URL de la página de mantenimiento especificada, como una página HTML alojada en OSS.
Notas:
Si las solicitudes de direcciones IP fuera de la lista de permitidos devuelven un error 403 en lugar de redirigirse, compruebe si existen varios orígenes OSS que generen un conflicto. Se recomienda que cada nombre de dominio de CDN DCDN apunte a un único origen principal de OSS.
Asegúrese de que la URL de la página de mantenimiento sea de acceso público y de que ninguna otra regla de control de acceso la bloquee.
Comportamiento predeterminado: cuando una regla de lista de permitidos de IP se asocia con una condición de coincidencia de ruta URI, la verificación de la lista aplica únicamente a las solicitudes que coinciden con dicha ruta. Las solicitudes que no coinciden se permiten de forma predeterminada. Para aplicar el control de acceso por IP a todas las rutas, utilice EdgeScript y escriba una lógica personalizada.
Escenario 2: protección de Referer y control por extensión de archivo
Requisito: restringir el acceso por Referer para archivos con extensiones específicas, pero permitir solicitudes con Referer vacío para esos mismos archivos.
Enfoque de configuración:
En el módulo Rules Engine, cree una condición de regla. Establezca el tipo de coincidencia en File extension, el operador de coincidencia en does not contain any e introduzca como valores de comparación las extensiones que desea eximir, por ejemplo
.pdf.En "Access control" > "Referer hotlink protection", haga referencia a esta condición de regla. Las solicitudes de extensiones distintas a las especificadas quedarán sujetas a la lista de permitidos o de bloqueo de Referer, mientras que las solicitudes con Referer vacío para las extensiones indicadas estarán exentas.
Escenario 3: bloqueo de acceso a archivos que no son imágenes ni videos
Requisito: un bucket de OSS se distribuye mediante la aceleración de CDN. Es necesario bloquear el acceso a archivos que no son multimedia, como los .html, a través de URL maliciosas manipuladas.
Enfoque de configuración:
En el módulo Rules Engine, cree una condición de regla. Establezca el tipo de coincidencia en File extension, el operador de coincidencia en contains any e introduzca
.html,.htm,.php,.asp,.jspcomo valores de comparación.Agregue otra condición de regla. Establezca Match Type en "Client IP", Match Operator en "Does not contain any" y Match Value en las direcciones IP de la lista de permitidos.
En "Access control", haga referencia a esta condición de regla y configure la devolución de un error 403 para las solicitudes coincidentes: aquellas provenientes de direcciones IP fuera de la lista de permitidos que soliciten archivos distintos de los formatos de imagen o video especificados.
Nota (restricciones de carga):
El motor de reglas de CDN únicamente limita el acceso, por lo que no controla las cargas de archivos. Para restringir los tipos de archivo durante la carga, utilice la API PostObject de OSS y configure una Policy que limite dichos tipos. Por ejemplo, al establecer starts-with $Content-Type image/, se rechazan las cargas de archivos que no sean imágenes, como los .html. La API PutObject de OSS no verifica los tipos de archivo, de modo que no bloquea archivos que no son multimedia durante la carga.