📝 Use case: your app hosts files in Azure Blob Storage and users can generate expiring links to these files (using SAS tokens)
🤕 Problem: when a user opens a link with an expired SAS token, an unfriendly XML is displayed containing a technical error
😊 Solution: proxy the link with SAS token through an endpoint (Azure Function in my case), which will either redirect to the file (if the token is still valid) or show a descriptive error message
Recently the sex education app which we’ve created together with Kasia Koczułap, Marek Majchrzak and Radek Czemerys had a requirement to generate expiring links to files. As we store our files in Azure Blob Storage, using SAS tokens was an obvious choice — for each file requested, our backend generates a link with SAS token valid for 30 minutes:
It works great when the token is valid, but here’s what the user sees after opening an expired link
More technical users may figure out that the link expired. Others may think that the app is broken or the link got corrupted during copying.
Not only this page does not explain what happened — it also does not provide the next steps. Users may feel lost and in effect, they may leave a bad review or ask support for help, even though they could fix this situation by regenerating the link.
Fixing the flow
A better UX would be to show a clear & detailed error message in case the link expired. The way I approached this in our app was to proxy the original link with SAS token through a new HTTP Triggered Azure Function. This function checks whether the token is still valid and if yes, then simply redirects to the file. Otherwise, it returns a simple HTML page with a descriptive message.
The fact that I’ve used Azure Function does not mean you can not use the same logic in your WebAPI endpoints (or whatever else you’re using). For us Azure Function was an obvious choice, as we use them heavily in our project 🏋🏻♀️
How to detect link expiration?
You may have noticed that the link with SAS token has a few parameters:
sv=2019–02–02 is a version of the API which was used to generate this SAS token
sr=b means that the SAS token was created for a blob
sig is the signature of the token
sp=r means that the token is valid only for reading
… and:
**se=**2021–01–10T20:32:58Z, which specifies the moment when the SAS token expires. So in order to verify that the token is still valid, we just need to check whether the se parameter contains a date which is in the future — easy peasy! ✨
Code
Here’s a proof of concept of all of the stuff described above. If you’d like to run it or you’d need the list of nugets used, check out the full project here: https://github.com/miszu/expire-sas-token-handling
Let me know if you have any doubts or questions. If something above was useful to you, I’d be extremely grateful for any feedback you may have. Good luck with whatever you’re doing! 🙌🏻