Newsgroup: it.comp.www.php
Titolo: Download di file da altro server: come fare?

Ciao a tutti.
Ho il mio semplice script per il download dei file che gira su un server,
mentre i file da scaricare sono su un altro server, un server dedicato,
con grande velocità (i file sono dei video anche abbastanza pesanti), che
si trova fisicamente in un'altra città rispetto al primo server.
Ho il classico database con l'associazione id e url.
Se l'utente scrive 
http://www.miodominio.it/download.php?id=12345
 nel
browser, gli devo mandare il file 
www.altrodominio.it/pesante.avi
,
ovviamente senza mostrargli il link: come posso fare?
Ho pensato che attualmente, usando readfile(), il file debba passare prima
al primo server e poi arrivi all'utente: è così?
C'è un modo per evitare questo "doppio download"?
Grazie, Maurizio
-- 
questo articolo e` stato inviato via web dal servizio gratuito 
http://www.newsland.it/news
 segnala gli abusi ad 
ab...@newsland.it

ovviamente senza mostrargli il link: come posso fare?
Non puoi. Ti serve uno script "traduttore" su 
altrodominio.it
, e magari
anche una qualche autenticazione: che si chiami pesante.avi o ?12345, a
te cosa cambia, se basta avere l'URL per scaricarselo? :-)
Leonardo
-- 
 What do you make, so fair and bright;
 What do you build with sails for flight;
 What do you weave with wool so white?

 te cosa cambia, se basta avere l'URL per scaricarselo? :-)
Sě, ovviamente download.php controlla prima se si hanno i permessi giusti.
:)


 link crittato).
In che senso ?

 In che senso ?
Nel senso che vedrò se posso fare in modo a far sì che sarà il file swf a
riprodurre il video in streaming oppure a chiedere all'utente dove
salvarlo. Credo si possa fare col metodo FileReference.download(). Pare
però possa scaricare "solo" file fino a 100MB. :(
Ad ogni modo, Flash o non Flash, l'idea è che se il client conosce il link
può scaricare il file direttamente. Se uno usa uno sniffer è chiaro che
vede che i dati provengono dal secondo server, ma la maggior parte degli
utenti forse neppure se ne accorgeranno. ;-)
Ciao, Maurizio


 riprodurre il video in streaming oppure a chiedere all'utente dove
No intendevo come faceva donwload.php a inviare il link ad un eseguibile 
flash.

 flash.
Un semplice:
<?php echo print '<object ... src="miofile.swf?link=blablabla" ...>'; ?>
non andrebbe bene?
Altrimenti ci sarebbe LoadVars.load(url).
Oppure AMFPHP o, immagino, altre soluzioni.
Insomma, ormai la comunicazione client->server è stata abbastanza
sviluppata.


 anche una qualche autenticazione
scusa, ma forse non può è un po' troppo generico... perché basta fare
una specie di proxy su miodominio, inviando da php una richiesta http
al server altrodominio e passare tutti i byte letti al client. O no?
Insomma, un readfile su locazione http, diciamo.
-- 
Sherlock

Sherlock wrote:

nel caso migliore.. raddoppia il traffico.. e questo e' male (tm)..
-- 
www.iuz-lab.info
 - 
www.php-faq.org

 Insomma, un readfile su locazione http, diciamo.
Ehm, se leggi il mio primo post, era proprio ciň che volevo evitare :))
Pensavo comunque che in teoria ciň che chiedevo io si potrebbe anche fare,
avendo il controllo completo dei due server (cosa che non ho) e spoofando
un po' di pacchetti.
Se S1 e S2 sono i due server e C il client, quando C contatta S1, S1 dice
a S2 di inviare i dati a C usando perň l'indirizzo di S1. Questo per ogni
pacchetto ricevuto.
Si genera ancora un po' di traffico, ma almeno lo si minimizza.
Ad ogni modo, il gioco non vale la candela, quindi non provo neppure a
vedere se realmente avrebbe funzionato. ;-)
Saluti, Maurizio


 pacchetto ricevuto.
Ma pacchetti di che livello? ip? 
Non mi pare che risolverebbe il problema, nel senso che comunque il
al browser dovrebbe arrivare l'url dove stanno effettivamente i file.
Alla fine per quello che vuoi tu mi sa che la crittazione dei dati è
davvero l'unica cosa, ma poi neanche quella se proprio vogliamo
dirlo...perché io mi metto a guardare i pacchetti http e credo proprio
vedrei la richiesta effettiva.
-- 
Sherlock

Chiamando s1 quello con il database dove hai l'associazione id -> file
e s2 quello che ha effettivamente il file
su s2 non hai proprio nessuna possibilita di agire? se no metti il file 
download.php sul server 2 che fa la query sul server s1 posi fa il 
readfile in locale.
Oppure download.php potrebbe fare un div nascosto con il link al file 
sul server2, l'utente normale vedrebbe solo la possibilita di scaricare 
il file, pero quello un po piu evoluto se si guarda l'html risultante 
vedrebbe il vero indirizzo


 vedrebbe il vero indirizzo
mah... io comunque non ho capito quanto sia importante nascondere il 
fatto che i file stiano da un'altra parte.
Come dicevo, usando Wireshark, sebbene sia una cosa da utenti molto
evoluti, anzi tecnici direi, si potrà sempre vedere dove il browser fa
la richiesta vera del file pesante.avi analizzando i pacchetti tcp con
dentro le richieste http...
-- 
Sherlock


wrote:



Si', quello si puo' fare; pero' cessa lo scopo. Perche' a quel punto ti
serve banda X per scaricare il file verso il client e banda Y per avere
il file da 
altrodominio.it
 - risultato: il server usa ancora piu' banda
di prima (vabbe' che Y e' banda in download, ma insomma...).
Ha senso se il problema e' quello di spazio disco: su 
miodominio.it
 per
esempio hai poco spazio disco (ma hai MySQL e tutte cose), mentre forse
altrodominio.it
 ti da' solo spazio magari illimitato. Allora... *sempre
che il contratto te lo consenta* e se 
miodominio.it
 consente la fopen()
verso server esterni (c'e' pure quel caso li')... puoi fare il readfile
su http, esattamente.
Nel caso di Maurizio il problema e' proprio la banda, sicche'... :-(
Comunque e' vero: rispondere al quotato con "non puoi" come ho fatto io
e', nel caso generale, sbagliato.


 Ma pacchetti di che livello? ip? 
No direi tcp perché vuole che le richieste inoltrate a S1 vengano 
segnalate da S1 a S2 (e immagino i macelli con i contatori) e che S2 le 
serva con pacchetti col source ip address falso e con i dati tcp della 
comunicazione.
Sarebbe una cosa bestiale perché poi S1 dovrebbe falsare i propri 
contatori in base a quello che S2 ha trasmesso sul canale.

 comunicazione.
beh ma ... se tu mi dici "le serva con pacchetti col source ip address
falso" non stiamo parlando di livello ip, cioč indirizzamento e routing?
Il tcp che io sappia gestisce le porte, č ip che si occupa degli
indirizzi (anche se stiamo andando OT, ma volevo capire)
-- 
Sherlock

indirizzi (anche se stiamo andando OT, ma volevo capire)
Infatti, se riesci a realizzare un reflector "doppio" a livello IP hai
risolto il problema:
Client ==> manda pacchetto con DESTADDR = S1
S1 = manda pacchetto (per es. incapsulato in ICMP) a S2
S1 pero' dovra' captare il pacchetto "PRIMA" che finisca in bocca allo
strato TCP di S1... quindi, il sistema piu' pratico e' usare una porta
non standard per HTTP, che so, 81 od 8080.
In pratica S1 per prima cosa manda un redirect a
 
http://S1:8080/directorydiS2tantononcambianulla/file.zip
Il client manda un pacchetto SYN alla porta 8080 di S1, e il reflector
lo fa sparire (per evitare che S1 risponda con un brutale RST, che non
farebbe funzionare un accidente causa teardown sul client -- oppure e'
possibile bloccare i RST in uscita basandosi sul loro contenuto). Poi,
manda un ICMP a S2 contenente il pacchetto tapioca come fosse payload.
Su S2 un altro diavoletto prende su il pacchetto, ne crea un pacchetto
TCP riscrivendo la destinazione (S2!=S1), ricalcola il checksum, e poi
inietta tutto nell'interfaccia locale. Deve anche creare una rule, nel
firewall, che spoofi l'indirizzo sorgente dei pacchetti diretti all'IP
del client mettendoci dentro S1.
Poi ci vuole un sistema che intercetti la fine della comunicazione (il
RST) e ne approfitti per cancellare la regola relativa dal firewall, o
ti si ingorga ugniňsa nel giro di poco (abbastanza, perche' sembri che
funzioni tutto -- troppo poco perche' sembri qualcosa di solido).
E ovviamente, se S2 ha un firewall minimamente stateful, oppure lavora
d-nattato (e quindi, gli serve un vero SYN dall'esterno), non funziona
neanche a pregare in cinese.
Tolte le bischerate che sicuramente ci avro' ficcato, e quello che non
mi sono ricordato di metterci, piu' o meno le cose dovrebbero stare in
questo modo.
Forse si puo' fare di piu' (e meglio) creando una VPN e modificando un
qualche sistema di aggregazione della banda ma IMHO e' circa lo stesso
lavoro che andando di netfilter/pcap/libinject. A meno che qualcuno lo
abbia gia' fatto, si capisce :-)


 indirizzi (anche se stiamo andando OT, ma volevo capire)
Parliamo anche di ip, nel senso che il server S2 dovrebbe mandare i 
pacchetti al client costruiti come se venissero da S1, quindi dovrebbe 
alterare sicuramente lo strato ip rispetto all'uso consueto, ma il 
pacchetto ha anche la parte di tcp che dovrebbe essere artefatta.
Su inet il payload, il carico effettivo, viene impacchettato in TCP e 
c'è tutto un controllo per sapere quanto ne puoi mandare (algoritmo slow 
start e tcp windowing) e dei contatori da aggiornare in ogni scambio. 
S1 dovrebbe dire a S2 a che punto sono nella comunicazione S1 e il 
client. Secondo me sarebbe un macello bestiale.

 lavoro che andando di netfilter/pcap/libinject.
Alla fine la cosa seria secondo me e non cercare di nascondere niente, 
in questo modo zac! via il problema alla radice.

in questo modo zac! via il problema alla radice.
Su questo non c'e' il minimissimo dubbio! :-)
