如何使浏览器使用不同的AWS S3预签名URL缓存相同的图像? [英] How to make browser cache identical image with different aws s3 presigned url?

查看:201
本文介绍了如何使浏览器使用不同的AWS S3预签名URL缓存相同的图像?的处理方法,对大家解决问题具有一定的参考价值,需要的朋友们下面随着小编来一起学习吧!

问题描述

我为用户生成了与此类似的网址,以便从我的aws s3存储桶中检索图像文件:

解决方案

我遇到了同样的问题,并通过缓存图像的presigned-url链接解决了这个问题,

当您从AWS请求一个预签名的URL时,它将返回一个带有expire&的链接.每次刷新时,签名都会指向存储桶中的源文件:服务器将向AWS传递请求,然后检索新的expire&浏览器一无所知的签名,因此它将再次获取相同的图像.

告诉浏览器保留状态的方法不必再次获取该方法,而是在刷新页面时发回相同的签名!听起来很简单,但可能会变得凌乱,所以请多包涵.

我所做的解决方案是使用"Redis" 缓存层,该层将浏览器加载的图像映射到序列.

如果userA加载了该页面,则只需检查同一用户和同一浏览器是否曾经访问过该页面即可.使用串行"的MacAddress应该添加到浏览器的本地存储中,

串行结构=(浏览器类型和名称+用户ID + MacAddress),这是为了确保userA同时从不同的设备和浏览器登录时可以正常工作,并确保每次用户A从此特定浏览器和设备加载页面/图像时,您都会创建相同的序列.

如果userA没有序列保存到本地存储,则将其添加到本地存储,然后检查序列是否存在于Redis (用户可能之前登录并清除了浏览器缓存) ,如果是,则删除附加的对象,该对象包含图像的预签名链接作为参数:

"serial" : 

{ 

         imageID_1 : "https://s3.bucket.xxx/imageID_1.jpg?.......xyz1",

         imageID_2 : "https://s3.bucket.xxx/imageID_2.jpg?.......xyz2",

         imageID_3 : "https://s3.bucket.xxx/imageID_3.jpg?.......xyz3"

 }

然后为必须在页面上加载的每个imageID/key请求新的预签名url,并将它们附加到Redis中的"serial"对象参数.如果否,则只需添加两个"serial"和对象参数:

"serial" : 

{ 

         imageID_1 : "https://s3.bucket.xxx/imageID_1.jpg?.......abc1",

         imageID_2 : "https://s3.bucket.xxx/imageID_2.jpg?.......abc2",

         imageID_3 : "https://s3.bucket.xxx/imageID_3.jpg?.......abc3"

 }

如果浏览器有一个序列缓存到本地存储中,则还必须与每个请求一起检查链接到该序列的对象参数中是否存在imageID 按顺序为其创建presigned-url(如果不存在),然后将其作为新参数添加到该对象中:

"serial" : 

{ 

         imageID_1 : "https://s3.bucket.xxx/imageID_1.jpg?.......abc1",

         imageID_2 : "https://s3.bucket.xxx/imageID_2.jpg?.......abc2",

         imageID_3 : "https://s3.bucket.xxx/imageID_3.jpg?.......abc3",

         imageID_4 : "https://s3.bucket.xxx/imageID_4.jpg?.......abc4",


 }

这是为了防止用户已经将序列号保存到浏览器的本地存储中,并告知之前有一些已加载的图像,因此我们必须检查userA是否在请求之前加载了相同的图像,或者他是否正在请求新的图像./p>

最后,您必须检查是否由于任何原因未加载图像或禁止从浏览器访问图像(用于检查并报告回服务器的字体结束代码),在这种情况下,您只需删除串行附加对象,然后附加新的带预签名的网址,然后将其发送回前端(浏览器).

I generated the url similar to this for my users to retrieve image files from my aws s3 bucket:

https://resource.my-company.com/tYERrR13341/q1/something.jpg?response-expires=Thu%2C%2008%20Nov%202018%2007%3A26%3A21%20GMT&AWSAccessKeyId=TTKIAJJBATJ89740989&Expires=1541661981&Signature=J49ebmKMdZ%2FZqwupfaD39f9e716831

Sometimes a user may refresh the page and the url to the same resource get a new set of values for Expires and Signature.

The browser will treat these two urls as different two objects, and will try to download the resource from the s3 bucket again.

It causes some performance issue. Is it possible to make a browser to be aware of the fact that, despite the difference in the parameters part of the url, the user is trying to retrieve the same resource and hence retrieve it from its local cache?

解决方案

I had the same issue and solved it with caching the images presigned-url links, this will solve the problem.

When you request a pre-signed url from AWS it returns a link with expire & signature which points to the source file in your bucket, each time you make a refresh: the server will pass a request to AWS and then retrieve a new expire & signature which the browser knows nothing about, so it will fetch the same image again.

The way to tell the browser hold on do not fetch that again, is to send back the same signature when you refresh the page! It sounds easy but it can get messy so bear with me.

The solution I made was using a "Redis" cache layer that maps the browser loaded images to a serial.

If userA loads the page you simply check if it has been visited before by the same user and the same browser & MacAddress using a "serial" you should add to the browser's local storage,

serial structure = (browser-type&name + userID + MacAddress), this is to make sure it works if userA login from different devices and browsers at the same time, and to make sure that you create the same serial each time userA loads the page/images from this specific browser and device.

If userA has no serial saved to local storage then add it to local the storage and go check if the serial exists in Redis (the user maybe logged-in before and cleared the browser-cache), if yes then remove the attached object which contains the presigned-links for your images as parameters:

"serial" : 

{ 

         imageID_1 : "https://s3.bucket.xxx/imageID_1.jpg?.......xyz1",

         imageID_2 : "https://s3.bucket.xxx/imageID_2.jpg?.......xyz2",

         imageID_3 : "https://s3.bucket.xxx/imageID_3.jpg?.......xyz3"

 }

Then request new pre-signed url for each imageID/key that has to be loaded on the page and attach them to the "serial" object parameters in Redis. If no, then just add both "serial" + object parameters:

"serial" : 

{ 

         imageID_1 : "https://s3.bucket.xxx/imageID_1.jpg?.......abc1",

         imageID_2 : "https://s3.bucket.xxx/imageID_2.jpg?.......abc2",

         imageID_3 : "https://s3.bucket.xxx/imageID_3.jpg?.......abc3"

 }

if the browser has a serial cached into local storage, you also have to check with each request if the imageID exists in the object parameters linked to the serial in-order to create presigned-url for it (if it does not exist) then add it as a new parameter to the object :

"serial" : 

{ 

         imageID_1 : "https://s3.bucket.xxx/imageID_1.jpg?.......abc1",

         imageID_2 : "https://s3.bucket.xxx/imageID_2.jpg?.......abc2",

         imageID_3 : "https://s3.bucket.xxx/imageID_3.jpg?.......abc3",

         imageID_4 : "https://s3.bucket.xxx/imageID_4.jpg?.......abc4",


 }

this is in case the user already has a serial saved into the browsers local storage, telling there is some loaded images before, so we have to check if userA is requesting the same images loaded before or he is requesting new ones.

finally you have to check if images are not loaded or forbidden to be accessed from the browser for any reason (font-end code to check and report back to the server), in this case you just remove the serial attached object and attach the new presigned-urls then send them back to the front-end (browser).

这篇关于如何使浏览器使用不同的AWS S3预签名URL缓存相同的图像?的文章就介绍到这了,希望我们推荐的答案对大家有所帮助,也希望大家多多支持IT屋!

查看全文
登录 关闭
扫码关注1秒登录
发送“验证码”获取 | 15天全站免登陆