Cloudfront - multipart upload with signed url - amazon-cloudfront

Is there a way or document for multipart upload to cloudfront using signed urls?

Related

Accessing files from AWS S3 Bucket

I am using NodeJS to upload a file into my S3 bucket. As a response I receive a link to the file.
For example I receive https://my-bucket-name.s3.ap-south-1.amazonaws.com/testUpload_s.txt
The bucket does not allow public access as of now. How am I supposed to securely access the file from the bucket? I would like to know whether the the following method be safe?
Allow public access for bucket
Each file will be given a random unique name during upload
This file name or the response URL is stored in the database
When the file has to be fetched I use the link received from the
upload response to access the file from the bucket
Is this approach safe? If not is there any other method to do the same?
There are a number of options for giving clients access to an object in S3, including:
make the object public
require the client to authenticate with AWS credentials
give the client a time-limited, pre-signed URL
They each serve a different use case. Use #1 if it's safe for anyone to access the file (for example the file is an image being shown on a public web site). Use #2 if the client has AWS credentials. Use #3 if you don't want to make the file public but the client does not have AWS credentials. Note with #3 that the pre-signed URL is time-limited.
You don't need to store URL. You can query objects in S3 bucket using file name.
For access from outside Use signed url.
https://docs.aws.amazon.com/sdk-for-go/v1/developer-guide/s3-example-presigned-urls.html

How to use file upload with Kuzzle

I use Kuzzle as a backend for my progressive web app and I wanted to do some file upload.
As far I can see, Kuzzle does not support server side file storage.
How can I upload images from my application and then display them to other users?
EDIT (2019-05-20): Since this is a very current feature in mobile or web application, we have developed a Kuzzle Plugin that allows to upload file to S3 using Presigned Urls: https://github.com/kuzzleio/kuzzle-plugin-s3
Check out the README: https://github.com/kuzzleio/kuzzle-plugin-s3#example-using-the-javascript-sdk
ORIGINAL RESPONSE:
Kuzzle does not natively handle file upload.
The best way to handle file upload is to use an external service like Amazon S3 or Cloudinary to upload your file in the client side and then store the file URL and metadata into Kuzzle.
You can develop a Kuzzle plugin to generate S3 presigned upload URLs with a tiny TTL and then use this URL to upload you file directly to your S3 bucket.
This way you can use Kuzzle authentification and rights management system with your file upload.
Here you have some resources about presigned URL: https://medium.com/#aakashbanerjee/upload-files-to-amazon-s3-from-the-browser-using-pre-signed-urls-4602a9a90eb5
And you will need to develop a Kuzzle plugin with a custom controller to generate these URLs: https://docs.kuzzle.io/plugins/1/controllers
Full disclosure: I work at Kuzzle as core developer

IIS resource request filtering ASP.NET Web API

I am building a ASP.Net Web API as back-end and AngularJS as front-end website, and hosting it on IIS 10. User are allowed to upload files to Uploads folder, but User can only download certain files with Authorization header on HTTP GET from Uploads folder, and I request filtering denied access to Uploads directory so that user can't simply HTTP GET any resources from Uploads folder bypass authorization. The question is what if I want to show certain images from Uploads folder on my website, on html? I could not HTTP GET any resources from Uploads folder. Am I doing something wrong? Is there a way to get around this?

How to use Cloudfront to protect my files

I have a bunch of images on my S3 which is linked with Cloudfront.
Now I have a web server and I only want users to view the image through my website so I can't just give out links to the image. How do I set that?
It appears that your requirement is:
Content stored in Amazon S3
Content served via Amazon CloudFront
Content should be private, but have a way to let specific people view it
This can be accomplished by using Pre-Signed URLs. These are special URLs that only work for a limited period of time.
When your application determines that the user is entitled to view an image, it can generate a Pre-Signed URL that grants access for a limited period of time. Simply use this URL in an <IMG> tag as you would normally.
See:
Amazon S3 pre-signed URLs
Amazon CloudFront pre-signed URLs
Since your content in Amazon S3 will be private (so users cannot bypass CloudFront and access it directly), you will also need to grant CloudFront permission to access the content from S3. See: Using an Origin Access Identity to Restrict Access to Your Amazon S3 Content
Another option, instead of creating a pre-signed URL each time, is to use Signed Cookies. However, this doesn't give fine-grained control for access to individual objects -- it's more for granting access to multiple objects, such as a subscription area.

"303 See other" in HTTP HEAD response

I am building an ASP.NET Azure Web Application (Web Role) which controls access to files stored in Azure Blob Storage.
On a GET request, my HttpHandler authenticates the user and creates a Shared Access Signature for this specific file and user with a short time frame (say 30 mins). The client is a media player which checks for updated media files using HEAD, and if the Last-modified header differs, it will make a GET request. Therefore I do not want to create a SAS url but rather return LAst-modified, Etag and Content-length headers in response to the HEAD request. Is this bad practice? In case the file is up to date, there is no need to download the file again and thus no need to create a SAS url.
Example request:
GET /testblob.zip
Host: myblobapp.azurewebsites.net
Authorization: Zm9v:YmFy
Response:
HTTP/1.1 303 See other
Location: https://myblobstorage.blob.core.windows.net/blobcontainer/testblob.zip?SHARED_ACCESS_SIGNATURE_DATA
Any thoughts?
Is there a specific reason to force the client to make a HEAD request first? It can instead authenticate using your service, get a SAS token, make a GET request using If-Modified-Since header against Azure Storage, and download the blob only if it was modified since the last download. Please see Specifying Conditional Headers for Blob Service Operations for more information on conditional headers that Azure Storage Blob service supports.

Resources