[PHP/MySQL] Gegenereerde PDF in database opslaan

[Verwijderd]

Ik heb een pdf, gegenereerd dmv phppdflib.
Dit werkt allemaal goed.

Er komt een pdf-file uit, welke ik op het scherm kan laten zien met:

PHP:

echo $temp;

of op de hd kan opslaan met

PHP:

$myFile = "test.pdf";
$fh = fopen($myFile, 'w') or die("can't open file");
fwrite($fh, $temp);
fclose($fh);

Nu wil ik hem echter in een mysql-database opslaan, in een LONGBLOB veld.
Nu moet ik dus die $temp omzetten naar een formaat voor in een BLOB-veld, maar hoe doe ik dat?

op een of andere manier $temp converteren naar een binary-file en dan inserten in de database?

[ Voor 13% gewijzigd door Verwijderd op 06-04-2007 12:16 ]

[Verwijderd]

waarom wil je het bestand in de database zetten en niet een link naar het bestand?

Bestanden in de database zetten is niet altijd even verstandig

[Wacky]

Volgens mij kan je $temp gewoon via een INSERT query in je database opslaan hoor, heb je dit al geprobeerd?

[Verwijderd]

Omdat bepaalde accounts er wel bij moeten kunnen en anderen niet.
Als ik ze gewoon als files opsla, dan kan iedereen erbij toch.
Als ik ze buiten mijn wwwRoot opsla, dan kan niemand erbij.

nu dacht ik ik zet ze in een database met het accountID erbij, dan kan alleen die account erbij dmv een query

[Ramon]

waarom zou je dat willen?

maak een map op de server en sla de pdf op met een nummer in de naam en maak in de database een id veld met dat nummer en eventuele andere gegevens die je wilt opslaan en je hebt hetzelfde idee en nog sneller ook.

[Verwijderd]

Wacky schreef op vrijdag 06 april 2007 @ 12:17:
Volgens mij kan je $temp gewoon via een INSERT query in je database opslaan hoor, heb je dit al geprobeerd?

Dit lukt niet, dan krijg ik een foutmelding van adobe, The file is damaged and could not be repaired als ik de query uitvoer.

PHP:

$query = "insert into statistieken values ($stats->AccountID, (date('W')-1), date('Y'), $temp)";
queryUitvoeren($query);

[Verwijderd]

Ramon de Jesus schreef op vrijdag 06 april 2007 @ 12:19:
waarom zou je dat willen?

maak een map op de server en sla de pdf op met een nummer in de naam en maak in de database een id veld met dat nummer en eventuele andere gegevens die je wilt opslaan en je hebt hetzelfde idee en nog sneller ook.

Als iemand anders dan alle nummers gaat proberen, dan komt hij er toch ook bij, of zie ik dat nu verkeerd.

Map buiten wwwRoot, dan kan geen enkele account er toch bij

[ Voor 6% gewijzigd door Verwijderd op 06-04-2007 12:21 ]

[consolefreak]

als je ze:
- buiten de wwwroot zet
- php script maakt dat je database checkt en indien gebruiker rechten heeft: bestand uitlezen en doorsturen naar de gebruiker.

is dit geen goed plan?

[Zsub]

Kan je niet iets met chmod/chown doen...?

[Peedy]

Verwijderd schreef op vrijdag 06 april 2007 @ 12:21:
[...]


Als iemand anders dan alle nummers gaat proberen, dan komt hij er toch ook bij, of zie ik dat nu verkeerd.

Map buiten wwwRoot, dan kan geen enkele account er toch bij

Als je gewoon een random id genereerd van 8/9/10 karakters, dit id koppelt aan een user dmv een database, dan kan je bepaalde users dit id laten zien en andere users niet. Als je dan directory listing voor de directory waarin de pdfjes zitten uitschakelt wordt het voor die andere users erg moeilijk om de andere pdfjes te vinden.

Gewoon met PHP een id genereren:

code:

rand(111111111,999999999);

[ Voor 5% gewijzigd door Peedy op 06-04-2007 12:26 ]

[P.O. Box]

Je moet de PDF's dan buiten de www-root zetten en een php-file maken in de www-root die je aanroept met een id uit de database.... in dit databasrecord staat dan de locatie van de PDF buiten de wwwroot.... je doet wat rechtencontroles en dergelijke en als de gebruiker rechten heeft, dan open je het PDF bestand met bijv. fopen() en output je de inhoud naar het scherm.... de gebruiker ziet dan in zijn url: "http://jouwdomein/showpdf.php?id=12" ...


edit: wat consolefreak zegt dus

[ Voor 3% gewijzigd door P.O. Box op 06-04-2007 12:27 ]

[ADT_Phantom]

Verwijderd schreef op vrijdag 06 april 2007 @ 12:20:
[...]


Dit lukt niet, dan krijg ik een foutmelding van adobe, The file is damaged and could not be repaired als ik de query uitvoer.

PHP:

$query = "insert into statistieken values ($stats->AccountID, (date('W')-1), date('Y'), $temp)";
queryUitvoeren($query);

probeer het eens op deze manier:

PHP:

$query = "insert into statistieken values ($stats->AccountID, (date('W')-1), date('Y'), '".addslashes($temp)."')";
queryUitvoeren($query);

dus nu met quotjes erom en de functie addslashes.

[ Voor 4% gewijzigd door ADT_Phantom op 06-04-2007 12:33 ]

[GlowMouse]

ADT_Phantom schreef op vrijdag 06 april 2007 @ 12:31:
[...]

PHP:

$query = "insert into statistieken values ($stats->AccountID, (date('W')-1), date('Y'), '".addslashes($temp)."')";
queryUitvoeren($query);

dus nu met quotjes erom en de functie addslashes.

Quotes voeg je toe met mysql_real_escape_string; addslashes is een nutteloze functie die je niet dient te gebruiken.

Als je gewoon een random id genereerd van 8/9/10 karakters, dit id koppelt aan een user dmv een database, dan kan je bepaalde users dit id laten zien en andere users niet.

Tot je een keer een dubbele id krijgt. Waarom zou je, als je toch een database gebruikt, niet de database een nieuwe id laten genereren via een auto_increment veld?

[Verwijderd]

Ga het even proberen met die andere functie, en anders zet ik ze buiten de wwwRoot en dan via php-script aanroepen. in ieder geval bedankt voor de reacties.

Bij die andere quey krijg ik een andere foutmelding van adobe.

File does not begin with '%pdf'

[ Voor 24% gewijzigd door Verwijderd op 06-04-2007 13:14 ]

[Janoz]

Er zijn hele goede redenen om een bestand wel in de DB te zetten. Er zijn ook erg slecht onderbouwde redenen om een bestand maar op de schijf op te slaan. Hierover zijn echter al meerdere discussies gevoerd. (Ikzelf ben meer voor het in de DB kamp, om toch maar even wat tegengewicht te geven tegen verschillende andere posters hier).

Gebruik gewoon de mysql_real_escape functie. Ga asjeblieft geen random id's genereren. Dat is een schijnveiligheid die je alleen maar extra werk op de hals haalt.

[Verwijderd]

met die schijnveiligheid ben ik het inderdaad eens, maar buiten de wwwRoot opslaan, dan heb je ook geen problemen meer met de maximale size van een blob, ik zal eens gaan kijken naar die mysql_real_escape functie.

[Verwijderd]

Pasgeleden met een zelfde situatie gezeten. Ik heb het alsvolgt opgelost:

Gebruiker upload bestand

1. Systeem slaat naam van het bestand op, evt los het bestandstype
2. Systeem slaat het bestand op het bestandssysteem op, met als naam de ID van de kolom uit de DB. Het bestand kan in een www (sub) dir opgeslagen worden, en dan beveiligd met een .htaccess om directe HTTP requests op het bestand te voorkomen, of het kan ergens buiten de www dir opgeslagen worden

Als het bestand aangevraagd word (kan zijn per id, of per originele bestandsnaam):

1. Systeem opent het bestand van het bestandssysteem
2. Systeem schrijft HTTP headers die het bestand het orginele bestandsnaam geven (uit de DB). De gebruiker heeft geen idee hoe het intern werkt, en je zit vanwege de ID's ook niet met bestandsnamen die dubbel kunnen zijn (bv 2 keer foo.pdf oid)

[Peedy]

Janoz schreef op vrijdag 06 april 2007 @ 13:22:
Er zijn hele goede redenen om een bestand wel in de DB te zetten. Er zijn ook erg slecht onderbouwde redenen om een bestand maar op de schijf op te slaan. Hierover zijn echter al meerdere discussies gevoerd. (Ikzelf ben meer voor het in de DB kamp, om toch maar even wat tegengewicht te geven tegen verschillende andere posters hier).

Gebruik gewoon de mysql_real_escape functie. Ga asjeblieft geen random id's genereren. Dat is een schijnveiligheid die je alleen maar extra werk op de hals haalt.

Bedoel je met 'schijnveiligheid' het feit dat de bestanden evt. nog wel te benaderen zijn als je toevalligerwijs de bestandsnaam, welke een random id is, raad? Want ik pas random id's + database toe op een paar sites, maar daar zijn die files geen supergeheime bestanden ofzo.

[xces]

@Janoz, zou jij kort de voor en nadelen kunnen noemen? Voor een administratiegedeelte heb ik er zelf voor gekozen om de PDFs te laten genereren zodra ze gedownload worden. (a.d.h.v. factuurregels die overigens wel in de db staan).

[Janoz]

Het laten genereren lijkt mij inderdaad nog een veel betere oplossing. Het enige nadeel daarvan is de mogelijke serverload, maar dat is bij de door jou genoemde applicatie waarschijnlijk geen issue.

Qua voor en nadelen mbt je binaire content opslaan in je DB kun je wel veel in de search vinden (er zijn al eerder discussies over geweest). In het kort komt eht er op neer dat het opslaan op de schijf vaak efficienter is en het opslaan in de DB veiliger (mbt security, maar ook qua integriteit van je data).

[Verwijderd]

Joris,

Ik ben bezig met hetzelfde.

Zie jij voordelen aan phppdflib ten opzichte van andere manieren ?

Misschien dat je wat extra informatie zou willen delen ? Ik ben al een eind, de PDF's zijn niet echt een probleem, er zijn alleen vele wegen die naar Rome leiden.