Blob file is accessible from Cache without SAS token [using Azure Front Door and CDN Profile]

Hello @GitaraniSharma-MSFT ,
Thank you for your valuable response. Could you please check whether my following understandings are correct for the given options?

Option 1
I don't want to allow access to the file from the cache without SAS token, not even until the cache expiry time. So I cannot choose it.

**Option 2
'**Cache every unique URL' will not hit the cache because when URL is generated each time SAS token would be different. So I have to drop this too.

The problem at the Application level
Whenever the file in Blob storage is modified read the file from Blob storage and cache it and then for every successive request read it from the cache.

Is it possible, If so what settings should I follow?

Please let me know If additional information is required. Thanks !!

Hello @Sachin K ,

I don't want to allow access to the file from the cache without SAS token, not even until the cache expiry time.

If you don't want to allow access to the file from the cache without SAS token, then the better option would be to disable caching altogether.

Azure CDN/AFD won't validate the Access Token. It will be validated only if you directly access the storage account.

Cache every unique URL will not hit the cache because when URL is generated each time SAS token would be different.

This should not be the case with SAS token. Azure CDN treats the SAS token as a plain query string.

With Azure Content Delivery Network (CDN), you can control how files are cached for a web request that contains a query string. In a web request with a query string, the query string is that portion of the request that occurs after a question mark (?). A query string can contain one or more key-value pairs, in which the field name and its value are separated by an equals sign (=). Each key-value pair is separated by an ampersand (&). For example, http://www.contoso.com/content.mov?field1=value1&field2=value2. If there's more than one key-value pair in a query string of a request, their order doesn't matter.

Cache every unique URL: In this mode, each request with a unique URL, including the query string, is treated as a unique asset with its own cache. For example, the response from the origin server for a request for example.ashx?q=test1 is cached at the POP node and returned for subsequent caches with the same query string. A request for example.ashx?q=test2 is cached as a separate asset with its own time-to-live setting.

This mode is only recommended to NOT use in case when the query string contains parameters that will change with every request, such as a session ID or a username, because it will result in a low cache-hit ratio.

Refer: https://video2.skills-academy.com/en-us/azure/cdn/cdn-how-caching-works#introduction-to-caching

https://video2.skills-academy.com/en-us/azure/cdn/cdn-query-string

So, when a user with the SAS token requests the file access, the response from the origin server will be cached at the POP node and will be returned for subsequent caches with the same query string. When the query string changes, a new request is sent to the origin server again and then cached.

Could you please clarify what do you mean by "when URL is generated each time SAS token would be different"?

Also, your ask seems to contradict with your problem:

Problem: After caching the file, If I call the same URL without SAS token the file is accessible. Question: How can I restrict the access of files from the cache without using the SAS token?

Since your existing query string mode says: Ignore query strings, the CDN point-of-presence (POP) node passes the query strings from the requestor to the origin server on the first request and caches the asset. All subsequent requests for the asset that are served from the POP ignore the query strings until the cached asset expires.

So, this is an expected behavior in this default mode.

If you don't want to access the files without SAS tokens, then you should not use caching at all.

Or you could try to use the below query string mode in your rule:

Bypass caching for query strings: In this mode, requests with query strings aren't cached at the CDN POP node. The POP node retrieves the asset directly from the origin server and passes it to the requestor with each request.

Kindly let us know if the above helps or you need further assistance on this issue.

Regards,

Gita Sharma

Hello @GitaraniSharma-MSFT ,

Thanks for the help. I understood the information provided.
Could you please provide a solution to the problem mentioned below? What settings or configurations I should set?

Whenever the file in Blob storage is modified read the file from Blob storage and cache it and then for every successive request read it from the cache.

Hello @Sachin K ,

A cached resource isn't compared to the version on the origin server every time it's accessed. Instead, as long as a cached resource is considered to be fresh, it's assumed to be the most current version and is sent directly to the client. A cached resource is considered to be fresh when its age is less than the age or period defined by a cache setting.

You can control how caching is performed in a CDN by sending cache-directive headers. Cache-directive headers are HTTP headers, which are typically added by the origin server.

Two headers can be used to define cache freshness: Cache-Control and Expires. Cache-Control is more current and takes precedence over Expires, if both exist. There are also two types of headers used for validation (called validators): ETag and Last-Modified. ETag is more current and takes precedence over Last-Modified, if both are defined.

When the cache is stale, HTTP cache validators are used to compare the cached version of a file with the version on the origin server. Azure CDN Standard/Premium from Edgio supports both ETag and Last-Modified validators by default, while Azure CDN Standard from Microsoft supports only Last-Modified by default.

A cache validates a file using Last-Modified by sending an If-Modified-Since header with a date and time in the request. The origin server compares that date with the Last-Modified header of the latest resource. If the resource hasn't been modified since the specified time, the server returns status code 304 (Not Modified) in its response. If the resource has been modified, the server returns status code 200 (OK) and the updated resource.

Refer: https://video2.skills-academy.com/en-us/azure/cdn/cdn-how-caching-works#resource-freshness

Azure storage blob supports Last-Modified HTTP header.

Last-Modified: The date/time when the blob was last modified. The date format follows RFC 1123. Any write operation on the blob (including updates on the blob's metadata or properties) changes the last modified time of the blob.

https://video2.skills-academy.com/en-us/rest/api/storageservices/put-blob?tabs=microsoft-entra-id#response-headers

https://video2.skills-academy.com/en-us/rest/api/storageservices/set-blob-properties?tabs=microsoft-entra-id#response-headers

So, in your configured global and custom caching rules, you should specify the following Caching behavior setting:

• Set if missing: It honors origin-provided cache-directive headers, if they exist; otherwise, use the provided cache duration.

For the Override and Set if missing Caching behavior settings, valid cache durations range between 0 seconds and 366 days. For a value of 0 seconds, the CDN caches the content, but must revalidate each request with the origin server.

Refer: https://video2.skills-academy.com/en-us/azure/cdn/cdn-caching-rules#caching-behavior-settings

So, you may set a Global rule to configure cache duration as below:

And configure your caching rule to set the query string caching behavior as below:

The above settings will make sure the below:

It will honor origin-provided cache-directive headers, if they exist; otherwise, the CDN will cache the content, but will revalidate each request with the origin server. If the file has been modified on the origin server, the cache updates its version of the resource.

And requests with query strings will not be cached at the CDN POP node. The POP node will retrieve the asset directly from the origin server and pass it to the requestor with each request.

Kindly let us know if the above helps or you need further assistance on this issue.

Regards,

Gita