Onderwerp: php code controleren of het goed is ja/ nee

Oorspronkelijk geplaatst door marsipulami

Wil ik je er toch even op wijzen dat TS onder andere aan de hand van reacties hier bepaalt of je wel mag scripten voor TS of niet. Dingen vergeten kan, maar om dan zulke code hier te plaatsen ..... ook al is de code oud.

Er werd gevraagd om een contact form, denkende aan de functies daarvan heeft dit script ongeveer dezelfde eisen/functies. Een slordig foutje maar zoals je kunt zien zijn de andere $_POST variabelen wel gewoon beveiligd, ieder mens maakt wel eens fouten/vergeet wel eens wat ;-)!

Over het gebruik van de { } tags is inderdaad een persoonlijke voorkeur hoe je die het liefst gebruikt.

Oorspronkelijk geplaatst door systemdeveloper

Mja, ook voor naamgeving heb je standaarden en een 'get' funktie is toch wel bedoeld om ook een returnwaarde te leveren. De programmeur die jouw werk moet overnemen als je ziek wordt oid moet het ook snel kunnen oppakken.

Over die SEO... als jij (met echo) 'blabla.php' in je webpage output, dan wil ik nog zien hoe je die met mod_rewrite gaat omzetten naar seo vriendelijke urls...
Andersom lijkt me redelijk standaard... maar met mod_rewrite een 'blabla.php' omzetten naar bv "/blabla/" is pretty pointless, aangezien je hem dan met mod_rewrite weer terug moet zetten naar 'blabla.php' en dus een loop zou krijgen.

Over die functies heb je misschien gelijk, maar ook al zou de functie 'DisplayLinkpartners' zijn dan zou de programmeur die mijn werk over moet nemen toch eerst de functienaam moeten opzoeken, maar goed i get the point.

Overigens;

Code:

<a target="_blank" href="'. $result['link'] .'" title="'. $result['naam'] .'">'. $result['naam'] .'</a>

Het eerste script heeft betrekking tot linkpartners, deze lijken mij niet SEO geoptimaliseerd te worden.

Oorspronkelijk geplaatst door Mikey

Ipv delen op dezelfde lijn, via deze weg kun je heel snel zien waar je een } vergeten zou kunnen zijn. Het laat het verhaal wat overzichtelijker. Maar dat is een persoonlijk puntje

Heeft ook te maken waar je mee begonnen bent, JAVA standaard is dat je wel op 1 lijn programmeert. dus bijv:

Code:

public void getMethod(){
 // doe iets

}

Dan neem je dat ook snel mee naar je andere talen
Maar das een beetje OFFTOPIC

Het stukje code wat je laat zien is veilig. De vraag is of het dat nog steeds is als er met variabelen wordt gewerkt. De 1 in de SQL string is immers een vaste waarde.

Oorspronkelijk geplaatst door HPsurfer

Het stukje code wat je laat zien is veilig. De vraag is of het dat nog steeds is als er met variabelen wordt gewerkt. De 1 in de SQL string is immers een vaste waarde.

Leg eens uit hoe je de onbeveiligde $_GET in de SQL query veilig kan noemen

Oorspronkelijk geplaatst door HPsurfer

Het stukje code wat je laat zien is veilig. De vraag is of het dat nog steeds is als er met variabelen wordt gewerkt. De 1 in de SQL string is immers een vaste waarde.

Altijd $_GET en $_POST door mysql_real_escape_string halen

Dat $_GET, $_POST, $_COOKIE (en ook $_SESSION) variabelen (denk aan GPC) door een mysql_real_escape_string() gehaald moeten worden was voor mij bij mijn eerste PHP tutorial die ik las al duidelijk, ik ben het hier gewoon vergeten, anders had ik ook geen escape strings gebruikt op de POST variabelen ;-)

Dank jullie wel voor de reacties. Had niet gedacht dat dit zo snel zo veel reacties zou gaan opleveren. Ben eventjes een uurtje weg geweest en zeer veel reacties. Zal het allemaal op mijn gemak eventjes doornemen.

Dat is wel wat lastig voor mij aangezien ik er zelf de ballen verstand van heb.

Oorspronkelijk geplaatst door Robin L

Dat $_GET, $_POST, $_COOKIE (en ook $_SESSION) variabelen (denk aan GPC) door een mysql_real_escape_string() gehaald moeten worden was voor mij bij mijn eerste PHP tutorial die ik las al duidelijk, ik ben het hier gewoon vergeten, anders had ik ook geen escape strings gebruikt op de POST variabelen ;-)

Vergeten of niet, als je zoiets vergeet bij een klant dan lever je imho een slecht script af. Er staan er behoorlijk wat in.

Oorspronkelijk geplaatst door wilma

Dank jullie wel voor de reacties. Had niet gedacht dat dit zo snel zo veel reacties zou gaan opleveren. Ben eventjes een uurtje weg geweest en zeer veel reacties. Zal het allemaal op mijn gemak eventjes doornemen.

Dat is wel wat lastig voor mij aangezien ik er zelf de ballen verstand van heb.

Post gewoon hier een aantal stukjes php en wij checken het wel. WHT is uiteindelijk om elkaar te helpen. Dit ziet er redelijk simpel uit voor 5 minuten werk

Je moet ze niet alleen door mysql_real_escape_string halen maar ook controleren of ze wel het juiste datatype zijn en meer van dat soort fratsen.

Dit stukje code gebruikt een string als boolean, dat zou standaard al een onvoldoende moeten opleveren.
Ik doe niet zo veel php maar volgens mij wordt de query nu tweemaal uitgevoerd, eerst om te kijken hoeveel rijen het oplevert en daarna om de data op te halen, andersom zou logischer zijn, dat je het aantal rijen uit $result haalt.
Verschillende talen in je database ontwerp gebruiken lijkt mij ook niet echt een pluspunt.
Verder is het niet logisch dat de methode GetHuppeldepup heet en vervolgens is er geen returnwaarde maar wordt er wat naar scherm geprint. List... of Display... zou een stuk logischer zijn.

Oorspronkelijk geplaatst door Robin L

Dat $_GET, $_POST, $_COOKIE (en ook $_SESSION) variabelen (denk aan GPC) door een mysql_real_escape_string() gehaald moeten worden was voor mij bij mijn eerste PHP tutorial die ik las al duidelijk, ik ben het hier gewoon vergeten, anders had ik ook geen escape strings gebruikt op de POST variabelen ;-)

Wat we wel eens doen bij oudere code waar problemen mee zijn te checken of post en get bestaan, zoja loopen erdoorheen en de betreffende checks eroverheen. Niet de meest mooie oplossing maar beter dan weken gaan graven in andermans werk

Verder een klein ding als het toch mooi wilt maken, functienamen niet beginnen met hoofdletters : getList ipv GetList. Maar ook hier vooral een persoonlijke smaak wat je geleerd hebt of overgenomen

Ben ik dan nog de enige die pro scheiding van data en opmaak is?
Bij get functies zal er nooit output richting client/scherm zijn. En bij display functies zal er nooit een stukje data berekend worden.

Of als je het netjes wilt, voor de output iets van een template engine gebruiken, waardoor opmaak en data(verwerking) geheel te scheiden is.

Maar ook dit zijn weer persoonlijke voorkeuren..

Oorspronkelijk geplaatst door lmp

Ben ik dan nog de enige die pro scheiding van data en opmaak is?
Bij get functies zal er nooit output richting client/scherm zijn. En bij display functies zal er nooit een stukje data berekend worden.

Daar wordt al genoeg over genoemd

Oorspronkelijk geplaatst door lmp

Of als je het netjes wilt, voor de output iets van een template engine gebruiken, waardoor opmaak en data(verwerking) geheel te scheiden is.

Wanneer je weet dat er maar 1 mogelijke layout overheen komt lijkt me dat niet echt zinnig. Ik ben er trouwens wel voorstander van, MVC en dergelijke. Toch blijft die toepassing erg lastig te handhaven in een php,javascript,html omgeving(lees: AJAX)

Oorspronkelijk geplaatst door marsipulami

Wanneer je weet dat er maar 1 mogelijke layout overheen komt lijkt me dat niet echt zinnig. Ik ben er trouwens wel voorstander van, MVC en dergelijke. Toch blijft die toepassing erg lastig te handhaven in een php,javascript,html omgeving(lees: AJAX)

Je kan met smarty en xajax zalige combinaties maken waarbij je zelfs afhankelijk van de rechten van de user(s) kan bepalen welke switches wel en niet geladen worden. En hiermee met wat extra's zelfs de functionaliteit compleet opbouwen aan de hand van de betreffende rechten.

Oorspronkelijk geplaatst door marsipulami

Daar wordt al genoeg over genoemd
Wanneer je weet dat er maar 1 mogelijke layout overheen komt lijkt me dat niet echt zinnig. Ik ben er trouwens wel voorstander van, MVC en dergelijke. Toch blijft die toepassing erg lastig te handhaven in een php,javascript,html omgeving(lees: AJAX)

Mja, wanneer de klant een nieuwe layout wilt maar geen nieuwe php code, is het toch wel fijn als er een template engine of iets gebruikt is.

Overigens ben ik niet zo fan van dit stukje:

Code:

$query  = mysql_query($sql);
                                $rows   = mysql_num_rows($query);       
                                
                                if(empty($rows)){       
                                        echo "Geen linkpartners toegevoegd, of linkpartners wachten op goedkeuring.";
                                }else{

wanneer $rows 0 neemt empty het voor leeg aan, terwijl dit naar mijn mening niet hetzelfde is.
In dit stukje code betekend het namelijk dat wanneer mysql_num_rows/mysql_query fout gaat (een return false; ) deze echo door gaat. Terwijl je dit misschien als fout afhandeling wilt oppakken, gezien er iets mis is gegaan. Maar dit kan een kwestie zijn van persoonlijke preferentie.

En zelf heb ik meer de style/voorkeur om de if en else om te draaien.

Code:

if ( $rows > 0 ) {
QUERY BENDE
}
else { echo 'geen linkparner'; }

Maar dat is zeker persoonlijke voorkeur

Overigens weet ik niet of je iets herschreven hebt, maar ik had het idee dat de mysql_* functies geen exceptions terug gooide.
Probeer trouwens eens pdo, werkt best fijn.