Jump to content

Recommended Posts

Hi,

 

I have one webhost (A) that supports no PHP and has unlimited bandwidth.

I have a second webhost (B) that does support PHP, but has limited bandwidth.

 

The website is on host A and contains a 5mb file that people can download and I'd like to count the downloads. But now I need to use host B to count the downloads.

 

I'm using this small script on host B to count the downloads.

 

<?php 
$hits=file("count.txt");
$hits[0]++;$fp=fopen("count.txt","w");
fputs($fp,$hits[0]);
fclose($fp);
header("Location: http://webhost-A.com/files/download.zip");
?>

 

The download link people see on my website is: http://webhost-B.com/download.php

 

Generally this works fine, but I found out that people can still find the direct link with download managers and then put that direct link on their website, which prevents me from counting those downloads.

 

A solution I found is to use ReadFile. But the problem is that when using ReadFile, host B first downloads the file from host A and then sends it to the user and that's exactly what I don't want.

 

Is it possible to let people download the file directly from host A without showing the direct download link in any way and also count the downloads?

  • 1 year later...

It's easy to do...

 

First, create a separate file for downloads, users will see links to this script only.

Then, in this script set some headers, like these:

header('Content-Description: File Transfer');
header('Content-Type: application/octet-stream');
header("Content-Disposition: attachment; filename=NAME_OF_FILE_THAT_USER_WILL_SEE");
header('Content-Transfer-Encoding: binary');

After that you may read a file from other site and write it to a browser of your user. It'll be considered by browser as a file for download with the name NAME_OF_FILE_THAT_USER_WILL_SEE (don't forget about extension!). Then browser will start download...

 

You may read the contents of that file or even you can create it, for example any CSV or TEXT file.

 

All that you need - to have a relation between parameters sent to this script and real file names.

 

BTW if you add session, you may limit a time when user may start download. Or you may give a specific abilities to a specific user, if you have authentication at you site...

 

At the end, if you understand the principle of this download you'd be able to do whatever you wish.

Sergei, they can't do that because host B has limited bandwidth.

 

The best thing you guys can do is increment a counter and then use a header() redirect to send the user to the file, and hope nobody finds the files directly.

 

Also, you could simply parse the logs on Host A

 

 

 

This thread is more than a year old, so OP obviously found his answer already.

Sergei, they can't do that because host B has limited bandwidth.

As I understand, limited bandwidth is not a problem for TC. He is worry about direct links only. "My" method hide direct links at all.

 

In any case he can try :) Maybe it solves his troubles.

You should create file serving script on server b.

When user visits server a, script is generating some random token with validity for example 30 seconds, and sends them to file server.

Then server A sends redirection to file server with same token.

File server should verify existence of token, and if exists, serves file else don't.

 

 

You should create file serving script on server b.

When user visits server a, script is generating some random token with validity for example 30 seconds, and sends them to file server.

Then server A sends redirection to file server with same token.

File server should verify existence of token, and if exists, serves file else don't.

Again, that's not possible given the OP's constraints.

 

Since everyone continues to give solutions that wouldn't work for the OP, and OP hasn't been here in a year, I'm closing this.

Guest
This topic is now closed to further replies.
×
×
  • Create New...

Important Information

We have placed cookies on your device to help make this website better. You can adjust your cookie settings, otherwise we'll assume you're okay to continue.