I am creating a google-chrome application that will download songs from an octet stream, however due to JavaScript restrictions, I cannot create a "download" button. The user must right click and select save file as. I wish to create a php page that will redirect the browser to the location of the octet stream, which will be on a different site, and then create a download dialog there. I know there are probably security restrictions here, but is it possible to have a php page redirect and set the content disposition headers of that page it is redirecting to?
Note: I cannot get the octet stream from my server to save because the host I am using does not support php calls to external sites.
The download dialog (content-disposition header) has to be produced by the other site. There's no way around it, because browsers will only believe headers from the same server. If the other site doesn't produce the desired headers, and if you don't own the other site, there's nothing you can do about it.
You might write a PHP script which accesses the other site on behalf of the user, downloads the octet stream to the server first, and then sends it to the user with the desired headers. In other words, your script would act as a proxy server. Look into the curl module if interested. But this will cause your server's bandwidth to skyrocket, and there may also be problems with copyright.
Related
ftp_get() downloads a file from an FTP server and saves the file to local server.
So when I want to download a file from an FTP server to my browser, the file will first be downloaded to the local server and then downloaded to the browser.
This causes double bandwidth. Is there a way to download a file from an FTP to browser directly?
ftp_get() or curl or any PHP script will require opening a stream to the source, and passing it the client browser. You still use 2 streams, resulting in double the bandwidth usage. The only way to avoid this is to link to or have the end-user collect the file directly.
I am assuming that you're collecting the file from a private FTP location, passing the credentials, and you do not want the end-user to have these or they do not know them. Yet for them, it should be a seamless download.
Not a lot of good ways to do this. In my mind, making an FTP Client connection via Flash in the end-users browser is one way. You could dynamically create flash or have the flash collect the credentials (encrypted), and then perform the connection to the FTP Server from the end-users browser (after decrypting the credentials) and download the file directly to the end-user.
All you can do is to redirect the client browser to the ftp:// URL. That's doable when the FTP site allows an anonymous read access. Most (all) web browsers support FTP natively.
Depending on a workflow, you either redirect from the PHP code:
header("Location: ftp://download.example.com/file.pdf");
On you directly use ftp:// URL in the HTML code:
Download
If anonymous read access is not allowed, you'd have to include the credentials in the URL, what you probably do not want to.
ftp://username:password#download.example.com/file.pdf
well currently I have a script which gathers mp3s. All the songs are hosted on external sites.
A user clicking the mp3 link will result in the mp3 playing in the browser in the users default audio player (quicktime etc)
I'm just wondering what code I could use (PHP) to have the mp3 open as a download prompt instead of playing. This would be easy although the catch is that it can't be processed through the server (aka can't use bandwidth)
can it be done?
Thanks
At first glance this appeared to be a duplicate of How to implement Content-Disposition: attachment?.
Then I saw the "3rd party sites" proviso.
There is no way to override the HTTP headers sent by a remote site when sending the client there. What you want is not achievable.
I'm building a web-radio like service, in which the user authenticates to the services, gets a cookie and a Flash-based app plays mp3s from the server. The server only delivers if the client is allowed for that particular mp3.
If a user opens a HTTP logger (like FireBug), he can see the files being downloaded by flash. If he opens the mp3 URL directly via the address bar, he can easily download the MP3, although the URLs are not guessable by the user.
I'm looking for a safe system to prevent the user from downloading the MP3 directly to his system. I have examined last.fm, as they use a similar setup, and somehow they prevent it.
In the end, you're not going to be able to stop someone who's determined. However, you can at least make it difficult.
There are several options involving referrer checks, authentication, and fun stuff like that. But probably the most successful anti-downloading check I've seen was one that works like this:
The user indicates that he wants to stream a file; the app makes an authenticated, encrypted request indicating his desired action. The result is a one-use-only and time-limited URL that is recognized by whatever application or CDN is hosting the file. After the URL is used once (i.e. by the flash app) it then expires and can never be used again. If the streaming does not start within a given amount of time (several seconds), the URL likewise expires. Obviously the URL given does not directly correspond to the file name, but is instead authenticated, decoded, and translated server-side.
It's still not impossible to work around, but it's fairly difficult.
You might use RTMP instead of HTTP to deliver audio data. RTMP is meant to be used for streaming audio, video and misc data. It streams just data rather than a file. It's not 100% safe, because if something gets to client (browser, flash player, whatever), user can save it, but it's still better than giving a file via HTTP.
You will need a server that supports RTMP though, e.g., Flash Media Server (FMS), Wowza or Red5.
As an example, lets say I'm working with a product that requires I put <iframe>s onto my page, which then get embedded into my existing website.
The issue being my website is SSL, and the iframe comes from another origin which is not SSL.
I'm not worried about javascript here as the other origin cannot access the DOM due to same-origin, but my huge concern here is that annoying "mixed content" error in IE that pops up, or the broken lock in other browsers, etc. If a user doesn't know to click "no," they don't get the content-- which is critical to the website.
What I want to do instead is provide a way to take this content and scoop it into my own script so it sends to the browser from my domain with my SSL certificate, for all resources it links to (ie, recursively parse the file and send the resources as my own). I realize this could open a huge hole because it's now coming from my origin.
What recommended approach should I take to get third party content to land on my site? Right now the content I'm pulling is the base HTML file, the CSS, and 9 images, all of which are dynamic. This is simmilar to a proxy I suppose.
What I want to do instead is provide a way to take this content and scoop it into my own script so it sends to the browser from my domain with my SSL certificate, for all resources it links to (ie, recursively parse the file and send the resources as my own). I realize this could open a huge hole because it's now coming from my origin.
Get a separate domain (mydomain.com -> thirdpartyname.mydomain-proxy.com) to serve as an HTTPS proxy for third-party content. That way they cannot run JavaScript in the same origin as your website.
Alternatively: Pressure them to adopt HTTPS. It's fast and it's free.
Im wondering what affect loading an external page with php has on a sites analytics. If php is loading an external page, and not an actual browser, will the javascript that reports back to google analytics register the page load as a hit?
Any JavaScript within the fetched page will not be run and therefore have no effect on analytics. The reason for this is that the fetched HTML page is never parsed in an actual browser, therefore, no JavaScript is executed.
Curl will not automatically download JavaScript files the HTML refers to. So unless you explicitly download the Google Analytics JavaScript file, Google won't detect the Curl hit.
Google offers a non-JavaScript method of tracking hits. It's intended for mobile sites, but may be repurposable for your needs.
You're misunderstanding how curl/file_get_contents work. They're executed on the server, not on the client browser. As far as Google and any regular user is concerned, they'll see the output of those calls, not the calls themselves.
e.g.
client requests page from server A
server A requests page from server B
server B replies with page data to server A
server A accepts page data from server B
server A sends page data to client
Assuming that all the requests work properly and don't issue any warnings/errors and there's no network glitches between server A and server B, then there is absolutely no way for the client to see exactly what server A's doing. It could be sending a local file. It could be executing a local script and send its output. It could be offshoring the request to a server in India which does the hard work and then simply claims the credit for it, etc...
Now, you CAN get the client to talk to server B directly. You could have server A spit out an HTML page that contains an iframe, image tag, script tag, css file, etc... that points to server B. But that's no longer transparent to the client - you're explicitly telling the client "hey, go over there for this content".