search

FineUploader / fine-uploader

Multiple file upload plugin with image previews, drag and drop, progress bars. S3 and Azure support, image scaling, form support, chunking, resume, pause, and tons of other features.
https://fineuploader.com
MIT License
8.18k stars 1.87k forks source link

Option to set SAS for Azure uploads and skip signing endpoint #1602

Open birarda opened 8 years ago

birarda commented 8 years ago

Type of issue

feature

Uploader type

Azure

Feature request details

With the S3 version of FineUploader, it is possible to avoid signing requests from your server by using STS and setting those credentials on the FineUploader instance. I'd like to do something similar for Azure.

Could there be a way to a pass a container SAS to the uploader at the beginning of the session and have it use that for all operations in the Azure container directly?

rnicholus commented 8 years ago

The workflow you are suggesting would likely be a great deal of work to implement for Azure, as it was for S3. Certainly it would be more than just allowing a SAS to be passed in for all operations. Azure requires, to my knowledge, a newly generated SAS for each request, just as S3 needs a request-specific signature. So, Fine Uploader would have to generate this SAS for each request client-side based on a supplied storage account key (and I assume storage account name would be needed as well). But this sort of operation would be unwise client-side without the ability to generate short-lived heavily locked-down access keys. I personally don't use Azure, so I'm not sure if this type of system even exists.

Providing support for an entirely client-side signing workflow for S3 was challenging, and there is still more to do in terms of STS support for S3 (see #1406 and related cases for details). That said, I don't see anything like this making it onto my personal schedule for development anytime soon. But I would be willing to be available for anyone who is dependent on Azure and knowledgeable in that regard that is interesting in creating a pull request to add alternate signing workflow support to the Azure module.

birarda commented 8 years ago

Hey @rnicholus, thank you for the prompt reply. It is much appreciated. You've got a great library here and I hope you don't feel like I was suggesting this would be a trivial amount of work.

I believe it is possible to generate a single SAS that allows all blob operations on the container with read, write, create, list, and delete permissions. I've just tested that now and confirmed that I was able to put an empty block in my Azure container.

On our end, we're creating that SAS using a stored access policy and then revoking said policy once the user is no longer allowed to upload to their container.

I'm going to attempt to hack this in to a fork of FineUploader today by simply returning a set SAS where it would normally hit the middleman server to request a SAS for the blob.

rnicholus commented 8 years ago

I believe it is possible to generate a single SAS that allows all blob operations on the container with read, write, create, list, and delete permissions

How are you able to prevent the user from using this SAS to delete or list any/all files in the storage account?

Generally speaking, I think client-side signing is a bad idea, and something I would probably not consider for any of my applications. That said, if keys are properly provisioned and locked down, it can be reasonable secure, so I'll be interested to know how your method of client-side signing can be secured to prevent unintended operations on the account.

Also, please note that it is generally difficult to get a pull request merged into Fine Uploader, especially one that supports an entirely new workflow. Ultimately, this results in more work for me in terms of support and maintenance. This is even more so the case for Azure, since I don't use Azure in any of my projects. So, for changes to be even considered for merge, the changes:

  1. Must be potentially useful for a large portion of users
  2. Must contain a comprehensive set of unit tests.
  3. Must contain comprehensive documentation.
  4. Must not include any breaking changes.
  5. Must minimize impact on the API. If there are additions to the API/options/events, they should be minimal, consistent, and intuitive.
birarda commented 8 years ago

I set the stored access policy that the SAS uses only on the container I want my user to be able to enact operations on. This works for our purposes since we have a container associated with each user. This prevents the SAS for one container from having any permissions on other containers in the storage account.

I understand that this may not be seen as a general purpose improvement to Fine Uploader.

Once I get through my tests today, if it works as I need I'll reference my fork here so any with the same desires can see how I've made it work. Happy to then close the issue if this isn't a workflow you envision supporting.

rnicholus commented 8 years ago

Please do open a PR so we can discuss further. Worst case scenario: you have a fork with a second set of eyes on it in case there are any issues you overlooked that may affect your workflow. I do appreciate your time and effort discussing and coding this up, regardless of the outcome.

birarda commented 8 years ago

Put up #1604 to continue the discussion. It's lacking tests currently but hopefully that shows you how I'm using it so you can provide appropriate feedback.