How does signed URLs work for streamed videos in Amazon CloudFront?
I'm using aws_cf_signer gem, but can't get signed urls work for rtmp streamed mp4-file. For static files, like text.txt it works fine, but not when I have streaming distribution.
Example:
I have file named test.mp4 so how do I get signed url out of signer.sign()?
E.g. signed_url = signer.sign('rtmp://xyz.cloudfront.net/test', :ending => Time.now + 3600) does not produce working url. I have tested URLs with VLC player and rtmpdump
The distribution itself is created with boto like this:
stream_dist = cf.create_streaming_distribution(origin=origin,
enabled=True,
trusted_signers=["Self"],
comment="test distribution")
According to the AWS: Restricting End User Access doc, the format for signed RTMP urls is different from HTTP:
With HTTP, a full URL uniquely describes an object. You can include the URL
in the signature. The content of a streaming distribution, however, cannot always
be described by a valid URL. In a streaming distribution, you only use the stream
name to create a signature. For example, if your stream including the signature is:
example/mp3_name.mp3?Expires=1258237200&Signature=TBD&Key-Pair-Id=PK12345EXAMPLE
The value for RESOURCE is:
example/mp3_name
For streaming distributions, you do not include a prefix, such as mp3: or mp4:,
for the resource name in the policy.
Also, when referencing an MPEG file, you might have to omit the file extension for
the URL enclosed in the signature. For example, you use mp3_name instead of mp3_name.mp3.
I'm not sure whether aws_cf_signer gem supports signing RTMP urls, unfortunately. If you find out, please let me know!
Related
We are using FFMPEG to stream a Google Drive URL into a node application.
Is there an FFMPEG method or library we can use to stream to FFMPEG using the Google Drive API instead of using the standard public shared URL?
At the moment using the URL works fine if the file size is <100mb but with bigger files we get an error:
https://drive.google.com/uc?export=download&id=fileId: Invalid data found when processing input
This is because we reach the pesky gDrive virus roadblock page:
From your question, I understood that your file is publicly shared. In this case, when the file size becomes large, the endpoint of https://drive.google.com/uc?export=download&id=fileId is required to be processed with 2 steps. Ref This has already been also mentioned in your question.
In this answer, in order to avoid this, I would like to propose to use the method of "Files: get" in Drive API and the API key. When Drive API and API key is used for the publicly shared file, no 2 step flow is required, and it can use it by changing only the URL.
Endpoint:
https://www.googleapis.com/drive/v3/files/{fileId}?alt=media&key={your API key}
For example, as a test, when you use curl command, you can use curl "https://www.googleapis.com/drive/v3/files/{fileId}?alt=media&key={your API key}".
References:
Download a file stored on Google Drive
Files: get
Using API keys
Our application is entirely built on websockets. We don't do any HTTP request-reply. However, we are stuck with file download. If i receive file content via websockets can I wrote to local folder on user computer ?
If it makes a difference, we are only supporting Chrome so not issue if it doesn't work on other browsers.
Also, I know i can do this via HTTP. Trying to avoid it and stick to websockets since thats how the entire app is.
Thanks a lot in advance!
The solution depends on size of your file.
If size is less than about 50 MB, I would encode file's content to base64 string on the server and send this string to the client. Client should receive parts of the string, concat them to single result, and store. After receiving whole string, add link (tag <a>) to your page with attribute href set to "data:<data_type>;base64,<base64_encoded_file_content>". <data_type> is a mime type of your file, for example "text/html" or "image/png". Suggest file name by adding download attribute set to name of file (doesn't work for Chrome on OS X).
Unfortunately I have no solution for large files. Currently there is only FileEntry API that allows to write files with JS, but according to documentation it is supported only by Chrome v13+, learn more here https://developer.mozilla.org/en-US/docs/Web/API/FileEntry.
So I'm pretty new at all this. I am trying to reverse engineer a web application.
When I submit a form, it sends a POST with a request payload that looks something similar to this:
encoding=UTF8&zip=1&size=136240&html=DwQgIg_a_whole_lot_more_gibberish_not_worth_posting
Anyways, from inspecting the captured traffic from Chrome developer tools, I noticed it is encoded and sent as a zipped up html?
How would I go about reversing this to see what the content is actually being sent to the server?
What you want to do is this:
1) Get the name of the zip file
2) Get the path of the zip file (likely the root directory or the current path the form is at)
3) Generate the URL (http://site_name.com/path/to/folder/zip_file.zip)
4) Download it using a too such as wget (typing the URL into the browser may work too)
I used this technique to download all the files that get downloaded to the OTA updates on iOS devices (used burp suit to intercept the zip file name where the server was on my computer which my iDevice was connected to).
Please note: the name of the zip file you have given does not end in .zip. this may mean it doesn't have a extension; you may have to add .zip to the file manually; or it may have another ending such as .tar, .tar.gz etc.
I'm trying a small app which play a asx streaming file. My understanding was i should parse the asx and get the URL. But in my case, REFHREF in ASX points like this www.website.com:8084. Is this the server configuration need to be modified ? Totally new to this audio streaming protocols. Any suggestion would be much appreacited ...
My code streams audio fine when i test with a ww.website.com/file.MP3
the URL from refhref may most probably lead you to another asx file, which needs to be parsed again, i would advice recursively parsing till u reach a valid playable stream! Wp7 supports asx streams but it disallows(throws an exception for some tags check here )
so you will have to parse the asx yourself, extract the URL and process it further!
Good Luck! post your findings too!
I would like to access an mms:// url, and stream the file in ruby. For example,
in the same way that Net:HTTP works for http:// type urls.
The simpliest (but non-scalable) way is to ask MPlayer to -dumpstream it for you.
http://mplayerhq.hu/