PHP·pub - Programming With Attitude - and beer

[Ernie]

Nå er det faktisk delvis nettleserenes skyld også da. Hadde den faktisk vist det 1. mellomrommet hadde man faktisk fått korrekt innrykk, dog bare med et mellomrom.

 

<?php
//Ingen innrykk
//Et innrykk (tab, men nettleser viser det som ingenting)
 //To innrykk (space  , space vises ikke)
 	//Tre innrykk (space   tab, space vises ikke og tab vises som et mellomrom)
   //Fire inntrykk (space   space  , 1. space vises ikke)
   	//Fem innrykk (space   space   tab, som over og tab vises som et mellomrom)
?>

 

I PHP-tagen er det ganske greit da Tab blir til 4 mellomrom

PHP

<?php

//Ingen innrykk

    //Et innrykk

        //To innrykk

            //Tre innrykk

                //Fire inntrykk

                    //Fem innrykk

?> 

Endret 12. august 2007 av Ernie

[Ståle]

lenge siden jeg har brukt PHP-taggen. Har de fikset spesialtegn-feilen?

 

den som gjore om ! til &0033; elns

Endret 12. august 2007 av Ståle

[Ernie]

PHP

<?php

if (!$var)

if ($var != $var)

 

// !

/* ! */

# !

?>

 

Ser sånn ut

[Ernie]

Må si jeg blir stadig mindre og mindre glad i PHP. Idag må jeg si jeg ble svært imponert over PHP. Tenkte jeg skulle skrive en fullverdig session-handler slik at $_SESSION kan brukes og at alt havner i databasen. Etter 7 timer minst 3 mer eller mindre stygge hacks samt mye banning fungerer det endelig.

 

Først og fremst kan man glemme å implementere det hele rent og pent i en klasse, spesielt hvis du har en egen database klasse. Det vil nemlige skje etter at alle objekter er slettet. Dog, manualen er jo et kjekt sted og der står det at session_write_close() er en fin ting å kjøre i destructor. Yeah right! Nå har du riktignok et objekt å jobbe i, og dermed også fungerende funksjoner, men database-klassen er selvsagt borte. Det kommer riktignok ikke av at den er slettet, men derimot at alle objekter i klassen du jobber i er borte. Hvis du derimot registerer session_write_close som en shutdown-funksjon blir dog alt mye bedre, men hvorfor i alle dager skal man være nødt til det? Dette burde da vitterlig PHP gjøre i utgangspunktet?

 

Vel, vel, neste problem er selvsagt at det ikke finnes noen funksjon for å opprette en session siden PHP-utviklerene har vært meget korttenkte og bare har read og write. Destroy skal vi selvsagt ha, men ikke create. Med en database må man altså først forsøke å kjøre en update/insert, og feiler dette gjøre det motsatte. Så godt dokumentert som hele prosessen er veit jeg ærligtalt ikke om dette bør gjøres i både read og write, men bare i read ser ut til å fungere.

 

Så var det siste lille hack. Av div. årsaker har jeg en datastruktur som krever at jeg oppdaterer raden ved innlogging. Samtidig veit vi at sessionid bør regenereres ved endring i rettigheter. Klok som jeg er kjører jeg selvsagt session_regenerate_id ved innlogging. Det går rett i dass. Først og fremst blir ikke den gamle session slettet med mindre man spesifikt ber om det, og parameteren ble ikke lagt til før PHP5.1.0. Dette er etter min mening svært kritikkverdig sikkerhet. Hva i alle dager er poenget med å regenerere id hvis den gamle session fortsatt eksisterer? Er man "smart" nok så ligger jo koblingen mot bruker i $_SESSION hvilket medfører av at på tross av forsøk på å eliminere session fixation alikevel kan sitte igjen med å gi angriper full mulighet til å gjennomføre dette. Isåfall får faktisk angriper en helt egen privat session! Vel, vel, det er ikke noe problem for min del da jeg kan sette parameteren. Det som derimot er litt verre er at session ikke eksisterer i databasen når jeg har tenkt å oppdaterer rettighetene. Jøsses tenker jeg, hva skjer? Jo, det som skjer er korrekt nok at session blir slettet ved session_regenerate_id, derimot blir den ikke lagt til før scriptet er ferdigkjørt. Fleksibiliteten må påståes å være sjokkerende dårlig. Greit nok, man bruker file i utgangspunktet og i utgangspunktet er det ikke noe annet som skal lagres enn innholdet i $_SESSION, men hva hvis noen tenker litt anderledes? Hva hvis noen faktisk vil legge inn obligatoriske data utenfor session? Jaja, hente ut nåværende session før session_regenerate_id og insert på ny etterpå. Enkelt skal det dog ikke være. Debug av hele herket er selvsagt ikke enkelt. Det står selvsagt ikke noe sted hva som faktisk skjer når man kjører session_regenerate_id og da blir det prøv og feil i tillegg til å logge til fil.

 

Tilbake sitter jeg igjen med følelsen av at det ikke er meningen å endre på session-handleren. Det hele virker mer eller mindre amatørmessig og bundet opp mot file samt automatikken det gir. Av og til lurere jeg virkelig på hvorfor jeg faktisk benytter PHP.

[jeg_lyver_mye]

Har prøvd meg på å lage en egen sessions-handler selv, ga opp. Fungerte lokalt men funka slettes ikke andre steder. Manualen er helt ubruklig her.

[Ernie]

Ja, eneste jeg finner i manualen som faktisk stemmer er at alle funksjoner skal returnere true/false unntatt read som alltid skal returnere en streng. Resten er ren gjetting. Står ikke engang i klartekst hva som skal gjøres utover at man har et kodeeksempel.

[jorgis]

At PHP-manualen har store hull er et faktum, spesielt på litt tyngre ting enn bare funksjonsreferanser. Her en dag skulle jeg drive litt research av opplasting av store filer, og lurte på om PHP lagret hele filen i minnet før den ble dumpet til /tmp, eller om den hadde den bare i en begrenset minnebuffer før den skrev den til disk, og manualen nevnte det ikke noen steder. Eneste jeg fant, var to korte kommentarer i manualsiden, og de sa to nøyaktig motsatte ting...

 

Skulle gjerne hatt en mer presis manual, men det er svært få som melder seg frivillig til noe så kjedelig som å skrive dokumentasjon, og det ville blitt sykt dyrt å betale for dokumentasjonsforfattere. :/

[Ernie]

Vel, dokumentasjon er en del av programmeringsjobben. Det er synd man rett og slett ikke pålegger utviklerene å skrive litt dokumentasjon nå og da. Det er jo trossalt de som kjenner til hvordan PHP fungerer. På den andre siden hadde det sikkert blitt litt frafall, men igjen det er jo en del av jobben

Endret 15. august 2007 av Ernie

[jorgis]

Vel, dokumentasjon er en del av programmeringsjobben. Det er synd man rett og slett ikke pålegger utviklerene å skrive litt dokumentasjon nå og da. Det er jo trossalt de som kjenner til hvordan PHP fungerer. På den andre siden hadde det sikkert blitt litt frafall, men igjen det er jo en del av jobben

9288574[/snapback]

 

Det var en diskusjon på p.internals-mailinglisten for noen uker tilbake om at det skulle bli oblig. å legge ved informasjon i commit-meldinger hvis endringen krevde tilsvarende endringer i dokumentasjonen. De er nok veldig klar over at dokumentasjonen ikke er god nok, så de jobber med saken.

Endret 15. august 2007 av jorgis

[jeg_lyver_mye]

Tråden " PHP kode som andre kanskje kan bruke" skulle nesten ha vært rydda opp. Også skulle vi lagd en ny en, for bare klasser og funksjoner.

[Gjest Slettet+142]

Ikke noe dårlig idé det

Du kan jo starte tråden, så kan sikkert en moderator fikse sticky..

[dabear]

Da må vi få litt standard på den, og unngå

<?php

$number = $_GET['num'];
$sql = 'SELECT * FROM foo WHERE baz=' . $number
//..
?>

..og slike usikre koder.

[Gjest Slettet+142]

- Skrive noen få "regler" i førstepost da,

hvor det bl.a kan stå "Koden skal være sikker. Usikre koder vil bli rapportert til moderator og evt. bli sikret av en annen."?

[jeg_lyver_mye]

Ja.

Hvordan skal vi gjøre dette da? Skal vi ha samle en gjeng som godtar kode? Hvis den er godtatt så legger vi det samla i første post... el.?

 

Edit: Annen ting som slår meg, den skal være DOKUMENTERT! Slik at folk kan bruke den. Gidder ikke folk å dokumentere, så ikke post den. Tror det med å legge det i førstepost er litt dumt. Folk må få kunne oppdatere klassene sine ol.

Endret 16. august 2007 av nevoscript

[Gjest Slettet+142]

Jau.

Kan ha en gjeng som ser gjennom kode, men ikke førstepost, nei.

Er ikke koden godtatt av mer enn 1 person av "gjengen" , kan en PM sendes til poster. 2 dager etter og ingen tilfredsstillelse i koden; Rapporter?

[jeg_lyver_mye]

Høres ut som en fin ide! Hvis moderator godtar den dealen da.

Flere som syntes dette høres ut som en fin ide?

Endret 16. august 2007 av nevoscript

[jorgis]

Husk en liten notis som gjør det klart at kode som deles i "PHP-kode som andre kan bruke"-tråden må ha en lisens som tillater at koden kan brukes, altså enten public domain eller en annen OSI-godkjent lisens. Hvis ikke lisens er oppgitt, kan lisensen defaulte til GPL?

[PT]

Forumreglene sier vel at HW.no har en evigvarende rett til *noe* som gjelder for alle innlegg som skrives på forumet, så det kan sikkert være greit å få det avklart med styret først.

[jorgis]

Forumreglene sier vel at HW.no har en evigvarende rett til *noe* som gjelder for alle innlegg som skrives på forumet, så det kan sikkert være greit å få det avklart med styret først.

9297566[/snapback]

 

IANAL, men juridisk sett har vel strengt tatt ikke HW.no rett til å kreve copyright på alt som går gjennom forumet, og forumreglene har ingen presedens over lovverket. Om jeg poster kode som jeg har skrevet, og som jeg har underlagt GPL-lisensen har de ingen muligheter til å kalle den for HW.nos eiendom eller si at den er under noen annen lisens enn den jeg har satt, uansett hva som står i forumregler eller ikke.

[rødøye]

Meget mulig du har rett, men vil du ikke ver å poste på forumet akseptere reglene, og dermed gi fra deg opphavsretten? Ikke at jeg vil at det skal være sånn, men kan noen med større innsikt enn meg uttale seg?