ftp bestand versturen via php

[Gelunox]

Ik ben op zoek naar een manier waardoor ik in php met een ftp server kan verbinden en vervolgens zonder tussenkomst van php de ftp het bestand naar de gebruiker laten sturen.

Het idee is dat ik een ftp server heb draaien met gebruikersnamen en wachtwoorden, ik wil gebruikers bestanden kunnen laten downloaden van die ftp server, maar de gebruikers niet die ftp accounts prijsgeven. Daarnaast wil ik niet dat php als middleman gaat spelen en extra resources opgebruikt.

Is dit uberhaupt mogelijk?

Ik heb nu al meerdere google zoekpogingen gedaan en alle zoektermen die maar in me opkwamen uitgevoerd maar ik heb het niet kunnen vinden.

[SyphOn]

http://php.net/manual/en/book.ftp.php

[GlowMouse]

Zo twee opties:
- eerst via php de file downloaden naar een map, en dan de user via http de file laten downloaden
- een ftp server gebruiken waarbij je makkelijk tijdelijke accounts kunt toevoegen en toch de user via ftp laten downloaden

[Osiris]

SyphOn schreef op zondag 20 oktober 2013 @ 22:38:
http://php.net/manual/en/book.ftp.php

Heb je überhaupt gelezen wat de TS precies wil?

Ontopic:
Ik heb het idee dat dit niet gaat lukken. Het lijkt mij sterk dat een browser verstand heeft van het downloaden van een file via (een deel van) het FTP-protocol, terwijl hij bezig is met HTTP.

Wat bedoel je verder precies met die "extra resources" die PHP zou gebruiken? Memory? CPU-kracht? Want een bestandje doorzetten, tja, daar hoeft PHP zelf natuurlijk niet veel voor te doen.. Staat ie gewoon uit z'n neus te vreten.

[ Voor 22% gewijzigd door Osiris op 20-10-2013 22:41 ]

[Gelunox]

Osiris schreef op zondag 20 oktober 2013 @ 22:41:
[...]

Heb je überhaupt gelezen wat de TS precies wil?

Ontopic:
Ik heb het idee dat dit niet gaat lukken. Het lijkt mij sterk dat een browser verstand heeft van het downloaden van een file via (een deel van) het FTP-protocol, terwijl hij bezig is met HTTP.

Wat bedoel je verder precies met die "extra resources" die PHP zou gebruiken? Memory? CPU-kracht? Want een bestandje doorzetten, tja, daar hoeft PHP zelf natuurlijk niet veel voor te doen.. Staat ie gewoon uit z'n neus te vreten.

voor zover ik weet van php en bestanden versturen naar de browser kost dat de server net zo veel ram als de grote van het bestand (tenzij je dat met lusjes links en rechts opvangt door telkens kleine stukjes te versturen)

Wat ik zou willen bereiken is dat php inlogt op de server en dat of aan de client kan koppelen zonder dat die de username/password te weten komt of dat php op de een of andere manier de ftp server wijs kan maken het bestand rechtstreeks naar de browser te duwen.

[Patriot]

Dat kan niet. Je hebt echter zelf de oplossing al, waarom gebruik je die niet? Is dat te ingewikkeld? Dan kun je beter iemand inhuren om dit werk voor je te laten doen.

[Osiris]

gotomtom95 schreef op zondag 20 oktober 2013 @ 22:45:
[...]

voor zover ik weet van php en bestanden versturen naar de browser kost dat de server net zo veel ram als de grote van het bestand (tenzij je dat met lusjes links en rechts opvangt door telkens kleine stukjes te versturen)

Wat ik zou willen bereiken is dat php inlogt op de server en dat of aan de client kan koppelen zonder dat die de username/password te weten komt of dat php op de een of andere manier de ftp server wijs kan maken het bestand rechtstreeks naar de browser te duwen.

"readfile() will not present any memory issues, even when sending large files, on its own. If you encounter an out of memory error ensure that output buffering is off with ob_get_level()."
(http://nl3.php.net/manual/en/function.readfile.php)

[Gelunox]

Osiris schreef op zondag 20 oktober 2013 @ 22:56:
[...]

"readfile() will not present any memory issues, even when sending large files, on its own. If you encounter an out of memory error ensure that output buffering is off with ob_get_level()."
(http://nl3.php.net/manual/en/function.readfile.php)

als ik op die manier een bestand probeer te versturen dan krijg ik of een empty response (ERR_EMPTY_RESPONSE) of een foutmelding van mem overflow (omdat bufferen aanstaat) of een foutmelding die zegt "ob_clean(): failed to delete buffer. No buffer to delete"

ik heb letterlijk alles gekopierd van example #1 en een bestand van 10GB op de server uitgezocht
$file = 'D:/Films/Aeon Flux.mkv';

[Room42]

gotomtom95 schreef op zondag 20 oktober 2013 @ 23:17:
[...]
$file = 'D:/Films/Aeon Flux.mkv';

Het lijkt mij heeeeel sterk dat dit klopt. Het moet het absolute path op de ftp-server zijn. Bijvoorbeeld "/Films/Aeon Flux.mkv".

[Gelunox]

Room42 schreef op zondag 20 oktober 2013 @ 23:21:
[...]

Het lijkt mij heeeeel sterk dat dit klopt. Het moet het absolute path op de ftp-server zijn. Bijvoorbeeld "/Films/Aeon Flux.mkv".

de ftp en http server draaien op de zelfde machine. dus voor testing purposes roep ik de file direct aan.

[ Voor 8% gewijzigd door Gelunox op 20-10-2013 23:25 ]

[RobIII]

gotomtom95 schreef op zondag 20 oktober 2013 @ 23:23:
[...]


de ftp en http server draaien op de zelfde machine. dus voor testing purposes roep ik de file direct aan.

Waarom dan nog lopen frotten met FTP Je kunt die bestanden dan toch ook rechtstreeks benaderen?

[Room42]

Ok, je hebt het FTP-idee dus losgelaten?

Wat geeft PHP voor error? Voeg even wat echo's toe om te debuggen.

[Gelunox]

RobIII schreef op zondag 20 oktober 2013 @ 23:25:
[...]

Waarom dan nog lopen frotten met FTP Je kunt die bestanden dan toch ook rechtstreeks benaderen?

Het hele punt dat ik dit moeilijke gedoe wil doen is dat php en http niet er voor gemaakt zijn om grote bestanden over te zetten terwijl het File Transfer Protocol dat wel is.
Natuurlijk wil ik daar van terug komen op het moment dat php het ook gewoon zelfstandig kan, maar dat lijkt tot nu toe niet zo te zijn.

[Osiris]

gotomtom95 schreef op zondag 20 oktober 2013 @ 23:27:
[...]


Het hele punt dat ik dit moeilijke gedoe wil doen is dat php en http niet er voor gemaakt zijn om grote bestanden over te zetten terwijl het File Transfer Protocol dat wel is.

Maar als je het via PHP wilt starten, dan bedoel je dus via een browser. En je wilt dus via FTP én de browser het bestand downloaden. Via een losse FTP-client wil je natuurlijk ook niet. En een browser is niet gemaakt voor FTP. Dus ik snap je "is er niet voor gemaakt"-argument niet, aangezien een browser dat ook niet is.

[Gelunox]

Room42 schreef op zondag 20 oktober 2013 @ 23:26:
Ok, je hebt het FTP-idee dus losgelaten?

Wat geeft PHP voor error? Voeg even wat echo's toe om te debuggen.

<b>Fatal error</b>: Allowed memory size of 134217728 bytes exhausted (tried to allocate 2351239168 bytes) in <b>M:\Web\Root\ftp\index.php</b> on line <b>20</b><br />

deze komt als ik bufferen uit zet (zowel in php.ini of via ob_end_flush() )
<b>Notice</b>: ob_clean(): failed to delete buffer. No buffer to delete in <b>M:\Web\Root\ftp\index.php</b> on line <b>15</b><br />

en de laatste (deze komt van de browser, niet van de ftp) als ik ob_clean en flush wegcomment
ERR_EMPTY_RESPONSE

file_exists() -> true
filesize() -> -1943731809

Osiris schreef op zondag 20 oktober 2013 @ 23:31:
[...]

Maar als je het via PHP wilt starten, dan bedoel je dus via een browser. En je wilt dus via FTP én de browser het bestand downloaden. Via een losse FTP-client wil je natuurlijk ook niet. En een browser is niet gemaakt voor FTP. Dus ik snap je "is er niet voor gemaakt"-argument niet, aangezien een browser dat ook niet is.

De meeste browsers doen er niet moeilijk over om bestanden van de ftp af te accepteren en downloaden ze zonder problemen op dezelfde manier als van http

[Osiris]

gotomtom95 schreef op zondag 20 oktober 2013 @ 23:34:
[...]

De meeste browsers doen er niet moeilijk over om bestanden van de ftp af te accepteren en downloaden ze zonder problemen op dezelfde manier als van http

Maar jij zegt:

HTTP prima voor kleine bestandjes, echter niet voor grote bestanden, daar is FTP voor.

En als een FTP-client derhalve geschikt is voor grote bestanden, hoe is een browser daar dan geschikt voor, als je hierboven HTTP al afgekeurd hebt? Want je zegt zelf al: "een groot bestand hoort niet".. Maar het kán wel.

De browser mist veel functies die een daadwerkelijke FTP-client wel heeft vaak. (Denk aan resumen ofzo..) Een browser kán het wel.. FTP.. Maar is hij er ook echt voor bedoeld?

Dus IMO ben je nu een probleem wat eigenlijk niet echt bestaat ook nog eens half aan het oplossen.

[Gelunox]

Osiris schreef op zondag 20 oktober 2013 @ 23:44:
[...]

Maar jij zegt:

HTTP prima voor kleine bestandjes, echter niet voor grote bestanden, daar is FTP voor.

En als een FTP-client derhalve geschikt is voor grote bestanden, hoe is een browser daar dan geschikt voor, als je hierboven HTTP al afgekeurd hebt? Want je zegt zelf al: "een groot bestand hoort niet".. Maar het kán wel.

De browser mist veel functies die een daadwerkelijke FTP-client wel heeft vaak. (Denk aan resumen ofzo..) Een browser kán het wel.. FTP.. Maar is hij er ook echt voor bedoeld?

Dus IMO ben je nu een probleem wat eigenlijk niet echt bestaat ook nog eens half aan het oplossen.

Hahaha, misschien wel. Ik probeer een werkende methode te zoeken die niet aan de een of andere kant het geheugen weg vreet en waarvoor ik niet allemaal rare fratsen hoef uit te halen.

[Osiris]

Persoonlijk ben ik 't helemaal met je eens dat HTTP niet bedoeld is voor grote bestanden. Maar een browser ook.
Ik zou gewoon een oplossing zoeken m.b.v. een daadwerkelijke FTP-client.

[Fish]

Geen rare fratsen? fatsoenlijke rechten op de ftp zetten en vandaar laten downloaden ?

[Gelunox]

fish schreef op zondag 20 oktober 2013 @ 23:53:
Geen rare fratsen? fatsoenlijke rechten op de ftp zetten en vandaar laten downloaden ?

en wat nou als je dat voor elke gebruiker appart wil doen omdat je geen centrale code wil hebben om uit te delen aan jan alleman?

[Osiris]

gotomtom95 schreef op zondag 20 oktober 2013 @ 23:55:
[...]


en wat nou als je dat voor elke gebruiker appart wil doen omdat je geen centrale code wil hebben om uit te delen aan jan alleman?

Wat is daar het probleem bij dan?

Of uploaden naar usenet en een NZB maken.. Hoef je ook maar 1x te uploaden

[ Voor 12% gewijzigd door Osiris op 20-10-2013 23:56 ]

[Merethil]

En mocht dat een groot probleem zijn zit je toch vast aan HTTP lijkt me.

[Gelunox]

Osiris schreef op zondag 20 oktober 2013 @ 23:56:
[...]

Wat is daar het probleem bij dan?

kost veel tijd en moeite en is, in ieder geval met filezilla, lastig te onderhouden. (ik weet niet of er ftp servers zijn die hun useraccounts in een database bijhouden)

[CH4OS]

Wat is er mis mee om een FTP-server correct te configureren en te administreren, zodat de gebruiker alleen bij zijn bestanden kan als die eenmaal klaargezet zijn door PHP?

[DataGhost]

gotomtom95 schreef op zondag 20 oktober 2013 @ 23:58:
[...]


kost veel tijd en moeite en is, in ieder geval met filezilla, lastig te onderhouden. (ik weet niet of er ftp servers zijn die hun useraccounts in een database bijhouden)

Ja die zijn er, proftpd bijvoorbeeld.

[Fish]

gotomtom95 schreef op zondag 20 oktober 2013 @ 23:58:
[...]


kost veel tijd en moeite en is, in ieder geval met filezilla, lastig te onderhouden. (ik weet niet of er ftp servers zijn die hun useraccounts in een database bijhouden)

Wel eens "filezila server.xml" bekeken ? geen database maar configureerbaar genoeg dunkt me.

[ Voor 7% gewijzigd door Fish op 21-10-2013 00:15 ]

[Ramon]

Wat de hell is dit voor onzintopic? HTTP niet geschikt voor grote bestanden dus dan maar iets raars doen met PHP en FTP? WTF?

Serveer die bestanden gewoon met HTTP zodat je PHP kan gebruiken voor access control. Of wil je zeggen dat die iso's die ik zojuist heb gedownload een droom zijn? Wil je toch per se FTP gebruiken stuur de gebruiker dan gewoon een link met het ftp:// protocol. Niet moeilijker doen dan nodig is. Wil je dat gebruikers niet kunnen delen dan maak je per download een map (bijv een uuid) die slechts tijdelijk geldig is en wordt verwijderd na verloop van tijd, maar dat zou ik al echt veel te complex vinden.

[Snake]

Uiteindelijk wil jij dat de user verbinding maakt op de FTP, maar zonder username en paswoord.

Dus je creeert on the fly een random foldername in de FTP, zet die op publiek, kopieer / symlink bestand erin, en laat de user die downloaden.

Na x aantal tijd verwijder je de map.

Laat de mapnamen zo random zijn dat ze niet te gues-able zijn?

[Hydra]

gotomtom95 schreef op zondag 20 oktober 2013 @ 23:27:
[...]


Het hele punt dat ik dit moeilijke gedoe wil doen is dat php en http niet er voor gemaakt zijn om grote bestanden over te zetten terwijl het File Transfer Protocol dat wel is.
Natuurlijk wil ik daar van terug komen op het moment dat php het ook gewoon zelfstandig kan, maar dat lijkt tot nu toe niet zo te zijn.

Dat is dus gewoon complete onzin. Http en ftp versturen bestanden beiden binair. Je keuze voor ftp is dus nergens voor nodig. Je kunt die bestanden net zo goed gewoon via http versturen.

CptChaos schreef op maandag 21 oktober 2013 @ 00:02:
Wat is er mis mee om een FTP-server correct te configureren en te administreren, zodat de gebruiker alleen bij zijn bestanden kan als die eenmaal klaargezet zijn door PHP?

Typisch PRG antwoord: gewoon antwoorden op de vraag zonder te zien dat de vraag verkeerd is.

[ Voor 23% gewijzigd door Hydra op 21-10-2013 07:35 ]

[meneer william]

Als ik vragen mag: 'Wat is het idee hier achter?'. Will je een soort publieke file share iets opzetten.
Als je gewoon ftp via de browser wil creëren waar gebruiker automatisch worden ingelogd kun je toch gewoon handmatig een ftp authenticatie request opzetten en deze versturen via javascript. Dan moet je gewoon tijdelijk een ftp account aanmaken en die daarna weer verwijderen. Vervolgens genereer je voor de gebruikers een link die hun doorstuurt naar de ftp server (met authenticatie request). Ze worden automatisch ingelogd en klaar is kees.

[Cartman!]

Hoe groot zijn de bestanden waar we het over hebben, 10MB, 100MB, 1GB, 10GB? Als het om files van 10GB gaat zou ik dat ook liever via FTP doen namelijk.