[php] opslaan van grote gegevens

[Dennis]

Hoi,

Voor een beveiligingssysteem heb ik een functie die gecodeerde tekst retourneert.

Deze tekst ziet er ongeveer zo uit:

code:

.œdK?^6rmg.Me1yj1\' Õ=.h>.~0.6J9~`.?1q
:+j2.35.oUJ=pc7v.%c.rfKtwy=K#.afw w%|.w4IscY°/.q|Fnf*.:.pnË$`b%0þ/.1|S3...h.k].1.ô..3..iZÉC#7=Ý.5.Au Kxw..$KM1O_>N 3XÑKaZ.?;$ÿi;c..8Ö\0|h\\.=.5NBj9ê.v(á1RkÃS}[<UN|ŜQ%y^œ\\u?^..lÛ\\_=..x.02.),
-
J.\0j9  u6xrhqiv{1z6~Èw.,.¿#+=Z%e8!}=Qx./©-\'#^}`q.a5*w6.^ä},.{.o.Lkh.bizipc6c.k.m|c7)Jed,\\b&43>A=.:Z2H<)686cl5%S9><Ahh.q.RMZS[)~.%6R~.\\$&R.\"W.._Qz.
X7jP63S!i   Fh_.iU..Z¿.1=

De tekst komt voort uit een geserializede array. Deze is trouwens al ge-addslashed.

Nu zit ik met hoe ik deze tekst op ga slaan. Database is uitgesloten, omdat dat gewoon te onhandig is. Mogelijkheden zijn includes en dan via $var = "<HIER DE INHOUD>";, maar dit levert problemen op waardoor ik alles tig keer moet addslashen, base64_encoden, serializen etc etc.

Een andere mogelijkheid is opslaan in een gewoon los bestand, maar dan moet ik weer met fopen gaan werken en dat doe ik liever niet, maar als het niet anders kan .

Iemand (betere) ideeën/oplossingen

[Flake]

Ik denk dat je alle mogelijkheden uitsluit

[Soultaker]

Een belangrijk uitgangspunt is het volgende: kan het voorkomen dat je coderingsfunctie uit een gewone string (die dus geen nul-karakters bevat) nul-karakters genereren? Zo ja, dan moet je de boel hoe dan ook coderen of in een binair formaat opslaan (ie. in je PHP code is dan geen optie).

Zo niet, dan kan het wellicht zo (ik weet niet hoe die constructie officieel heet):

code:

 $var =   $koptekst  = <<< EINDE
DATA DATA DATA
EINDE;

Als het goed is worden de newlines na en voor de eerste en laatste keer EINDE automatisch overgeslagen. Verder gaat dit natuurlijk alleen goed als de tekst newline-EINDE niet in je gecodeerde string voorkomt, maar wat is de kans. Ook moet je dit natuurlijk niet met een teksteditor gaan bewerken. Daarbij worden \r\n pairs WAARSCHIJNLIJK omgezet naar \n karakters (ik weet niet precies wat PHP's policy daarbij is).

Al met al geen nette methode dus. Ik zou je dus aanraden de boel te addslashen of in een apart bestand te zetten. Daar wordt 't parsen van je script echt niet zoveel trager op. Bovendien is een apart bestand beter te beveiligen dan de inhoud van een PHP script.

[Soultaker]

offtopic:

Omtrend de ongepaste inhoud van deze signiature is deze verwijderd. Gelieve dit in het vervolg niet wederom te laten voorkomen.

Nu wordt ik benieuwd, wat had je er precies in staan, SONiCB00M? (Jammer van de spelfouten trouwens.)

[Dennis]

Soultaker:
Nu wordt ik benieuwd, wat had je er precies in staan, SONiCB00M? (Jammer van de spelfouten trouwens.)

Dankjewel voor je vorige post. Ik kreeg ook al van iemand te horen dat ik het binair moet opslaan, nulkarakters die niet voorkomen zijn er niet. Dan wordt het dus toch met fopen enzo gaan werken .

En over die sig van degene die je quotte, die Dexterslab is iemand die je moet kennen, en dan weet je hoever het is

[Soultaker]

Op zaterdag 01 juni 2002 11:52 schreef ddc het volgende:
Dan wordt het dus toch met fopen enzo gaan werken .

Wat is precies het bezwaar daarbij? Performance kan 't niet zijn, want je wil 'm wel includen en een include is gegarandeerd 'duurder' dan een binair bestand in 'n variabele lezen. Daarbij is een include ook niet echt belachelijk veel makkelijker te coden; ok, het scheelt twee statements, maar het blijft toch wel beperkt tot een halve regel code.

[Dennis]

Ging mij vooral om het feit dat je dan met bestandspaden moet werken ipv url's .

[Verwijderd]

tjah, met wat je allemaal uitsluit zou ik toch maar met bestanden gaan werken. Ik zou toch de voorkeur geven voor een database, gewoon makkelijk te beheren... wat bind je daar onhandig aan?
zet wel die bestanden buiten de web-tree, scheelt meteen ook weer heel veel veiligheid...

[dusty]

Op zaterdag 01 juni 2002 12:16 schreef ddc het volgende:
Ging mij vooral om het feit dat je dan met bestandspaden moet werken ipv url's .

Volgens mij heb jij nog een lesje PHP nodig. Of je moet gewoon beter de handleiding lezen

[Dennis]

dusty:
Volgens mij heb jij nog een lesje PHP nodig. Of je moet gewoon beter de handleiding lezen

Dat kan nooit kwaad denk ik.
Maar als jij het eerste gratis aanbiedt wil ik daar best gebruik van maken

[Dennis]

jurriebur:
tjah, met wat je allemaal uitsluit zou ik toch maar met bestanden gaan werken. Ik zou toch de voorkeur geven voor een database, gewoon makkelijk te beheren... wat bind je daar onhandig aan?
zet wel die bestanden buiten de web-tree, scheelt meteen ook weer heel veel veiligheid...

Database is een probleem omdat ik daar niet rechtstreeks bij kan vanaf een andere site.

[dusty]

Op zaterdag 01 juni 2002 12:24 schreef ddc het volgende:
[..]
Dat kan nooit kwaad denk ik.
Maar als jij het eerste gratis aanbiedt wil ik daar best gebruik van maken

De eerste les bestaat uit lees de manual nog eens door, voornamelijk de fopen() functie

[Verwijderd]

Op zaterdag 01 juni 2002 12:25 schreef ddc het volgende:

[..]

Database is een probleem omdat ik daar niet rechtstreeks bij kan vanaf een andere site.

dan is het opslaan in een bestand denk ik de enige optie die nog een beetje handig is

[ACM]

Op zaterdag 01 juni 2002 12:25 schreef dusty het volgende:
De eerste les bestaat uit lees de manual nog eens door, voornamelijk de fopen() functie

Zou include niet ook fopen() gebruiken? (of iig de achterliggende file-open-structuur met daarna vast de eval() call)

[Dennis]

Goed, ik ben nu zover dat ie alles opslaat in een bestand (en het ook weer uitleest - duh), maar het lijkt haast wel of er onderweg wat met mn data gebeurd

Iig laat ik php met een bepaalde functie het bestand schrijven, zodat ik iig weet dat dat binarysafe gaat.

Ook het uitlezen lukt prima, maar zodra ik dan weer 1001 terugbewerkingen heb gedaan en de uiteindelijke decrypt functie uit wil voeren krijg ik dus een php-error.

En die functie is goed, want ik heb als test een encrypt gemaakt en gelijk die variabele weer gedecrypt en dat loopt gesmeerd.

Dit is wat ik in het bestand stop:

code:

õ0)``BSfI4aWK6
<49w®=1 l€6zak6}?2f27h;'ÃK4sh8asmg$ÙÙÝ?v]!2kjéiºÎ7;ép+\]h%8lÂN+yh$zv,m~Ý.žÈ7mŸ% î;sRYg}6Mc=Ŝ/,ezC;$h%h)9øŽ/w

Wk0nõD6ED<GO3`@YND)9e0HdkNkpI{|HHWHQZqveP2I
=c®.g aUVJ3œ®

W
nõ_-6\3xXf3=[~<]A_`!W]%$4 +Jtbl"u u)`s?&L0ß

En dit krijg ik eruit:

code:

õ0)``BSfI4aWK6
<49w®=1 l€6zak6}?2f27h;'ÃK4sh8asmg$ÙÙÝ?v]!2kjéiºÎ7;ép+\]h%8lÂN+yh$zv,m~Ý.žÈ7mŸ% î;sRYg}6Mc=Ŝ/,ezC;$h%h)9øŽ/w

Wk0nõD6ED<GO3`@YND)9e0HdkNkpI{|HHWHQZqveP2I
=c®.g aUVJ3œ®

W
nõ_-6\3xXf3=[~<]A_`!W]%$4 +Jtbl"u u)`s?&L0ß

Ik zie geen verschillen .
Dit is dus NA dat ik alle andere bewerkingen behalve de main decrypt heb gedaan.

[ACM]

Kan best zijn dat het in tekstuele vorm niet verschilt, dat is een nadeel van binaire strings

Overigens is met addslashes() de 0-string geescaped en kan je het evt ook non-binair wegschrijven (niet dat er op unix verschil in zit )
Lees je het ook binairy-safe in?

[Dennis]

Ben er al uit nu.
Objectfuncties moet je wel aanroepen via het object

[Flake]

Op zaterdag 01 juni 2002 11:46 schreef Soultaker het volgende:
offtopic:
[..]

Nu wordt ik benieuwd, wat had je er precies in staan, SONiCB00M? (Jammer van de spelfouten trouwens.)

[OT]
"DextersLab is een prutser"

[RSD]

scrhijf een functie die je gecodeerde text omvormt tot een lap text die je wel makkelijk in een database kan opslaan. Dan hoef je ook niet teveel te escapen en dergelijke.. of zet het om naar '0101010101010111100' etc.. het is maar een ideetje!

Ben best benieuwd aan watvoor projectje je bezig bent!

[drm]

RSD:
scrhijf een functie die je gecodeerde text omvormt tot een lap text die je wel makkelijk in een database kan opslaan.

het probleem was de database zelf, niet het opslaan van data erin

of zet het om naar '0101010101010111100' etc.. het is maar een ideetje!

Da's een slecht ideetje. Je krijgt dan namelijk 16x zoveel bytes dan je feitelijk nodig hebt, en da's om verschillende redenen.... "niet handig"

Soultaker:
(ik weet niet hoe die constructie officieel heet):

code:

 $var =   $koptekst  = <<< EINDE
DATA DATA DATA
EINDE;

Da's een implementatie van de zgn. "heredoc-syntax". Een brakke, overigens

[Helox-in-a-box]

how about serverside sessions? hoef je de data niet steeds zelf weg te schrijven en te openen zoals bij bestanden, er wort geen data bij de client opgeslagen zoals bij cookies en tis simpeler omdat je geen zin hebt om met databases te prutsen

[Dennis]

Helox-in-a-box:
how about serverside sessions? hoef je de data niet steeds zelf weg te schrijven en te openen zoals bij bestanden, er wort geen data bij de client opgeslagen zoals bij cookies en tis simpeler omdat je geen zin hebt om met databases te prutsen

Heb ik ooit gezegd dat het clientside opgeslagen moest worden dan

RSD:
scrhijf een functie die je gecodeerde text omvormt tot een lap text die je wel makkelijk in een database kan opslaan. Dan hoef je ook niet teveel te escapen en dergelijke.. of zet het om naar '0101010101010111100' etc.. het is maar een ideetje!

Ben best benieuwd aan watvoor projectje je bezig bent!

Hier kan je goed base64_encode gebruiken, wat ik dus ook heb gedaan.

Maargoed, zoals ik al zei: ik ben er al uit .