[PHP] File aanbieden met unique id ter preventie re-download

En een txtje erin stoppen zal misschien de eerste keer werken, maar eenmaal ze dit doorhebben is een txtje gemakkelijk te verwijderen. De vraag is waarom je dit zou willen tegenhouden?

Als je iets wil kunnen traceren na een download zal je unieke digitale watermerken moeten gebruiken en dat kost CPU/RAM. Alle andere manieren gaan gewoon niet werken, behalve DRM, maar dan jaag je ook weer gebruikers weg.

ScuL schreef op dinsdag 27 augustus 2013 @ 18:57:

Het probleem dat ik zie is de CPU kracht+geheugen vereist. Als je de zip compressie aanroept bij iedere download (bestand is circa 160MB) trekt dat de server plat waarschijnlijk.
Iemand een inventief idee?

Dan zul je ervoor moeten zorgen dat je het intensieve proces offloadt naar een andere server die de verwerking afhandelt voordat het bestand aan de gebruiker wordt aangeboden. Je zou hierbij bijvoorbeeld gebruik kunnen maken van Windows Azure of Amazon Web Services (betalen voor wat je gebruikt), maar je zou ook kunnen overwegen om hier een eigen servertje voor in te zetten. De server hoeft niet krachtig te zijn, een Raspberry Pi-achtig apparaat zou hiervoor al kunnen volstaan.

Het proces zou er dan als volgt uit kunnen zien:
1) Gebruiker klikt op "download" / "koop nu" (aangezien je het hebt over rechten en licenties zal "koop nu" toepasselijker zijn)
2) Vraag de gebruiker om zijn e-mailadres en sla dit op in een databaseje samen met andere relevante gegevens (zoals naam van het product en aankoopdatum)
3) Presenteer de gebruiker met een pagina met ongeveer deze tekst:

Hartelijk dank voor uw aankoop van <product X>. Binnen enkele minuten zult u in uw mailbox een link aantreffen waar u uw aankoop kunt downloaden. Let op, deze link is beperkt houdbaar.

4) Op een message queue (kan ook een tabel in een database zijn) plaats je een nieuw bericht met daarin informatie over de aankoop die zojuist is gedaan. Denk hierbij aan e-mailadres, naam van het product en het order-ID in je database.
5) Op je processing-server laat je een proces draaien dat je aan de message queue hangt. Zodra er een nieuwe taak binnenkomt, pakt de processing job dit bericht van de queue en verwerkt het. De verwerking kan ongeveer als volgt gaan:
5.1) Je proces kijkt naar het product dat moet worden aangeboden (bijvoorbeeld een video) en neemt de nodige voorbereidingen (temporary filename genereren en data wegschrijven)
5.2) Je job voert de bewerking uit (zoals de GUID inserten in de videostream)
5.3) Je job comprimeert (indien nodig) de output van je eerdere bewerking
5.4) Je job uploadt de aangepaste URL naar je webserver / cloud service provider en genereert de benodigde toegangs-URLs (Amazon Web Services, Windows Azure)
5.5) Je job verstuurt een e-mail naar de gebruiker met iets als de volgende tekst:

Hallo <voornaam>,

Enige tijd geleden heb je bij <naam website> de volgende bestelling geplaatst:
1x <naam product>

Dit product wordt geleverd als download, je kunt het op de volgende locatie downloaden:
<downloadlink, direct of via een redirectpagina>

Let op: deze link is beperkt houdbaar en zal verlopen na <verloopdatum>. Zorg dat je het product op je computer opslaat. Na de verloopdatum zal de downloadlink niet meer werken.

Heb je vragen? Neem dan contact op met onze klantenservice.

Met vriendelijke groet,
<naam website>

5.6) Zorg dat de taak in je message queue als 'voltooid' wordt gemarkeerd en ga verder met het verwerken van de volgende taak.

Door een message queue te gebruiken kun je een wachtrij aanleggen van downloads die afgehandeld moeten worden. Als het heel erg druk is zou je meerdere instances van je processing job kunnen laten draaien, waarbij je d.m.v. de message queue ervoor zorgt dat een beschikbare instance zo snel mogelijk weer een taak gaat uitvoeren.

Als er fouten optreden tijdens de verwerking moet je een foutafhandelingsstrategie bepalen: je kunt het bericht terug op de queue zetten (zodat het later nog een keer wordt geprobeerd), of je stuurt een seintje naar de beheerder. Je kunt een mengeling overwegen zodat je er zo weinig mogelijk werk aan hebt.

Een paar aandachtspunten:
- Het is van belang dat de taak op je message queue terechtkomt voordat je de gebruiker vertelt dat de bestelling met succes is geplaatst. Als het niet lukt om een bericht op de message queue achter te laten, annuleer je de betaling (je gebruiker hoeft niet op te draaien voor een technische fout, en jij wil het liefste zo weinig mogelijk doen met klantenservice/aftercare).
- Zorg voor goede beveiliging van je message queue, je wilt niet dat er berichten op de queue komen die er niet horen.
- Zorg ervoor dat je je tijdelijke opslagruimte periodiek (bij voorkeur geautomatiseerd) opruimt, zo voorkom je dat je bestanden hebt rondslingeren die veel ruimte innemen. Bij cloud storage providers betaal je ook nog eens voor de gebruikte hoeveelheid storage: hoe minder, hoe beter.
- Als je een tussenpagina maakt voor je de download aanbiedt, zorg er dan voor dat je de OrderId controleert zodat mensen geen download krijgen als ze simpelweg het OrderId ophogen. Gebruik iets als HMAC-SHA256 die je meegeeft aan je URL en verifieer de signature.

Je zou t gewoon even kunnen testen qua performance in php met zo'n store zip aanmaken? Als dat snel genoeg is, en afhankelijk van hoeveel downloads je verwacht per minuut, kan je een beeld krijgen van wat je al dan wel niet aan extra dingen nodig hebt.

Een paar aandachtspunten:
- Het is van belang dat de taak op je message queue terechtkomt voordat je de gebruiker vertelt dat de bestelling met succes is geplaatst. Als het niet lukt om een bericht op de message queue achter te laten, annuleer je de betaling (je gebruiker hoeft niet op te draaien voor een technische fout, en jij wil het liefste zo weinig mogelijk doen met klantenservice/aftercare).
- Zorg voor goede beveiliging van je message queue, je wilt niet dat er berichten op de queue komen die er niet horen.
- Zorg ervoor dat je je tijdelijke opslagruimte periodiek (bij voorkeur geautomatiseerd) opruimt, zo voorkom je dat je bestanden hebt rondslingeren die veel ruimte innemen. Bij cloud storage providers betaal je ook nog eens voor de gebruikte hoeveelheid storage: hoe minder, hoe beter.
- Als je een tussenpagina maakt voor je de download aanbiedt, zorg er dan voor dat je de OrderId controleert zodat mensen geen download krijgen als ze simpelweg het OrderId ophogen. Gebruik iets als HMAC-SHA256 die je meegeeft aan je URL en verifieer de signature.

punt 1 is een non-issue; als je het slim aanpakt kan je die taak draaien vlak voor de download; werkt het niet, dan kan je het nogmaals proberen, en nogmaals, etc etc etc... zodra het wel lukt sla je het op voor een X periode, waarna het opgeruimt wordt (en eventueel later dus weer opnieuw gegenereerd wordt)

punt 2 is een kwestie van een goede omgeving opzetten, je wilt sowieso dat al je back-end systemen beveiligd zijn, message queue is het minste van je zorgen (denk aan order informatie, credit card informatie, etc etc etc)

punt 3 hoeft niet per se, zolang de data niet direct aanspreekbaar is, maar als het om veel data gaat groeit je systeem snel genoeg dat je het wel wilt opruimen.

Overigens zijn die message queue concepten redelijk standaard, dus er zullen vast meerdere oplossingen voor zijn... denk er ook aan dat je buiten PHP kan kijken voor een oplossing.. in python heb je Celery als task engine over een message queue heen (rabbitMQ), terwijl java Mule heeft als ESB-achtige oplossing ..

Overigens kan je met nginx leuke geintjes uithalen om post-download acties uit te voeren: http://www.tipstuff.org/2...sfully-download-file.html

DXaroth schreef op dinsdag 27 augustus 2013 @ 21:54:
[...]


punt 1 is een non-issue; als je het slim aanpakt kan je die taak draaien vlak voor de download; werkt het niet, dan kan je het nogmaals proberen, en nogmaals, etc etc etc... zodra het wel lukt sla je het op voor een X periode, waarna het opgeruimt wordt (en eventueel later dus weer opnieuw gegenereerd wordt)

Het gaat over een operatie die enige tijd kan duren, daarom stel ik juist de message queue + processor als aparte taak voor. Dat wil je niet in-process hebben draaien omdat dat nadelig is voor de performance van je webserver.

punt 2 is een kwestie van een goede omgeving opzetten, je wilt sowieso dat al je back-end systemen beveiligd zijn, message queue is het minste van je zorgen (denk aan order informatie, credit card informatie, etc etc etc)

Zekers, maar het kan nooit kwaad om het even te benadrukken. Zeker als je publieke services afneemt (Azure Message Bus bijvoorbeeld) of de boel verspreidt over meerdere machines is een configuratiefout snel gemaakt, en dan staat je message queue wijd open.

punt 3 hoeft niet per se, zolang de data niet direct aanspreekbaar is, maar als het om veel data gaat groeit je systeem snel genoeg dat je het wel wilt opruimen.

Het gaat over bestanden van 160 MB per keer - met 15 downloads praat je dan al over meer dan 2 GB aan gebruikte opslagruimte. Opruimen kan dan geen kwaad.

Overigens zijn die message queue concepten redelijk standaard, dus er zullen vast meerdere oplossingen voor zijn... denk er ook aan dat je buiten PHP kan kijken voor een oplossing.. in python heb je Celery als task engine over een message queue heen (rabbitMQ), terwijl java Mule heeft als ESB-achtige oplossing ..

Een tabelletje in de database kan al voldoende zijn in deze situatie, maar dat hangt af van de verwachte load en de beschikbare middelen. Als het gaat over duizenden transacties per dag kan het interessant zijn om RabbitMQ op te zetten en een paar clients eraan te hangen, als het gaat over 2 downloads per dag volsta je met een database-tabel en een cronjob.

Overigens kan je met nginx leuke geintjes uithalen om post-download acties uit te voeren: http://www.tipstuff.org/2...sfully-download-file.html

Die kende ik nog niet, thanks

Om de load te beperken zou je ook een aantal downloads vooraf klaar kunnen zetten (kost je wel ruimte). Bijvoorbeeld een cronjob die er elke nacht voor zorgt dat je van van elke download een minimaal/maximaal aantal unieke varianten heb klaar staan (desnoods afhankelijk van populariteit). Download_id's bepaal je dus al van te voren welke je aan een bestelling koppelt.

Wat voor bestanden gaat het om? Wil je dit doen met afbeeldingen, documenten, binaries, ... ?

Door een bestandje toe te voegen aan de ZIP-file los je je probleem niet op: iemand kan met gemak alle bestanden uitpakken, je bestandje wegmikken, en het opnieuw online zetten. Ook de ZIP-file zelf gebruiken (door wat metadata te inserten in het comment-veld) is geen waterdichte oplossing, want mensen kunnen het bestand uitpakken en opnieuw uploaden.

De enige manier waarop het echt kan is door ieder bestand (of in ieder geval, alle belangrijke bestanden) te voorzien van een (onzichtbaar) watermerk. Bij voorkeur gebruik je voor ieder bestand een apart kenmerk, zodat het minder opvalt dat een bepaald patroon terugkomt.

ScuL schreef op woensdag 28 augustus 2013 @ 10:30:
Tot zoverre bedankt voor alle replies het geeft wat ideeën.


[...]


Het gaat om een zip-bestand met daarin een 7500 stuks losse files (zowel text als binaries)
Bij voorkeur kan ik het watermerk in een bestandje inserten (soort van "add" binnen de zip) - zonder dat de hele reut opnieuw ingepakt hoeft te worden.

De download frequentie is een probleem, ik verwacht namelijk minstens 2000 a 3000 downloads voor iedere keer dat er een nieuwe versie wordt klaargezet. Dat zou 390GB aan schijfruimte vereisen als ze allemaal uniek moeten zijn..

Het integreert in een bestaand forum-systeem (phpBB) dus ik heb van iedere mogelijke downloader al een unieke code die geregistreerd & gematched kan worden

Wat belet mensen om het opnieuw te zippen zonder je toevoeging? Het is niet echt een robuuste of betrouwbare oplossing voor je probleem.

Je zou per bestand (in de ZIP, niet de ZIP zelf) moeten bekijken hoe je een permanent en niet-verwijderbaar watermerk aanbrengt.

Wat je ook kan doen is gewoon een wachtwoord op de ZIP zetten en dat per download veranderen.
Als mensen het dan sharen weet je welk wachtwoord voor wie was. Als ze het wachtwoord verwijderen, dan had de uploader vast ook wel je TXT'tje verwijderd.

ScuL schreef op woensdag 28 augustus 2013 @ 12:31:
[...]


Dat zou veel te veel processing om handen hebben zeker bij het aantal downloads waar het om gaat.
Er zijn heel veel manieren om een hash of key te verstoppen in diverse text-bestanden die noodzakelijk zijn voor de functionaliteit van het pakket en niet op het 1e gezicht opvallen dus het bestandje wegmikken is niet zo eenvoudig als het lijkt

"Noodzakelijk", "functionaliteit", "pakket"... wees nou eens duidelijk waar het om gaat en wat je wilt bereiken? Wat zit er in die ZIP? Zijn de bestanden daarin afhankelijk van elkaar? Wat is het en wat doen mensen er mee? Het blijft nogal vaag en een specifieke oplossing is zo niet te geven.

Je zou in theorie een index kunnen maken met beschikbare bestanden, en zodra het bestand gedownload moet worden, pak je het eerste bestand van de index, geef je dat aan de gebruiker, wordt dat bestand van de index gewist en daarna een nieuw gezipt bestand aangemaakt en aan de index toegevoegd. Afhankelijk van de kracht van de server en hoe snel het achter elkaar wordt gedownload zouden er dan meerdere "reserve" bestanden beschikbaar moeten zijn. Dit zorgt er iig voor dat de gebruiker direct het bestand kan downloaden. Hoe je de zips van identifiers voorziet is dan alsnog aan jou, maar de gebruiker kan dan wel direct een bestand in handen krijgen, en op deze manier kan je het zippen makkelijker offloaden naar een andere server.

Oh, en voor het voorzien van UIDs kan je ziparchive::addfile gebruiken. Zet 1 kritiek textbestandje niet in de zip, en laat PHP via fopen en fwrite er een unieke string inzetten, en hem in de zip zetten zodra de zip aan de index wordt toegevoegd. Dat zou het dichtst bij jouw doel komen, denk ik. Alsnog kunnen mensen, als ze weten waar de string staat, hem verwijderen.

Als je een download request krijgt zou je dan de volgende dingen moeten doen:
1. Zoek op in de index welk bestand gedownload moet worden, welke gebruiker hem gaat downloaden, en de unieke string voor dat bestand. Log de unieke string en de gebruiker. Wis het bestand uit de index.
2. Geef de gebruiker het bestand.
3. Maak een nieuw bestand aan door de bronzip te kopieren, een unieke string toe te voegen aan het kritieke textbestand, en het kritieke textbestand aan de kopie van de bronzip toe te voegen. Zet hierna de naam van de nieuwe kopie en de unieke string in de index. De gebruiker hoeft hier niet op te wachten, het kan in de achtergrond gebeuren.
4. Verwijder het geserveerde bestand, nadat de gebruiker hem binnen heeft gekregen (of markeer hem voor verwijdering).

Op deze manier zou het aantal bestanden in de index niet veranderen, de gebruiker altijd een unieke string in het kritieke textbestand krijgen, en zouden er genoeg bestanden beschikbaar moeten zijn om continu nieuwe bestanden te serveren, zonder dat de gebruiker hoeft te wachten op de ziparchive::addfile, als die operatie lang duurt. Verder kan je afhankelijk van de grootte van je index weinig bestanden op je server hebben: 1x bronzip, 1x bron kritiek textbestand, en nx klaar te serveren zip (waar n het aantal bestanden in je index is).

[ Voor 57% gewijzigd door Niet Henk op 28-08-2013 13:06 ]

is het ook zwaar als je in PHP realtime 1 bestand (of een paar bestanden) uit de zip haalt, die van je watermerk voorziet, en dat ene bestand dan weer toevoegd aan de zip? Ik weet niet precies hoe de zip-functionaliteit werkt, maar op mijn pc werkt het toevoegen van 1 bestand aan een zip in ieder geval veel sneller dan het compleet opnieuw zippen van een zip...

Volgens mij is dat niet zo zwaar, en je hoeft zelfs de bestanden niet uit de zip te halen. Je kan gewoon naast de zip de bestanden die je later gaat toevoegen hebben staan, en ze pas toevoegen als het bestand geserveerd gaat worden, of als je met een index werkt als de zip klaar wordt gemaakt om te serveren.

Ik ga ervan uit dat de file die wordt aangeboden een binary is, en geen leesbare programmacode is?

Dan kun je het programma toch laten kijken naar een licence.key bestand. Als dat bestand niet wordt gevonden werk het prograsmma sowieso niet. En verder:
iedere mogelijke klant/downloader ken je een heel hoog, uniek, priemgetal toe;
in het programma (en daarom moet het een binary zijn) is een heel hoog priemgetal keihard ingecodeerd;
het product van die getallen komt in die licence.key te staan;
wanneer het programma start leest het licence.key;
het getal in licence.key wordt gedeeld door het hard-gecodeerde priemgetal. Als daar een int uitkomt was de licence4.key geldig (en start het programma op), komt daar geen int uit dan is de licence.key vervalst.

De licence.key wordt niet echt groot, enkele honderden bytes. Die kun je per download mee-zippen, maar je kunt hem ook apart meeleveren. Dat laatste heeft als voordeel dat het niets uitmaakt dat de download opnieuw wordt aangeboden, de downloader kan er toch niets mee.

Veel werk voor weinig succes

Als je met ini files werkt e.d. kun je een (of meerdere) "lege" regels toevoegen en daar met spatie + tab een "code / watermerk" inbouwen (dat kan overigens ook door aan 't eind van de regels spaties/tabs te plaatsen of te variëren tussen \r, \n en \r\n maar dat kan onder bepaalde teksteditors sneller opvallen).

Linksom of rechtsom: waterdicht krijg je 't niet.

Wat ook gedaan wordt: afhankelijk van de data kun je er unieke "records" tussen stoppen die voor de afnemer van de bestanden geen effect zullen hebben maar waar je wel bestanden aan herkent. Wij (telefonieoperator) krijgen bijvoorbeeld lijsten waarin telefoonnummers staan (tig-duizenden) die niet op straat mogen (en horen te) komen liggen; daar zitten gewoon een stuk of 5 a 10 nep-nummers tussen die voor elk van de afnemers gewoon variëren en dus een "uniek watermerk" vormen.

[ Voor 41% gewijzigd door RobIII op 29-08-2013 11:59 ]

Oh, een stukje advies als je met .ini files werkt: LET OP JE METADATA! Als je dat niet doet, kan je soms gewoon sorteren op laatst bewerkt, en het laatst bewerkte bestand zal wel het bestand met de key erin zijn. Dus je metadata manipuleren kan daar van pas komen.

RobIII schreef op donderdag 29 augustus 2013 @ 10:54:
Als je met ini files werkt e.d. kun je een (of meerdere) "lege" regels toevoegen en daar met spatie + tab een "code / watermerk" inbouwen (dat kan overigens ook door aan 't eind van de regels spaties/tabs te plaatsen of te variëren tussen \r, \n en \r\n maar dat kan onder bepaalde teksteditors sneller opvallen).

Linksom of rechtsom: waterdicht krijg je 't niet.

Wat ook gedaan wordt: afhankelijk van de data kun je er unieke "records" tussen stoppen die voor de afnemer van de bestanden geen effect zullen hebben maar waar je wel bestanden aan herkent. Wij (telefonieoperator) krijgen bijvoorbeeld lijsten waarin telefoonnummers staan (duizenden) die niet op straat mogen (en horen te) komen liggen; daar zitten gewoon een stuk of 5 a 10 nep-nummers tussen die voor elk van de afnemers gewoon variëren en dus een "uniek watermerk" vormen.

Op zich is dit wel een aardige optie als je het vertaalt naar de TS.

Voeg regels toe aan de ini-files die legitiem lijken. Terwijl ze eigenlijk geen waarde toevoegen. Gebruik deze eventueel in combinatie met de 'morse-code' van spaties en tabs om een unieke 'fingerprint' te genereren.

Dan komt men er alleen nog achter door twee downloads met elkaar te vergelijken.

TRON schreef op donderdag 29 augustus 2013 @ 11:21:
Dan komt men er alleen nog achter door twee downloads met elkaar te vergelijken.

Veel "diff'ers" negeren whitespace ook nog eens, dus met wat geluk valt 't daar ook niet (meteen) in op. Ga je (file)hashes vergelijken of wat strictere string-comparing dan val je alsnog gauw door de boot.

Maar daar moet bij gezegd: ik heb zelf dus te maken met een partij die 'watermarked' bestanden aanlevert en dag 1 dat we zo'n bestand aangeleverd kregen ontdekte ik het watermerk simpelweg door 't verschil in newlines. Alle records (héél veel) eindigden op \r\n op 10 records na, die eindigden op \n. Voila, uw watermerk is nu nutteloos.

[ Voor 35% gewijzigd door RobIII op 29-08-2013 11:59 ]