CODEWITHSUNDEEP
azure
Reft
Reft

Reputation: 2433

Windows Azure - Shared Access Signature (SAS URI)

Heres three questions for you!

  1. Is it possible to revoke an active SAS URI without refreshing storage key or using Stored Access Policy?

In my application, all users share the same blob container. Because of this, using stored access policy, (max 5 per container), or refreshing storage key, (will result in ALL SAS URI'S being deleted), is not an option for me.

  1. Is it possible to show custom errors if the SAS URI is incorrect or expired?

This is the default page: enter image description here

  1. If I let users create their own SAS URI for uploading/downloading, do I need to think about setting restrictions? Can this be abused? Currently, in my application, there are restrictions on how much you are allowed to upload, but no restrictions on how many SAS URIS you are allowed to create. Users can aquire how many SAS URIS as they like as long as the don't complete their upload or exceed the allowed stored bytes. How does real filesharing websites deal with this? How much does a SAS URI cost to create?

Edit - Clarification of question 3.

Before you can upload or download a blob you must first get the SAS URI. I was wondering if it's "expensive" to create a SAS URI. Imagine a user exploiting this, creating a SAS URI over and over again without finishing the upload/download.

I was also wondering how real filesharing websites deal with this. It's easy to store information about how much storage the user is using and with that information put restrictions etc, but... If a user keeps uploading files to 99% and then cancel and restarts again and do the same thing, i imagine it would cost alot for the host

Upvotes: 0

Views: 279

Answers (1)

Gaurav Mantri
Gaurav Mantri

Reputation: 136306

To answer your questions:

  1. No, ad-hoc SAS tokens (i.e. tokens without Storage Access Policy) can't be revoked other than changing the storage key or access policy.
  2. No, at this time it is not possible to customize error message. Standard error returned by storage service will be shown.
  3. You need to provide more details regarding 3. As it stands, I don't think we have enough information to comment.

UPDATE

Regarding your question about how expensive creating a SAS URI is, one thing is that creating a SAS URI does not involve making a REST API call to storage service so there's no storage transaction involved. So from the storage side, there's no cost involved in creating a SAS URI. Assuming your service is a web application, only cost I could think of is user making call to your service to create a SAS URI.

Regarding your comment about how real file sharing websites deal with it, I think unless someone with a file sharing website answers it, it would be purely speculative.

(My Speculative response :)) If I were running a file sharing website, I would not worry too much about this kind of thing simply because folks don't have time to "mess around" with your site/application. It's not that the users would come to your website with an intention of "let's just upload files till the upload is 99%, cancel the upload and do that again" :). But again, it is purely a speculative response :).

Upvotes: 1

Related Questions