I'm trying to figure out how to download images in the MWPhotoBrowser when the image URLs require authentication. In my case the images are on S3 and I need to pass a key along with the url. I don't see a way to handle this in the browser.
Changed my approach and instead get a tokenized URL from S3 and then pass clean urls into the photo browser.
Related
I have an image saved in my Firebase Storage. I would like to display this image in multiple emails that I send. I have so far used the download URL as obtained from my Firebase console and the image displays successfully. My question is: Is this the correct way of sharing the image? Is it secure? If not, then how should I get a secure link to that image?
Here's where I got the download URL from, in the Firebase console:
Any help on this would be appreciated.
Using a download URL is the appropriate way to share files outside of an application, or to users who don't need to be logged in.
I'm curious what you mean by "is it secure"? If you're sharing the object with someone, they can forward the link to someone else who can download it, but they can also just download the object and share it as well.
If you want to control access based on a particular user, you'll need to have users log in and download the objects in an application, rather than using download URLs. Granted, again, here they can take the downloaded object and share it with anyone else.
I have integrated slack in my custom application using the API provided by Slack.
I am able to fetch the post from Slack and able to display it in my application. I am able to fetch the image that was uploaded with the post (Few days back) but today when I added a post with the image. The image is not being displayed in the application, when I am trying to access the image URL in the browser it is asking for Authentication.
I am accessing the slack rest API to fetch the post from slack. from the response I am taking the "thumb_64" parameter from the "file" object.
I am able to access the below image URL, this image was uploaded on 2016-01-11
https://files.slack.com/files-tmb/T0F8RH7U7-F0J505EG1-33434fadf3/screenshot_from_2015-12-28_15_23_39_160.png
But I am not able to access the below mentioned URL ,this image is uploaded on 2016-02-16
https://files.slack.com/files-tmb/T0F8RH7U7-F0MHZL70Q-d740ed784b/configration_160.png
Thanks & Regards,
Have you seen the update where #slackapi announced about accessing files using the Web API?
Essentially, you now need to provide authentication to access file assets, by specifying an HTTP Authorization header with an OAuth token that has the correct scopes to access that kind of data for a team.
For example, you'd send a header like this with your GET request:
GET https://files.slack.com/files-tmb/T0F8RH7U7-F0MHZL70Q-d740ed784b/configration_160.png
Authorization: Bearer YOUR_VALID_ACCESS_TOKEN_HERE
The File type documentation goes into further detail.
I am integrating dropbox in my app using OAuth 2.0 and now I want to upload a image using it's core api
https://api-content.dropbox.com/1/files//
my problem is there is no parameter shown for file upload (where i can send NSData)
DropBox documentation link :- https://www.dropbox.com/developers/core/docs ( /files (POST) )
I don't want to upload file/image using DBRestClient because it requires two time of login one via webView (OAuth 2.0) and another one via it's internal framework and my app require OAuth 2.0 integration.
Look closer. The documentation says:
Request body: "The file contents to be uploaded. Since the entire POST body will be treated as the file, any parameters must be passed as part of the request URL. The request URL should be signed just as you would sign any other OAuth request URL."
So you need to upload the actual contents through the message body (where the POST data would go).
However, the documentation also recommends to use /files_put instead.
I am working on an iOS app which allows downloading and HTTP live streaming of private videos. The videos are stored in an Amazon S3 bucket (as mp4 and segmented as m3u8/ts files). Also CloudFront is turned on and connected to the bucket.
Since the content is private, I need to sign the URLs when connecting via CloudFront. In order to sign the URLs it's necessary to use the private key and therefore it's not possible to generate signed URLs in the iOS app without storing the private key in the bundle. And that would be a bad idea!
So I decided to write a simple Ruby server, which performs the URL signing and redirects to the generated signed CloudFront URL as follows:
http://signing.server.local/videos/1.mp4 → https://acbdefg123456.cloudfront.net/videos/1.mp4??Expires=XXX&Signature=XXX&Key-Pair-Id=XXX
http://signing.server.local/videos/1.m3u8 → https://acbdefg123456.cloudfront.net/videos/1.m3u8??Expires=XXX&Signature=XXX&Key-Pair-Id=XXX
For video downloads it works well, since there is only one request. But when I want the content streamed and give the MPMoviePlayerController the URL of the signing server, only the first request is signed by the server and redirected to CloudFront. For the next requests the MPMoviePlayerController takes the first signed CloudFront URL as the base and tries to connect directly without going throw the signing server.
The paths in the m3u8 files are relative.
Any suggestions how to implement this feature without the need to send all the content through the signing server?
The correct way to do private HLS with S3/CloudFront or any other storage/CDN is to use HLS encryption. See the Apple documentation about this topic.
In addition to the storage where your playlists and segmented video files are stored you have to integrate a secure HTTPS server for storing the top level playlists and keys. These keys are generated during the segmenting using the Apple HLS tools.
Here is how it works:
The MPMoviePlayerController gets an URL pointing to the top level playlist (.m3u8) on the secure HTTPS sever.
In this file there are links to the variant playlists (prog_index.m3u8) which are stored in S3/CloudFront and which point to the video files (.ts).
Additionally the variant playlists contain a link to the keys which are necessary in order to read the video files. These keys are stored on the secure HTTPS server as well.
See the following image:
Taken from the presentation Mobile Movies with HTTP LIve Streaming (CocoaConf DC, Jun '12)
Of course there are possibilities to make the infrastructure more secure, see the linked Apple documentation.
I also created a Ruby script for segmenting to produce the output with given base URLs, which makes things a lot simpler.
Lukas Kubanek has the right answer. However, you can get the effect of signed URLs by putting the top-level playlists in a "private" bucket, and then putting all the other playlists and .ts files in a public bucket. This is pretty much as secure as using signed URLs for everything, in that anyone who wants to can still download and save the content, but can't merely share the URL they were given. They can of course open the top-level playlist and then share a single stream of their choice, or host the top-level playlist themselves, but it's at least a small level of security-by-obscurity that may be enough for your content. Also, if you sign every single segment, you run into a problem with content that's longer than your time limit, or with the user simply pausing the video until the segment links expire.
I think you need some way to avoid doing two requests to different servers for each chunk of video.
Possible solution: Could you change the Cloudfront private key every few minutes? If yes, then just authenticate however you want (bidirectional handshake) and send the app the current private key. If it expires, or if there are any errors due to it expiring at not exactly when expected, just re-authenticate and get new private key.
Possible solution: Talk to authentication server when you want to play video X, and get signed URLs for every part of that video, or even better: a m3u8 file containing signed URLs. Then, play those directly...
Possible solution: Run everything through a local proxy (on loopback interface on the iOS device). Then modify request URLs as needed, or make them redirects.
When I try clicking a pdf link on my website in Chrome and FF it does not do anything. I can right-click and save as but I cannot open it up within the browser. Both browsers have adobe reader enabled and works when I remove the AWS Key and signature.
https://s3.amazonaws.com/bucket/sample.pdf?AWSAccessKeyId=&Expires=&Signature= // Does not open
https://s3.amazonaws.com/bucket/mypdf.pdf // Opens fine
It works fine in both IE and Opera. Any way to bypass this?
The reason of your problem is really obvious, but could be difficult to resolve. When you open nonKey link
https://s3.amazonaws.com/bucket/mypdf.pdf
browser gets .pdf extension at the end of the link and tries to download it. But when you have additional request params your link is not ends with .pdf and that may cause the problem.
It looks like your uploaded pdf file got no metadata for content-type. If you don't have Figure out content types automatically checkbox checked during upload, try to set content-type manually by adding metadata
content-type: application/pdf
Other idea is to make browser think that the link is ending with .pdf, so try to download with this link:
https://s3.amazonaws.com/bucket/sample.pdf?AWSAccessKeyId=a&Expires=b&Signature=c&file=sample.pdf