Práctica recomendada para el almacenamiento en caché de datos confidenciales

3

Mi servidor devuelve datos privados en el cuerpo de una respuesta HTTPS. No son contraseñas ni tarjetas de crédito, sino que son imágenes y texto generados por el usuario, a los que otros no deben acceder.

Los datos de una URL en particular nunca cambian, y podrían almacenarse en caché todo el tiempo que quisiera. El beneficio de rendimiento del almacenamiento en caché es significativo.

Hay muchas directivas de Cache-Control: max-age, private, no-store, etc., pero no estoy seguro de cuál debo usar.

Configuro cookies de sesión (la duración está limitada a una única sesión del navegador). ¿Hay alguna manera de tener un "caché de sesión" que se comporte de manera similar?

¿Qué es la mejor práctica?

    
pregunta Paul Draper 29.04.2015 - 17:15
fuente

2 respuestas

4

Si la mayoría de su tráfico son datos personalizados, debe usar HTTPS y basarse principalmente en los cachés del navegador. Utilice este caché configurando el encabezado Expire y ETag.

Además, el Cache-Control: no-store recomienda a los navegadores no almacenar en caché los datos en un almacenamiento persistente, los datos solo se pueden almacenar en caché en la memoria RAM. En efecto, esto es como caché de sesión.

    
respondido por el Lie Ryan 29.04.2015 - 17:42
fuente
3

Deberías usar la directiva private . Tenga en cuenta que el contenido permanecerá disponible dentro del navegador del usuario, incluso si el encabezado Expires está configurado ya que este encabezado no necesariamente obliga al navegador a purgarlo después de la fecha y la hora establecidas, por lo que no cumple con el requisito de tiempo de espera de su sesión. Sin embargo, si este riesgo es aceptable, entonces puede ser adecuado.

Puedes asegurarte de que el encabezado Last-Modified esté configurado para que el navegador sepa si actualizar el contenido.

Cache-Control: private
  

Indica que la totalidad o parte del mensaje de respuesta está destinado a un solo usuario y NO DEBE ser almacenado en caché por un caché compartido, como un servidor proxy.

De RFC2616 sección 14.9.1

Tomado de esta publicación .

Tenga en cuenta que no-store no es adecuado si definitivamente quiere almacenar en caché en el navegador (en mí), también de RFC:

  

El propósito de la directiva de no almacenar es evitar que los inadvertidos   liberación o retención de información confidencial (por ejemplo, en copia de seguridad   cintas). La directiva de no almacenar se aplica a todo el mensaje, y PUEDE   ser enviado ya sea en una respuesta o en una solicitud. Si se envía en una solicitud, un   el caché NO DEBE almacenar ninguna parte de esta solicitud ni de ninguna respuesta   lo. Si se envía una respuesta, el caché NO DEBE almacenar ninguna parte de   ya sea esta respuesta o la petición que la provocó. Esta directiva   se aplica a cachés no compartidos y compartidos. "NO DEBE almacenar" en   este contexto significa que el caché NO DEBE almacenar intencionalmente el   información en el almacenamiento no volátil, y DEBE hacer un mejor esfuerzo   intente eliminar la información del almacenamiento volátil tan pronto como sea posible   posible después de reenviarlo.

Sin embargo, también dice

  

Los buffers de historia PUEDEN almacenar tales respuestas como parte de su rutina normal.   operación

por lo que navegar hacia el contenido aún será posible desde la memoria caché, suponiendo que aún no se haya eliminado con fines de administración de memoria.

También algunos navegadores todavía pueden solicitar el archivo completo nuevamente , que es otra razón por la que esto puede no ser adecuado:

  

tampoco enviamos una solicitud if-modified-since al validar   Contenido 'no-store' en el caché porque no se supone que tengamos un   copia de él desde un punto de vista HTTP.

    
respondido por el SilverlightFox 01.05.2015 - 13:17
fuente

Lea otras preguntas en las etiquetas