Empresas
Empregos
  • Sobre nós
  • Soluções
    • Publicação de vagas
      Publique sua vaga e receba candidatos qualificados em 48h.
    • Avaliações de candidatos
      Mais de 500 testes técnicos e psicológicos, mais anti-fraude.
    • Headhunting
      Busca executiva personalizada do início ao fim.
    • Folha de Pagamento + EOR
      Dispersão de folha e EOR em mais de 15 países da LATAM.
  • Preços
  • Empregos

0

156
Visualizações
Problema de representación del lado del servidor sobre un CDN

Recientemente lancé un sitio que utiliza la representación del lado del servidor (con next.js). El sitio tiene una funcionalidad de inicio de sesión en la que, si una cookie de autenticación está presente desde la solicitud de un usuario, generará una vista de inicio de sesión para ese usuario en el servidor y devolverá la vista de inicio de sesión al navegador de los usuarios. Si el usuario no tiene una cookie de autenticación presente, muestra una vista de sesión cerrada en el servidor y la devuelve al navegador de los usuarios.

Actualmente funciona muy bien, pero me encontré con un problema al intentar servir el sitio a través de un CDN. Mi problema es que el CDN almacenará en caché la respuesta de un servidor para acelerarlo, por lo que lo que sucederá es que el primer usuario que ingrese al sitio web en el CDN tendrá su vista de inicio de sesión almacenada en caché y devuelta al navegador. Esto, a su vez, significa que debido a que se almacena en caché, otros usuarios que visitan el sitio también ven a los otros usuarios que iniciaron sesión en lugar de ver los suyos propios, ya que eso es lo que ha almacenado en caché la CDN. No es ideal.

Estoy tratando de pensar cuál sería la mejor manera de resolver este problema. ¿Me encantaría escuchar alguna sugerencia sobre las mejores prácticas para evitar esto?

Una forma en la que he pensado sería potencialmente devolver siempre una solicitud de vista de cierre de sesión en la primera visita a la página y, por lo tanto, la autenticación / inicio de sesión en el lado del cliente y, a partir de ese momento, siempre realizar la autenticación en el servidor. Sin embargo, este método solo funcionaría si next.js solo hace la representación del lado del servidor en la primera solicitud y las solicitudes posteriores hacen toda la representación en el cliente y no estoy seguro de si ese es el caso.

¡Gracias y me encantaría toda la ayuda / sugerencias que pudiera obtener!

ACTUALIZAR

Por lo que puedo deducir hasta ahora de las respuestas, parece que la mejor manera de solucionar esto será ofrecer una vista de sesión desconectada en caché de CDN a cada usuario cuando visite el sitio por primera vez. Luego puedo iniciar sesión manualmente desde la interfaz si hay un token de autenticación presente en sus cookies. Todas las páginas después de la primera página en la que aterrizan tendrán que devolver una vista de inicio de sesión. ¿Es esto posible con Next.js? ¿Sería esta una buena manera de hacerlo? Aquí hay un resumen de estos pasos:

  1. El usuario aterriza en cualquier página web
  2. Se realiza una solicitud al servidor para esa página junto con las cookies de los usuarios.
  3. Debido a que esta es la primera página que visitan, las cookies se ignoran y se devuelve una vista de "cierre de sesión" al navegador de los usuarios (que se habrá almacenado en caché en la CDN)
  4. La interfaz luego carga una vista de sesión cerrada. Una vez cargado, busca un token de autenticación y hace una llamada a la API para iniciar sesión si hay uno presente.
  5. Cualquier otra página de navegación después de eso se devuelve desde el servidor como una vista de "inicio de sesión" (es decir, la cookie de autenticación no se ignora esta vez). Esto evita tener que hacer el paso 4 nuevamente, lo que sería molesto para el usuario en cada página.
over 4 years ago · Santiago Trujillo
4 Respostas
Responde à pergunta

0

Lo que entiendo de su pregunta es que cuando un usuario inicia sesión, la vista de inicio de sesión se almacena en caché en la CDN y cuando el usuario cierra la sesión, el sitio también se muestra en la vista de inicio de sesión desde la caché de CDN.

Hay algunas soluciones a este problema son las siguientes:

  1. Establezca algo de TTL (Tiempo de vida) para la CDN para que invalide automáticamente los datos de caché después de un tiempo específico.
  2. Como desea entregar el sitio rápidamente, significa que desea lograr una latencia baja. Para esto, puede hacer una cosa, simplemente almacenar en caché los archivos grandes del sitio web, como imágenes, videos, documentos, etc., en la CDN. Y no almacene en caché todo el sitio web allí. Ahora, cada vez que llegue la solicitud del usuario, el sitio se servirá desde el servidor normal y los archivos multimedia se tomarán de la CDN. De esta manera, puede lograr una baja latencia. Y como los archivos multimedia se toman de la caché de CDN, el código del sitio web se cargará rápidamente y el sitio se atenderá rápidamente. De esta forma, la autenticación se realizará del lado del servidor.
  3. Otra solución sería invalidar la cookie y la autenticación después de un cierto tiempo de inactividad. Y después de eso, cuando llega un usuario, el sitio debería mostrar una vista de sesión cerrada.
over 4 years ago · Santiago Trujillo Relatório

0

Intente agregar un encabezado de control de caché a sus páginas requeridas de autenticación.

Control de caché: Privado

La directiva de respuesta privada indica que un recurso es específico del usuario; aún se puede almacenar en caché, pero solo en un dispositivo cliente. Por ejemplo, un navegador de escritorio puede almacenar en caché una respuesta de página web marcada como privada, pero no una red de entrega de contenido (CDN).

over 4 years ago · Santiago Trujillo Relatório

0

Para los proxies de almacenamiento en caché que funcionan bien (que debería ser su CDN), hay dos encabezados de respuesta que debe usar:

Control de caché: privado

Establecer este encabezado de respuesta significa que los proxies intermediarios no pueden almacenar en caché la respuesta. (El navegador aún puede almacenarlo en caché, si es apropiado hacerlo. Si desea evitar el almacenamiento en caché, en su lugar, usaría no-store ).

Ver también: https://developer.mozilla.org/en-US/docs/Web/HTTP/Headers/Cache-Control

Variar: Galleta

Este encabezado de respuesta indica que los datos de la respuesta dependen del encabezado de solicitud de Cookie . Es decir, si mi solicitud tiene el encabezado Cookie: asdf y su solicitud tiene el encabezado Cookie: zxcv , entonces las solicitudes se consideran diferentes y se almacenarán en caché de forma independiente. Tenga en cuenta que el uso de este encabezado de respuesta puede afectar drásticamente su almacenamiento en caché si se usan cookies para cualquier cosa en su dominio... y apuesto a que lo son.

Consulte también: https://developer.mozilla.org/en-US/docs/Web/HTTP/Headers/Vary

Una alternativa...

Un enfoque alternativo común en estos días es manejar todos los usuarios que enfrentan datos dinámicos del lado del cliente. De esa manera, puede realizar una solicitud a algún servidor API que no tenga CDN de almacenamiento en caché. Luego, la página se llena del lado del cliente con los datos necesarios. Las partes estáticas del sitio se sirven directamente desde la CDN.

over 4 years ago · Santiago Trujillo Relatório

0

Todos los datos de caché y distribución de CDN se basan en el cache header en la respuesta HTTP. Debe considerar estas dos notas simples para obtener el mejor rendimiento sin perder el poder de CDN.

1. Cabecera sin caché para contenido dinámico (respuesta HTML, API,...):

  • Debe asegurarse de que la respuesta del encabezado de caché de todos los contenidos dinámicos (respuesta HTML, API,...) sea Cache-Control: no-cache .
  • Si está usando next.js, puede usar un servidor personalizado (express.js) para servir su aplicación y control total sobre el encabezado de respuesta o puede cambiar la configuración de next.js.

2. Establezca el encabezado de caché para contenido estático (js, CSS, imágenes, ...)

  • Debe asegurarse de que la respuesta del encabezado de caché de todos los contenidos estáticos (js, CSS, imágenes, ...) sea Cache-Control: max-age=31536000 .
  • Si está utilizando next.js en cada compilación, todos los activos tienen un nombre único y puede configurar un caché a largo plazo para los activos estáticos.
over 4 years ago · Santiago Trujillo Relatório
Responde à pergunta
Encontrar trabalhos remotos

Descubra a nova forma de encontrar um emprego!

melhores empregos
Principais categorias de trabalho
Empresas
Postar vaga Preços Comercial
Jurídico
Termos e Condições Política de privacidade
© 2026 PeakU Inc. All Rights Reserved.
Andres GPT
Recomende algumas ofertas para mim
Preciso de ajuda