Got a problem, using GCS signed url feature (https://cloud.google.com/storage/docs/access-control/signed-urls) and want to force response content disposition.
I've used it once before in the past, but now I cannot seem to get it work and cannot find any documentation about Google deprecating this feature.
My current example url: https://storage.googleapis.com/examplebucket/examplefile.pdf?GoogleAccessId=account&Expires=expire&Signature=xx&response-content-disposition=inline
Signing is working and I can reach the file, just cannot force disposition.
If I upload file as Content-Disposition=attachment, then it wont make it inline and vice versa.
Any ideas?
For signed URLs, the contentDisposition metadata property, if specified, overrides the response-content-disposition query parameter. This is because the response-content-disposition query parameter is not part of the signature, which means that end users could change it.
If you want to specify response-content-disposition in the signed URL, clear the contentDisposition metadata property, and the value in the query parameter will be used.
Related
I have an application which is uploading objects to Google Cloud Storage using signed URLs and I'd like to know if it's possible to make the object public during the sign/upload step.
I know it's possible to make the object publicly visible by setting the policy on its bucket or by using the client library/making a REST request after it's been uploaded, but in order to minimize the impact on my workflow, I'd like to do it all in one go. Is this possible? If it can be done, I'm assuming it's by setting a header when signing the URL or when making the REST request using the signed URL but I haven't been able to find documentation which covers this.
UPDATE:
I've just found the Extension/Custom Headers section of the XML API docs which claims that this can be achieved using the x-goog-acl header (e.g. x-goog-acl: public-read). Unfortunately, this does not work. The object is not publicly visible after setting the header when signing the URL and when uploading the file.
Quoting the Cloud Storage documenation regarding Signed URLs:
When specifying the name:value pairs for headers, keep in mind the following:
Remove any whitespace around the colon that appears after the header name.
For example, using the custom header x-goog-acl: private without removing the space after the colon returns a 403 Forbidden error, because the request signature you calculate does not match the signature Google calculates.
So the solution could be setting the header value as x-goog-acl:public-read instead of x-goog-acl: public-read.
I have a .pdf object stored in Google Cloud Storage with Content-Type = application/octet-stream.
When giving temporary access through a signed URL, I extend the URL with:
&response-content-type=application%2Fpdf
Nevertheless, the response coming back from Google Cloud Storage still contains Content-Type = application/octet-stream
Inspecting the request + response through the browser confirms this behaviour.
According to the documentation (https://cloud.google.com/storage/docs/xml-api/reference-headers#responsecontenttype) the response-content-type should ensure Content-Type = application/pdf in my example.
For another usecase, I am succesfully making use of the Content-Disposition override via response-content-disposition, so I am very curious why the response-content-type is not working for me.
Anyone any idea what I am missing to make this work?
Thanks!
As per documentation signed URLs are not authenticated GET requests that support content-type override.
Query String Parameters like response-content-disposition and response-content-type are not verified by the signature. To force a Content-Disposition or Content-Type in the response, set those parameters in the object metadata using gsutil or the XML/JSON API.
I am trying to collect data from amazon web services. Every time I make the call I get back a 403 Forbidden.
This is what my code looks like (the link is jumbled):
Invoke-RestMethod -Uri "https://hosted-data-work.s3.amazonaws.com/20161121T220310.324/dw_split/73610000000000001/assignment_fact/part00101.gzAWSAccessKeyId=ASIAJVX3JXfd5dfdfRKJNGM74Q&Expires=1479839499&Signature=J4JdyX53AwH6wExVmoVAtkweCEI%3D&resp222onse-contentdisposition=inline%3B%20filename%3D%22assignment_fact-00000-095582fd.gz%22%3B&x-amz-security-token=bluh" -Method Get
The link above is a download file. I just want to get the data the simplest way possible. What else do I need to add in the call? I have no clue about aws!
How did you generate that URL? It looks like a presigned URL, which means the authorization for accessing the object will be granted based on the credentials used when presigning. There are a couple of possible reasons that could be giving you a not authorized response:
The credentials used to generate the presigned URL do not actually have permissions to read the object. Double check your IAM policies and/or ACLs for the bucket and the IAM user which generated the URL.
The signature got truncated/corrupted between the the time you generated the presigned URL and the time you tried to use it. Try logging the url when you generate it and again when you use it and compare to make sure they match exactly.
Presigned URLs expire after a specified validity period which cannot be longer than 1 week. Make sure you are generating a fresh URL when needed and setting the expiration appropriately.
Any of those could be causing the result you're seeing.
I was misinformed and took a bad approach at this problem. I did not know I can simply download the file to my computer. I though it had to be transferred from bucket to bucket, then to my computer.
I'm just getting started with Cloudinary, and I'm attempting to Uploading with a direct call to the API. Using the DHC REST Client (chrome extension), I put my request together per the instructions found here at Creating API authentication signatures. Here's a screenshot of that request and response.
I also tried...
adding quotes around all values except timestamp as shown in the example
making the request a multi-part request and attaching the image to the body as a "file"
deleting timestamp, api_key, and signature and instead replacing them with upload_preset to try and upload an unsigned image (yes, I created the preset)
And finally, I did try adding public_id even though it says it would assign one if not provided.
In all cases, I get the same error response... Missing required parameter - file
Can anyone tell me what I'm missing?
Ok, figured it out. These name/value pairs need to be added to the body of the request rather than the header. Here's what that would look like in the DHC client. Note that the upload_preset will not work for you... I only created it to test with. Also note that doing a signed request is accomplished the same way but with different parameters.
Imagine I am creating an API to allow a user to attach an image to their profile, where the image may come from a binary submission in the body, or a url, which the server will retrieve and process.
Assuming the API expects a PUT with binary image data to
/user/jon/image
When adding the URl functionality, which of the following would be preferable?
A:
PUT to /user/jon/image/url
passing the url in the body
or
B:
PUT /user/jon/image/
passing in a url in the body and setting a MIME type to advise the host whether or not the content is an image or an URL?
Is there a standard way of dealing with this situation? I feel that using MIME types to dictate the payload is more semantically correct, but a little less discoverable
Thanks
Once I had this same problem. I solved it by first posting the image by "PUT /user/jon/image/" and then posting the URL with PUT to /user/jon/image/url.
The problem is, that the user posts an image and forgets about the URL. I solved this by saving the image temporally in a session and when the URL is posted, I saved the URL and the image at the same time.
Problem is, this is not Restful, because a restful server doesn't have sesions. But being 100% restful is almost imposible, so its your choice.