Creemos que hay una forma mejor de hacerlo. Por este motivo, a partir de hoy, los administradores pueden auditar fácilmente todas las sesiones de usuario activas y los datos asociados utilizados por sus políticas de Cloudflare One. Esto permite lo mejor de ambos mundos: controles muy granulares al mismo tiempo que se mantiene una capacidad mejorada de resolución y diagnóstico de problemas de las implementaciones Zero Trust en un único y sencillo panel de control. Ahora los administradores pueden acceder a la información que anteriormente se encontraba en el navegador de un usuario o que cambiaba dinámicamente, sin necesidad de molestar a un usuario final o de analizar los registros.

La autenticación y la autorización son los dos componentes que evalúa una política Zero Trust antes de permitir que un usuario acceda a un recurso.

La autenticación es el proceso de verificar la identidad de un usuario, un dispositivo o un sistema. Algunos de los métodos más comunes de autenticación son la especificación de nombres de usuario y contraseñas, la presentación de un certificado digital o incluso factores biométricos como una huella dactilar o un reconocimiento facial. La autenticación multifactor (MFA) requiere dos o más métodos independientes de autenticación para una mayor seguridad, por ejemplo, una clave de hardware junto con una contraseña.

La autorización es el proceso de otorgar o denegar el acceso a recursos o permisos específicos una vez que se ha autenticado con éxito una entidad. Define qué puede y no puede hacer la entidad autenticada en el sistema.

Las aplicaciones web, en las que nos centraremos, suelen utilizar cookies HTTP para gestionar la autenticación y la autorización.

Autenticación:

1. Inicio de sesión: cuando un usuario inicia sesión en una aplicación web especificando su nombre de usuario y contraseña, la aplicación verifica estas credenciales respecto a su base de datos o en un proveedor de identidad (IdP). También es posible aplicar otros métodos de autenticación para un mecanismo de autenticación de varios factores. Si estos coinciden, el servidor o el servicio de seguridad externo (p. ej., Cloudflare Access) considera que el usuario se ha autenticado.

2. Creación de cookies/tokens: el servidor crea a continuación una sesión para el usuario como una cookie o un token web JSON. La cookie es válida durante cierto tiempo, hasta que sea necesario que el usuario se vuelva a autenticar.

3. Envío y almacenamiento de cookies: el servidor envía una respuesta al navegador del usuario, y esta incluye en la cookie el ID de sesión y otra información de identificación sobre el usuario. A continuación, el navegador almacena esta cookie, que se utiliza para reconocer el usuario en sus solicitudes posteriores.

Autorización:

1. Solicitudes posteriores: para todas las solicitudes posteriores enviadas a la aplicación web, el navegador del usuario incluye automáticamente la cookie (con el ID de sesión y otra información de identificación) en la solicitud.

2. Verificación del lado del servidor: el servidor recibe los datos del usuario de la cookie y comprueba si la sesión es válida. Si es válida, el servidor recupera también los detalles del usuario y sus permisos de acceso asociados con ese ID de sesión.

3. Decisión de autorización: en función de los permisos de acceso del usuario, el servidor decide si se autoriza al usuario a realizar la operación solicitada o a acceder al recurso solicitado.

De esta forma, el usuario se mantiene autenticado (y su autorización se puede comprobar) para todas las solicitudes posteriores a su inicio de sesión, hasta que esta caduque o hasta que el usuario cierre la sesión.

En las aplicaciones web modernas, este estado de la sesión se suele almacenar como un token web JSON (JWT).

Los JWT se utilizan en muchas aplicaciones web modernas, y en soluciones de acceso a la red Zero Trust (ZTNA) como Cloudflare Access, para la autenticación y la autorización. Un JWT incluye una carga que codifica la información acerca del usuario y posiblemente otros datos, e incluye la firma del servidor para evitar su manipulación. Los JWT se utilizan a menudo sin estado, lo que significa que el servidor no mantiene una copia de cada JWT (simplemente los verifica y descodifica cuando llegan con las solicitudes). Esta condición "sin estado" de los JWT significa que no tienes que depender de un sistema central para gestionar las sesiones de los usuarios, lo que evita que surjan problemas de escalabilidad cuando aumente el número de usuarios que accedan a un sistema.

No obstante, esta condición "sin estado" de los JWT hace que la depuración de la autenticación basada en JWT resulte complicada si no se dispone del JWT específico de un usuario. Estas son las razones:

1. Especificidad de los tokens: cada JWT es específico de un usuario y de una sesión. Contiene información (afirmaciones) sobre el usuario, la autoridad emisora, la fecha y hora de emisión del token, la fecha de caducidad y posiblemente otros datos. Por lo tanto, para depurar un problema, a menudo necesitas el JWT exacto que causa el problema.

2. No hay registros del lado del servidor: puesto que los JWT son sin estado, el servidor no almacena las sesiones por defecto. No puede buscar tokens anteriores o su estado asociado, a menos que se haya diseñado específicamente para registrarlos. Esto no suele ser el caso, debido a consideraciones acerca de la privacidad y la minimización de los datos.

3. Problemas temporales: los problemas vinculados con los JWT pueden ser temporales (relacionados con el momento específico en que se ha utilizado el token). Por ejemplo, si un token había caducado cuando un usuario intentaba utilizarlo, necesitarías ese token específico para depurar el problema.

4. Privacidad y seguridad: los JWT pueden contener información confidencial, por lo que se deben manejar cuidadosamente. Obtener un JWT de un usuario podría exponer su información personal o sus credenciales de seguridad a quienquiera que esté depurando el problema. Asimismo, si un usuario envía su JWT mediante un canal no seguro a un desarrollador o a un servicio de asistencia informática, este podría ser interceptado (Cloudflare lanzó recientemente una solución gratuita, HAR Sanitizer, para ayudar a mitigar este problema).

Estos factores dificultan la resolución de problemas vinculados con la autenticación basada en JWT si no se dispone del token específico.

Nos propusimos desarrollar una forma mejor de depurar los problemas relacionados con la identidad de un usuario en Cloudflare Zero Trust sin necesidad de compartir los JWT o los archivos HAR. Ahora los administradores pueden ver la identidad del registro de un usuario (que se utiliza para las políticas de Gateway) y todas las sesiones de Access activas.

Esta información de la sesión incluye la identidad completa evaluada por Zero Trust, que incluye las afirmaciones del IdP, la información acerca de la postura del dispositivo, el contexto de red y más. Gracias a Cloudflare Workers KV, hemos podido desarrollar esta función sin añadir más carga a la lógica de autenticación de Access. Cuando un usuario se autentica con Access, su identidad asociada se guarda de inmediato en un par clave-valor en Workers KV. Todo esto tiene lugar en el contexto del evento de autenticación del usuario, lo que significa que el impacto en la latencia o la dependencia de un servicio externo son mínimos.

Esta función está disponible para todos los clientes en todos los planes Zero Trust. Si deseas empezar con Cloudflare Zero Trust, regístrate hoy mismo para conseguir una cuenta gratuita para hasta 50 usuarios. O bien colabora con los expertos de Cloudflare para comentar las opciones SSE o SASE para tu organización y abordar tus casos Zero Trust paso a paso.

¿Por qué no es suficiente el almacenamiento de activos en caché? Sí, el almacenamiento en caché mejora el rendimiento, pero una mejora significativa en ese aspecto también trae consigo dolores de cabeza. CDN puede adivinar qué activos debe almacenar en caché, pero solo mediante la suposición. Configurar su sitio para obtener el máximo rendimiento siempre ha sido un proceso propenso a errores que requiere una amplia colección de reglas y encabezados esotéricos. Incluso cuando está todo perfectamente configurado, casi nada se almacena en caché para siempre, y a menudo las preciadas solicitudes siguen teniendo que viajar hasta su origen (donde sea que esté). La invalidación de la memoria caché es, después de todo, uno de los problemas más difíciles en la ciencia de la computación.

Esto genera la pregunta: en lugar de mover bytes desde el origen al límite poco a poco de forma descoordinada, ¿por qué no empujar todo el origen al límite?

Hace dos años, para la Semana de Aniversario, anunciamos Cloudflare Workers, una forma para que los desarrolladores escriban y ejecuten JavaScript y WebAssembly en nuestra red en 194 ciudades de todo el mundo. Un año después, lanzamos Workers KV, nuestra tienda distribuida de clave-valor que proporcionó a los desarrolladores la capacidad de almacenar el estado en el límite en esas mismas ciudades.

Workers Sites aprovecha el poder de Workers y Workers KV al permitir que los desarrolladores carguen sus sitios directamente al límite y más cerca de los usuarios finales. Nacido en el límite, Workers Sites es lo que creemos que debería ser el desarrollo moderno en la web, nativamente seguro, rápido y masivamente escalable. Se invierte menos tiempo en la configuración y se invierte más tiempo en el código y en el contenido en sí.

Los Workers Sites se implementan con unos pocos comandos de terminal y pueden servir para un sitio generado por cualquier generador de sitios estáticos, como Hugo, Gatsby o Jekyll. Con Wrangler (nuestra CLI), puede subir los activos de su sitio directamente a KV. Cuando llega una solicitud a su sitio Workers, el Cloudflare Worker generado por Wrangler leerá y servirá el activo de KV, con los encabezados apropiados (no es necesario preocuparse por el Content-Type ni por el Cache-Control; de eso nos ocupamos nosotros).

Los Workers Sites se pueden usar para implementar cualquier sitio estático, como un blog, sitios de marketing o un portafolio.  Si alguna vez decide que su sitio necesita volverse un poco menos estático, su Worker no es más que código; edítelo y extiéndalo hasta que tenga un sitio dinámico funcionando en todo el mundo.

Para comenzar a trabajar con los Workers Sites, primero debe registrarse en Workers. Después de seleccionar su subdominio Workers.dev, elija el plan Workers Unlimited (desde $5/mes) para obtener acceso a Workers KV y tener la posibilidad de implementar los Workers Sites.

Después de registrarse en Workers Unlimited, deberá instalar la CLI para Workers: Wrangler. Wrangler se puede instalar desde NPM o Cargo:

Una vez que instale Wrangler, estará listo para implementar su sitio estático, con los siguientes pasos:

# NPM Installation
npm i @cloudflare/wrangler -g
# Cargo Installation
cargo install wrangler

1. Ejecute wrangler init --site en el directorio que contiene los activos creados de su sitio estático

2. Complete el archivo wrangler.toml recién creado con su cuenta y los detalles del proyecto

3. Publique su sitio con wrangler publish

También puede consultar nuestra documentación de referencia de los Workers Sites o seguir el tutorial completo para create-react-app en los documentos.

Si prefiere empezar con un video, ¡no hay ningún problema! Este video lo guiará a través de la creación e implementación de su primer sitio de Workers:

Además de mejorar la experiencia del desarrollador, trabajamos mucho tras bastidores al asegurarnos de que tanto las implementaciones como los sitios en sí sean increíblemente rápidos: nos complace compartir cómo lo hacemos con usted en nuestra publicación técnica de blog.

Para probar el rendimiento de los Workers Sites tomamos uno de nuestros sitios personales y lo implementamos para ejecutar algunos puntos de referencia. Esta prueba fue hecha para nuestro sitio, pero sus resultados pueden variar.

Una forma común de comparar el rendimiento de su sitio es usar Google Lighthouse, que puede hacer directamente desde la pestaña Auditorías de su navegador Chrome.

Así que pasamos la primera prueba con gran éxito: ¡100! Sin embargo, ejecutar un punto de referencia desde su propia computadora presenta un sesgo: sus usuarios no están necesariamente donde usted está. De hecho, cada vez más sus usuarios están donde usted no está.

Desde dónde se realiza la evaluación comparativa es realmente importante: realizar pruebas desde diferentes lugares producirá resultados diferentes. La evaluación comparativa desde Seattle y el contacto con un servidor en la costa oeste dice muy poco sobre su rendimiento global.

Decidimos usar una herramienta llamada Catchpoint para ejecutar puntos de referencia desde ciudades de todo el mundo. Para ver cómo nos comparamos, implementamos el sitio en tres plataformas de implementación de sitios estáticos diferentes, incluidos Workers Sites.

Dado que los proveedores ofrecen regiones de centros de datos en las costas de Estados Unidos o Europa central, es común ver un buen rendimiento en regiones como América del Norte, y en ellas todo funciona perfectamente:

Pero, ¿qué sucede con sus usuarios del resto del mundo? El rendimiento es aún más crítico en esas regiones: los primeros usuarios no se conectarán a su sitio en una MacBook Pro, cuya conexión es increíblemente rápida. Los Workers Sites le permiten llegar a esas regiones sin ningún esfuerzo adicional de su parte: cada vez que nuestro mapa crece, su presencia global aumenta con él.

Llevamos a cabo la tarea de ejecutar algunos puntos de referencia desde diferentes partes del mundo para usted, y nos complace compartir los resultados:

Implementar su próximo sitio con los Workers Sites es fácil y conduce a un gran rendimiento, por lo que pensamos que era correcto que implementáramos los Workers Sites nosotros mismos. ¡Con este anuncio, también estamos suministrando los documentos de Cloudflare Workers! Y ahora se les brinda servicio desde un centro de datos de Cloudflare cerca de usted usando los Workers Sites.

¡Estamos ansiosos por ver qué implementa con los Workers Sites!

¿Ha creado algo interesante con Workers o Workers Sites? ¡Háganoslo saber @CloudflareDev!

Workers KV es una base de datos de clave-valor, altamente distribuida y de coherencia eventual que amplía el perímetro global de Cloudflare. Permite almacenar miles de millones de pares clave-valor y leerlos en una latencia ultrabaja en cualquier parte del mundo. Ahora puede crear aplicaciones completas con el rendimiento de una memoria caché estática de red de entrega de contenidos (CDN, _Content Delivery Networ_k).

Workers es una plataforma que le permite ejecutar JavaScript en el perímetro global de Cloudflare de más de 175 centros de datos. Con solo unas pocas líneas de código, puede enrutar solicitudes HTTP, modificar respuestas o incluso crear nuevas respuestas sin un servidor de origen.

// A Worker that handles a single redirect,
// such a humble beginning...
addEventListener("fetch", event => {
  event.respondWith(handleOneRedirect(event.request))
})

async function handleOneRedirect(request) {
  let url = new URL(request.url)
  let device = request.headers.get("CF-Device-Type")
  // If the device is mobile, add a prefix to the hostname.
  // (eg. example.com becomes mobile.example.com)
  if (device === "mobile") {
    url.hostname = "mobile." + url.hostname
    return Response.redirect(url, 302)
  }
  // Otherwise, send request to the original hostname.
  return await fetch(request)
}

Los clientes acudieron rápidamente a nosotros con casos prácticos que requerían una manera de almacenar datos permanentes. Siguiendo nuestro ejemplo anterior, es fácil manejar una redirección única, pero ¿qué sucede si quieren manejar miles de millones? Tendría que incrustar los datos directamente en el código fuente de su secuencia de comandos de Workers, adaptar todo a menos de un 1 MB y volver a implementarlo cada vez que quiera hacer un cambio: ¡de locos! Por eso creamos Workers KV.

// A Worker that can handle billions of redirects,
// now that's more like it!
addEventListener("fetch", event => {
  event.respondWith(handleBillionsOfRedirects(event.request))
})

async function handleBillionsOfRedirects(request) {
  let prefix = "/redirect"
  let url = new URL(request.url)
  // Check if the URL is a special redirect.
  // (eg. example.com/redirect/<random-hash>)
  if (url.pathname.startsWith(prefix)) {
    // REDIRECTS is a custom variable that you define,
    // it binds to a Workers KV "namespace." (aka. a storage bucket)
    let redirect = await REDIRECTS.get(url.pathname.replace(prefix, ""))
    if (redirect) {
      url.pathname = redirect
      return Response.redirect(url, 302)
    }
  }
  // Otherwise, send request to the original path.
  return await fetch(request)
}

Con unos pocos cambios de nuestro ejemplo anterior, escalamos de una redirección a miles de millones, y eso es solo una muestra de lo que se puede hacer con Workers KV.

Los almacenes de datos distribuidos suelen seguir el modelo del teorema CAP, que establece que los sistemas distribuidos solo pueden elegir entre 2 de las 3 siguientes garantías:

• Consistency (coherencia): ¿mis datos son los mismos en todas partes?

• Availability (disponibilidad): ¿es posible acceder a mis datos en todo momento?

• Partition (tolerancia a particiones): ¿mis datos resisten las interrupciones regionales?

Con Workers KV preferimos garantizar la disponibilidad y la tolerancia a particiones. Esta combinación se conoce comocoherencia eventual, que le da a Workers KV dos ventajas competitivas únicas:

• Las lecturas son ultrarrápidas (promedio de 12 ms), ya que se activan a través de nuestra tecnología de almacenamiento en caché.

• Los datos están disponibles en más de 175 centros de datos perimetrales y son resistentes a las interrupciones regionales.

Sin embargo, la coherencia eventual trae aparejadas ciertas desventajas. Si dos clientes escriben valores diferentes para la misma clave al mismo tiempo, el último cliente que escribe es el que termina “ganando”, y su eventual valor se vuelve coherente a nivel global. Esto también significa que si un cliente escribe a una clave y ese mismo cliente lee la misma clave, los valores pueden no ser coherentes durante un breve período de tiempo.

Para ayudar a entender esta situación, presentamos un ejemplo de la vida real entre tres amigos:

• Supongamos que Matthew, Michelle y Lee están planeando su almuerzo semanal.

• Matthew decide que saldrán a comer sushi.

• Matthew le cuenta a Michelle sus planes de comer sushi; Michelle está de acuerdo.

• Lee, sin conocer los planes, le dice a Michelle que es pizza lo que comerán.

Una hora más tarde, Michelle y Lee están esperando en la pizzería mientras Matthew está sentado solo en el restaurante de sushi, ¿qué sucedió? Podemos decir que se debió al carácter eventual de su acuerdo previo, porque después de esperar unos minutos, Matthew mira su calendario actualizado y se termina enterando del nuevo plan: salían a comer pizza.

Si bien en la vida real puede tardar unos minutos, Workers KV es mucho más rápida. Puede lograr la coherencia global en menos de 60 segundos. Además, cuando un Worker escribe a una clave y de inmediato lee esa misma clave, se espera que los valores sean coherentes si ambas operaciones proceden de la misma ubicación.

Ahora que comprende los beneficios y las desventajas de usar la coherencia eventual, ¿cómo puede saber si es la solución de almacenamiento adecuada para su aplicación? En pocas palabras, si desea tener disponibilidad global con lecturas ultrarrápidas, Workers KV es la herramienta indicada para usted.

Sin embargo, si su aplicación escribe con frecuencia a la misma clave, hay que tener algo más en cuenta. Lo denominamos “el problema de Matthew”: ¿Está de acuerdo con que los Matthew del mundo en ocasiones vayan al restaurante equivocado?

Uno puede imaginar casos prácticos (como nuestro ejemplo de redirección de Worker) en los que esto no representa ninguna diferencia sustancial. Pero si quiere hacer un seguimiento del saldo de la cuenta bancaria de un usuario, no sería nada bueno que se mostraran dos saldos al mismo tiempo, ya que el cliente podría comprar algo con dinero que ya ha gastado.

A continuación presentamos ejemplos de aplicaciones que se han desarrollado con KV:

• Redirecciones masivas: maneje miles de millones de redirecciones HTTP.

• Autenticación de usuario: valide las solicitudes de usuario a su API.

• Claves de traducción: localice sus páginas web de manera dinámica.

• Datos de configuración: establezca quién puede acceder a su origen.

• Funciones de paso: sincronice datos de estado entre las funciones de varias API.

• Almacén de archivos perimetrales: aloje grandes cantidades de archivos pequeños.

Hemos destacado varios de esos casos prácticos en nuestro blog.post anterior. También tenemos algunos tutoriales de código más detallados, que incluyen un artículo del blog recientemente publicado sobre cómo crear una lista de tareas con Worker KV en línea.

Por lejos, la solicitud más común era facilitar la escritura de datos a Workers KV. Por esa razón, estamos lanzando tres nuevos métodos para mejorar esa experiencia:

Si quiere importar los datos existentes en Workers KV, no querrá pasar por la tediosa tarea de enviar una solicitud HTTP por cada par clave-valor. Por esa razón, agregamos un punto de conexión masivo a la API de Cloudflare. Ahora, puede cargar hasta 10 000 pares (hasta 100 MB de datos) en una sola solicitud PUT.

curl "https://api.cloudflare.com/client/v4/accounts/ \
     $ACCOUNT_ID/storage/kv/namespaces/$NAMESPACE_ID/bulk" \
  -X PUT \
  -H "X-Auth-Key: $CLOUDFLARE_AUTH_KEY" \
  -H "X-Auth-Email: $CLOUDFLARE_AUTH_EMAIL" \
  -d '[
    {"key": "built_by",    value: "kyle, alex, charlie, andrew, and brett"},
    {"key": "reviewed_by", value: "joaquin"},
    {"key": "approved_by", value: "steve"}
  ]'

Analicemos un caso práctico de ejemplo: usted desea descargar la traducción de su sitio web a Workers. Como usted lee las claves de traducción con más frecuencia que cuando las actualiza, esta aplicación funciona bien con el modelo de coherencia eventual de Workers KV.

En este ejemplo, usamos Crowdin, una famosa plataforma para administrar datos de traducción. Worker responde a un punto de conexión /translate, descarga todas sus claves de traducción y las escribe de forma masiva en Worker KV para que usted pueda leerlas más tarde en nuestro centro perimetral:

addEventListener("fetch", event => {
  if (event.request.url.pathname === "/translate") {
    event.respondWith(uploadTranslations())
  }
})

async function uploadTranslations() {
  // Ask crowdin for all of our translations.
  var response = await fetch(
    "https://api.crowdin.com/api/project" +
    "/:ci_project_id/download/all.zip?key=:ci_secret_key")
  // If crowdin is responding, parse the response into
  // a single json with all of our translations.
  if (response.ok) {
    var translations = await zipToJson(response)
    return await bulkWrite(translations)
  }
  // Return the errored response from crowdin.
  return response
}

async function bulkWrite(keyValuePairs) {
  return fetch(
    "https://api.cloudflare.com/client/v4/accounts" +
    "/:cf_account_id/storage/kv/namespaces/:cf_namespace_id/bulk",
    {
      method: "PUT",
      headers: {
        "Content-Type": "application/json",
        "X-Auth-Key": ":cf_auth_key",
        "X-Auth-Email": ":cf_email"
      },
      body: JSON.stringify(keyValuePairs)
    }
  )
}

async function zipToJson(response) {
  // ... omitted for brevity ...
  // (eg. https://stuk.github.io/jszip)
  return [
    {key: "hello.EN", value: "Hello World"},
    {key: "hello.ES", value: "Hola Mundo"}
  ]
}

Ahora, cuando quiere traducir una página, todo lo que tiene que hacer es leer en Workers KV:

async function translate(keys, lang) {
  // You bind your translations namespace to the TRANSLATIONS variable.
  return Promise.all(keys.map(key => TRANSLATIONS.get(key + "." + lang)))
}

De forma predeterminada, los pares clave-valor almacenados en Workers KV duran para siempre. Sin embargo, puede que a veces quiera que los datos se eliminen automáticamente después de un cierto período de tiempo. Es por eso que añadimos las opcionesexpiration y expirationTtl para las operaciones de escritura.

// Key expires 60 seconds from now.
NAMESPACE.put("myKey", "myValue", {expirationTtl: 60})

// Key expires if the UNIX epoch is in the past.
NAMESPACE.put("myKey", "myValue", {expiration: 1247788800})

# You can also set keys to expire from the Cloudflare API.
curl "https://api.cloudflare.com/client/v4/accounts/ \
     $ACCOUNT_ID/storage/kv/namespaces/$NAMESPACE_ID/ \
     values/$KEY?expiration_ttl=$EXPIRATION_IN_SECONDS"
  -X PUT \
  -H "X-Auth-Key: $CLOUDFLARE_AUTH_KEY" \
  -H "X-Auth-Email: $CLOUDFLARE_AUTH_EMAIL" \
  -d "$VALUE"

Supongamos que desea bloquear a los usuarios que se marcaron como inapropiados en su sitio web, pero solo quiere hacerlo por una semana. Con una clave con vencimiento, puede configurar el tiempo de vencimiento y no tener que preocuparse por eliminar el bloqueo más adelante.

En este ejemplo, asumimos que los usuarios y las direcciones IP son lo mismo. Si su aplicación tiene autenticación, puede usar tokens de acceso como identificador de clave.

addEventListener("fetch", event => {
  var url = new URL(event.request.url)
  // An internal API that blocks a new user IP.
  // (eg. example.com/block/1.2.3.4)
  if (url.pathname.startsWith("/block")) {
    var ip = url.pathname.split("/").pop()
    event.respondWith(blockIp(ip))
  } else {
    // Other requests check if the IP is blocked.
   event.respondWith(handleRequest(event.request))
  }
})

async function blockIp(ip) {
  // Values are allowed to be empty in KV,
  // we don't need to store any extra information anyway.
  await BLOCKED.put(ip, "", {expirationTtl: 60*60*24*7})
  return new Response("ok")
}

async function handleRequest(request) {
  var ip = request.headers.get("CF-Connecting-IP")
  if (ip) {
    var blocked = await BLOCKED.get(ip)
    // If we detect an IP and its blocked, respond with a 403 error.
    if (blocked) {
      return new Response({status: 403, statusText: "You are blocked!"})
    }
  }
  // Otherwise, passthrough the original request.
  return fetch(request)
}

Aumentamos nuestro límite de tamaño en valores que van desde 64 kB a 2 MB. Resulta bastante útil si necesita almacenar datos basados en memoria temporal o archivos en Workers KV.

Observe este caso: usted desea permitir que los usuarios carguen su GIF favorito en su perfil sin tener que almacenar estos GIF como archivos binarios en la base de datos ni administrar otro cubo de almacenamiento en la nube.

Workers KV es la solución ideal para a este caso práctico. En Workers KV puede crear un espacio de nombres rápido y confiable para los GIF de los usuarios dondequiera que se encuentren sus clientes.

En este ejemplo, los usuarios cargan un vínculo a su GIF favorito, luego un Worker lo descarga y lo almacena en Workers KV.

addEventListener("fetch", event => {
  var url = event.request.url
  var arg = request.url.split("/").pop()
  // User sends a URI encoded link to the GIF they wish to upload.
  // (eg. example.com/api/upload_gif/<encoded-uri>)
  if (url.pathname.startsWith("/api/upload_gif")) {
    event.respondWith(uploadGif(arg))
    // Profile contains link to view the GIF.
    // (eg. example.com/api/view_gif/<username>)
  } else if (url.pathname.startsWith("/api/view_gif")) {
    event.respondWith(getGif(arg))
  }
})

async function uploadGif(url) {
  // Fetch the GIF from the Internet.
  var gif = await fetch(decodeURIComponent(url))
  var buffer = await gif.arrayBuffer()
  // Upload the GIF as a buffer to Workers KV.
  await GIFS.put(user.name, buffer)
  return gif
}

async function getGif(username) {
  var gif = await GIFS.get(username, "arrayBuffer")
  // If the user has set one, respond with the GIF.
  if (gif) {
    return new Response(gif, {headers: {"Content-Type": "image/gif"}})
  } else {
    return new Response({status: 404, statusText: "User has no GIF!"})
  }
}

Por último, queremos agradecer a todos nuestros clientes de la beta. Sus valiosos comentarios nos permitieron generar estos cambios en Workers KV. Manténgase en contacto con nosotros. Siempre estamos adelantándonos a lo que viene y nos encanta recibir noticias suyas.

Ya estamos listos para anunciar los precios de disponibilidad general. Si usted es uno de nuestros clientes empresariales, su precio obviamente permanece sin cambios.

• $0,50/GB de datos almacenados, 1 GB incluido

• $0,50/millones de lecturas, 10 millones incluidos

• $5/millones de operaciones de escritura, listas y eliminación, 1 millón incluido

Durante el período beta, supimos que los clientes no quieren simplemente leer valores en nuestros centros perimetrales, sino también escribir valores desde ellos. Como hay una alta demanda de estas operaciones perimetrales, que son más costosas, hemos comenzado a cobrar operaciones no leídas por mes.

Como dijimos antes, aumentamos nuestro límite de tamaño de valor de 64 kB a 2 MB. También eliminamos nuestro límite en el número de claves por espacio de nombres, que ahora es ilimitado. Estos son nuestros límites de disponibilidad general:

• Hasta 20 espacios de nombres por cuenta, cada uno con claves ilimitadas

• Claves de hasta 512 bytes y valores de hasta 2 MB

• Escrituras ilimitadas por segundo para diferentes claves

• Una escritura por segundo para la misma clave

• Lecturas ilimitadas por segundo por clave

Workers KV ya está abierta a todos los clientes, y puede empezar a usarla hoy mismo desde su panel de control de Cloudflare en la pestaña Workers. También puede consultar nuestra documentación actualizada.

¡Estamos ansiosos por descubrir todo lo que podrán crear los usuarios con Workers KV!