Tips och Trix för PHP-utvecklare

Något som jag tycker är praktiskt, måhända det bara är jag är i alla fall att använda sprintf(); till sqlsatser, det blir mycket lättare att läsa dem tycker jag. Titta på det i alla fall

Pirro

Två saker som jag tycker borde vara med är:
1. Beskriv risken för SQL-injections i add_slashes()-avsnittet.
2. Ett templates-avsnitt borde finnas eftersom det i kombination med Objektorienterad programmering är det bästa sättet att koda större siter.

1. Har jag aldrig gjort. Det systemet är det summaste PHP-gänget gjort.
2. Har vant in mig på <?, *bad jostor*
3. I början var jag dålig på det, men nu på senare tiden gör jag det alltid. kör ofta t.ex. preg_replace('/[^a-zåäöü0-9\s]/i', '', $var) för bättre säkerhet.
4. Gör jag bara om det krånglar.
5. Kör alltid med PCRE.
6. Borde jag kanske göra mer.....
7. Gör jag alltid, eller det jag beskrev i punkt 3.
8. Det var nytt för mig, får ta och börja med assoc..
9. På senaste tiden så gör jag alltid det.
10. Använder alltid enkelfnuttar, annars blir det rörigt.
11. Obejorienterat är för jobbigt......

echo `ls -l`;
http://se.php.net/manual/en/language.operators.execution.php

Vad hände med sidan? Finns den inte kvar?

frofrik: Från http://www.punbb.org:

Missade det...

Jag kom just på en sak som kan vara bra att ta upp.
När man skapar inloggningar kan det vara bra att använda ett Javascript för att hasha lösenordet innan man skickar det.

vbBulletin 2 (som Sweclockers kör) använder sig inte av det och då inträffade detta: http://forum.sweclockers.com/showthread.php?s=&threadid=38583...

Bara en tanke som är ganska viktigt för säkerhet.

1. Självklart känner man till det
2. Använder alltid <?php, snyggare och så kan väl <? krocka med xml.
3. Har blivit bättre på det på sistone.
4. Det använder jag alltid.
5. Woot ?
6. Använt den nån gång. Men inte ofta alls.
7. Brukar köra htmlentities
8. Jaså, det hade jag inte en aning om. Tack.
9. Har länge kört med kodstandard.
10. Japp, de där kan jag.
11. Aldrig skrivit objektorienterad kod.

8. Jag använder alltid mysql_fetch_array().
MYSQL_NUM och MYSQL_ASSOC gör att PHP inte utför mer arbete än om man skulle använda de andra funktionerna. Dessutom kan det finnas tillfällen då man vill använda MYSQL_BOTH.

Intressanta tips...

1. Har alltid använt $_GET, $_POST etc.. kul att veta att man gör rätt.
2. Brukar jag göra. Slarvar lite ibland och använder <? när jag skriver nåt litet stycke php i htmln
3. Detta brukar jag vara noga med. Inte bara ur ren säkerhetssynpunkt. Folk är idioter.
4. Det har jag lärt mig den hårda vägen.
5. Rätt så ny med RegExps. Fattade inte skillnaden när jag valde mellan preg och ereg. Valde preg för jag tyckte det såg bättre ut. Än en gång kul att se att man gjorde rätt
6. Använder den flitigt om nåt krånglar. Inte tänkt på att baka in den och pre-taggar i en funktion dock. Smart!
7. Det här var lite nytt för mig. Väldigt nyttigt.
8. Använde _array förr, men när jag såg (med print_r) att jag fick dubletter började jag lenast leta efter ett alternativ som verkade mindre korkat.
9. Skriver alltid ungefär likadant. Ibland space mellan operander ibland inte. Lite såna småsaker som kan skilja.
10. Brukar till och med tänka på att använda ' ' istället för " " om jag inte behöver variabelsubstitutionen.
11. Har aldrig skrivit objektorienterad php.

Bra skrivet. Det borde finnas mer sånt här.

/Robin

Det hjälper ju ingenting såvida inte algoritmen för hashen är dynamisk, för annars är det bara för boven att sniffa upp hashen, kringgå hashprocessen i javascriptet och logga in. Superenkelt.

Även om nu hashalgoritmen skulle vara dynamisk skulle det vara lätt att kringgå det eftersom javascript är synlig källkod.

Man kan använda till exempel MD5-algoritmen från http://pajhome.org.uk/crypt/md5/
Borde inte vara några större problem att koda in.

Ett problem är ju att man aldrig får det rätta lösenordet på servern, bara MD5-summan. Så nån 'maila-mig-mitt-bortglömda-lösenord'-funktion blir lite svårt :\
Men ur säkerhetssynpunkt är ju inte det nån nackdel.

/Robin

EDIT: Missuppfattade hur du menade...

Hmm... Om man med hjälp av nån sessions-variabel sparar nåt slags slumpmässigt prefix till lösenordet som läggs framför innan löenordet går igenom hashingen? Då måste man dock ha orginallösenordet på servern :\

Nåja, bara en tanke... Det är trots allt sent, kanske kan komma på nåt bättre efter lite sömn...

Ett sätt vore att stoppa in en eller flera variabler som PHP slumpar fram och skriver in dem i javascriptet varje gång sidan tankas. Javascriptet kan då göra en hash som blir påverkad utav variablerna.
PHP vet vilka variablar som har skickats och kan därför tidbegränsa just den unika hashen av lösenordet och neka alla försök av att använda just den hashen två eller flera gånger.

Säkerhetshålet är ju visserligen där, ungefär likadan form som WEP. Lyssnar man på tillräckligt många inloggningar knäcker man hashalgoritmen. Hur lätt det är att knäcka MD5 vet jag inte och hur lång tid det tar (med tanke på hur ofta man loggar in på systemet) vet jag inte.

Sen så finns det ju säkrare hashalgoritmer än MD5. Jag tror jag läste i någon annan tråd att SHA-1 skulle vara säkrare, fast jag har ju precis läst att den har blivit knäckt. SHA-2 finns ju alltid för de paranoida.

Blir bra mycket säkrare än om lösenordet skickas i klartext iaf.

Man brukar spara lösenord i databaser som MD5-hash. Ge mig nytt lösenord brukar jag göra så att man får skriva in svaret på en hemlig fråga eller något annat sätt för att verifiera sedan så återställs lösenordet i databasen med typ en 7 siffrig randomiserad sifferkombination som sedan mailas till användaren som han kan logga in med.

En rolig sak jag upptäckte härom dagen var att man kan anropa funktioner inifrån tilldelningen med heredoc syntax. Man måste dock använda "variable functions".

Problemet jag hade var att jag helst ville göra:

function getSelectBoxWithFoos()
{
	$s = '<select';
	# A lot of code here...
	$s .= '</select>';
	return $s;
}

$strMyForm = <<<HEREDOC
<form action="">
	<fieldset>
		<legend>Foo</legend>
getSelectBoxWithFoos()
	<fieldset>
	<hr />
	<input type="submit" value="Bar" />
</form>
HEREDOC;

Detta går inte utan renderar ju istället texten getSelectBoxWithFoos().

Man kanske skulle kunna tänka sig att följande skulle funka (notera måsvingarna runt funktionsanropet).

function getSelectBoxWithFoos()
{
	$s = '<select';
	# A lot of code here...
	$s .= '</select>';
	return $s;
}

$strMyForm = <<<HEREDOC
<form action="">
	<fieldset>
		<legend>Foo</legend>
{getSelectBoxWithFoos()}
	<fieldset>
	<hr />
	<input type="submit" value="Bar" />
</form>
HEREDOC;

Men det gjorder det inte. Detta skriver ut: {getSelectBoxWithFoos()}.

Det är här "variable functions" kommer in i bilden. Följande funkar (notera första raden och $-tecknet framför funktionsanropet).

$getSelectBoxWithFoos = 'getSelectBoxWithFoos';
function getSelectBoxWithFoos()
{
	$s = '<select';
	# A lot of code here...
	$s .= '</select>';
	return $s;
}

$strMyForm = <<<HEREDOC
<form action="">
	<fieldset>
		<legend>Foo</legend>
{$getSelectBoxWithFoos()}
	<fieldset>
	<hr />
	<input type="submit" value="Bar" />
</form>
HEREDOC;

Mer info
Heredoc
Variable functions

Jo. Sålänge man har en mail att maila det nya lösenordet till så funkar ju det. Om nån skulle sniffa upp svaret på den hemliga frågan så måste de ändå sniffa lösenordet till mailen för att få tag i det nya lösenordet.
Har dock retat mig länge på hotmails system med hemlig fråga, där vem som helst som gissar rätt på frågan kan byta lösenord. Något jag anser vara den svagare länken i hotmails system.

Man kommer ändå inte undan att nån kan sniffa MD5-hashen och kringgå javascriptet för att logga in.

andrin:
och vad ska det vara bra för?

Hmm... Om man föredrar funktionorienterad utveckling så borde man se fördelarna direkt.

Med funktionsorienterad utveckling så styckar du upp din kod i olika mer eller mindre självständiga enheter som blir lättare att flytta runt.

Om man föredrar att ha allt i ett skript som läses rakt upp och ner så hjälper inte detta något.

Har märkt att de flesta PHP-utvecklare går genom nästan samma faser:

1. Rakt upp och ner. All kod i ett skript. PHP-motorn läser/tolkar uppifrån och ner och spottar ut sig i den ordning koden är skriven.

2. Funktionorienterad utveckling. Koden ligger i olika funktioner som anropas från diverse ställen. Fördelen är att det blir lättare att återanvända kod och att det blir lättare att överblicka.

3. Början till OOP. Man börjar skapa klasser för konkreta saker.

4. Semi OOP. Man börjar med basklasser, abstrakta klasser.

5. Full OOP. Klasser, klasser klasser och mer klasser. Man gör allt i klasser. Gör man en sak utanför en klass får man ont i magen och mår smått illa. Man börjar betrakta sin omgivning med klasstänkandet i bakhuvudet: "Ärver det här bordet från ett träd? Eller ett annat bord? Eller implementerar det t.o.m. flera träd-interface? Det här glasbordet då?" Man blir smått galen och närmar sig Tao.

Det kan flera faser som jag inte nämnt men det är sett i stort.

Aha.. Koncentrerade mig för mycket på säkerhetssnacket ovan och glömde bort att det här var en allmän "Tips och Trix för PHP-utvecklare"-tråd. Ursäkta.

Jo, jag föredrar funktionsoreinterad utveckling. Och det här var ett bra tips.
Har dock aldrig använt mig av heredoc-syntax innan. Men nu slipper jag slita mitt hår allt för mycket om jag skulle få för mig att vilja anropa en funktion i.

/Robin

Hittade en intressant benchmark-sida.

Är man en nörd när man känner igen sig från din lista? =/.
USCH!

Fast det brukar nästan alltid gå till överdrift när man programmerar.

Det är kul att någon tar sig tid att göra ett så pass seriöst arbete för att hjälpa andra! Tack för det!

Men själv har jag inte riktigt kommit såhär långt än. Någon som har något bra tips på hur jag kan lära mig php från grunden?

3. Kan posta hur jag brukar göra:

function navigator()

{

		if(isset($_GET['page']) && file_exists('include/inc.'.$_GET['page'].'.php'))

		{

			$content =  'include/inc.'.$_GET['page'].'.php';

		}

		else $content = 'include/inc.start.php';

		

		return $content;

}

Edit: Dubbel

Ajdå... byte ifrån swtich-case satsen till den jag skrev ovan för att jag tyckte den var smidigare... Bara o byta tillbacka då antar jag

Kan man inte använda något i stil med:

<?php
	
	$good_inc = array('start', 'blandat');
	
	if(in_array($_GET['p'], $good_inc)){
		include($_GET['p'].'.inc');
	}
	else{
		include('annat.inc');
	}

?>

??