nefunkční SHA1

T-fon:
Do databáze vkládáte přímo heslo z POST, ale při přihlašování projde funkcí db_escape() a trim(). Je to kvůli bezpečnosti a stejným procesem by mělo projít vždy, tj. i při insertu.

Jinak doufám, že to heslo máte v databázi uložené fakt v hashi, že jste ho tam pro testování nenapsal v nějakém adminu přímo.

T-fon:
Není problém v tom, že při zakládání účtu se na heslo nevolá trim a db_escape, čili to nemusí být úplně stejný řetězec?

„ještě bych prosil o stručné vysvětlení té funkce db_escape“
Escapuje data odesílaná do databáze. Například v tom kódu výše kdybych při zakládání účtu odeslal například údaje:
založí se dva uživatelé.
Ta funkce právě zabrání tomu, aby řetězec šlo upravit tak, aby se interpretoval jako část SQL dotazu.

T-fon:
„když použuju úplně stejné heslo a odeberu to SHA1 (ze zakládání účtu i z ověření), tak to funguje správně“
Tyhle chyby jsou na 99% způsobené tím, že buď při registraci, nebo při ověření, se do SHA1 pošle špatný řetězec.
První krok je ověřit (SHA1 si jde vygenerovat i online), jestli hash uložený v databázi je skutečně správný hash toho hesla.
Pokud není, je chyba při zakládání účtu. Pokud je, zaměřil bych se na ověřování hesla.

„takže by to mělo vypadat takto při té registraci?“
Práce s tím heslem by měla být úplně stejná jako při té kontrole.

ideálně si vytvoř jednu funkci, kterou proženeš heslo VŽDY, při vytváření účtu i při přihlašování. Vyhneš se tak těmto nepříjemnostem.

Neznám php, ale nelíbí se mi:
db_escape(trim(SHA1('$_POST[heslo]')))
Pokud vím, tak apostrofy neinterpretují svůj vnitřek, tedy provádíš hash nad řetězcem znaků: dolar podtrzitko velke p velke o velke s velke t leva hranata zavorka...

Navíc výstup SHA1 jsou jen znaky 0-9a-f, takže žádné bílé znaky ani další nebezpečné sekvence tam nebudou. (U ostatních polí vždy db_escape, nebo obdobné prováděj.)

nejak nerozumiem, preco escapujes uz vytvoreny hash. V nom nikdy nebudu ziadne nebezpecne znaky

T-fon:
Musíte si uvědomit, které funkce jsou v PHP a které v MySQL. Ve vzoru máte funkci sha1() použitou v MySQL (je to sha1, ne sh1). Ekvivalentní funkce je i v php sha1(), ale měl by vám být jasný řetězec aplikace funkcí, ne to nějak nakombinovat a doufat, že to vyjde.
Je hloupost prvně hashovat a až pak trim(), db escape není nezbytné, ale klidně to tam nechce.

„.......'$_POST[nick]','provereni_hesla($_POST[heslo])','$_POST[kolo]',........“
To nepůjde právě proto, že mícháte php funkci do mysql.
A podobně ošetřit všechny ostatní vstupy (nick , kolo).

T-fon:
udělej si pořádek v použití uvozovek a apostrofů a také, kdy je proměnná řetězec a kdy není:

$_POST je pole

1)
$_POST[*] je přístup k prvku pole, typ se zachovává
pokud je * řetězec, neuvozený, tak se interně v tomto kontextu převede, toto nepoužívat!
pokud je * 'řetězec', tak se použije přesně tak jak je zapsaný
pokud je * "řetězec", tak je ekvivalentní 'řetězec', dokud řetězec neobsahuje proměnné a nějaké další speciální konstrukce (*)

2)
'$_POST[*]' je řetězec obsahující znaky 'dolar p o s t zavorka ... zavorka'
pokud je * řetězec, neuvozený, je výsledek triviální: 'dolar p o s t zavorka ř e t ě z e c zavorka'
pokud je * 'řetězec', dojde k chybě
pokud je * "řetězec", bude výsledek 'dolar p o s t zavorka uvozovka ř e t ě z e c uvozovka zavorka'

3)
"$_POST[*]" je řetězec který obsahuje hodnotu prvku pole $_POST převedenou na řetězec
pokud je * řetězec, neuvozený, tak se interně v tomto kontextu převede, toto nepoužívat!
pokud je * 'řetězec', získá z pole $_POST hodnotu s klíčem 'řetězec' a převede ji na řetězec
pokud je * "řetězec", dojde k chybě

první způsob vrací hodnotu takového typu, jakého skutečně je, například 12
druhý způsob žádný přístup do pole neprovádí, ani není možný
třetí způsob vrátí hodnotu z pole převedenou na řetězec, například '12'

pokud vím, že výstupem je řetězec, nemá smysl funkci obalovat uvozovkami (apostrofy už vůbec ne, to nezpůsobí zavolání funkce)
php je dynamický jazyk, proměnné nemají přímo určené typy, ale každá hodnota ví, kterého je typu a sama se převádí na jiný typ v závisloti na kontexu, kde je použita

apostrofy obecně nijak neinterpretují obsah mezi nimi, řetězec přesně odpovídá tomu, jak je zapsaný, uvažuj o nich jako o správném zápisu řetězce
uvozovka jen vynutí interpretaci proměnné v řetězcovém kontextu (hodnota se převede na řetězec), uvozoky jsou používány často nadbytečně, většinou nejsou třeba pro interpretaci proměnných a lze je nahradit apostrofy

převedení na řetězec jde také vynutit operátorem sloučení řetězců, tečkou:
ekvivalentně
použití zpětného lomítka si už nastuduj sám

(*) umí jen hodnotu proměnné, hodnotu prvku pole a o moc víc už ne, neumí ani volání funkce.
tento příspěvek přenechávám djpw, aby s ním naložila, jak bude chtít

T-fon:
Ty apostrofy patří SQL dotazu, z pohledu PHP je to v uvozovkách. Je-li pole v uvozovkách, již se neuvozuje jednoduchý klíč, tj. můj způsob je správný. juriad má pravdu v 1 a 2, ale v 3 (tento případ), se mýlí. To, co píše nepoužívat, se má používat :-).
Vše o řetězcích, ale je to aspoň na hodinu.

dosazení hodnoty do stringu:
pokud moc chceš uvozovky:

nebo spojováním pomocí apostrofu:
za pomocí apostrofů:

moc jiných způsobů není, nejpříjemnější je asi ten první

T-fon:
1) php řetězce uvozené pomocí apostrofů (') neumožňují vkládání přoměnných (prostě proměnnou kterou obsahují nenahradí za její hodnotu).
2) u html atributů se uvozovky (") píší mezi rovnítko a hodnotu (nevím proč je máš až za $color)
3) řetězit řetězce můžeš jen pokud je ukončíš (a to musíš stejným znakem jako kterým jsi řetězec uvodil). echo 'první řetězec v apostrofech' . $promenna ' . "řetězec v uvozovkách" . 'apostrofy s něčím obaleným uvozovkami "Jupí' . $dalsiPromenna . '!" posledni retezec';
4) pokud v tom máš zmatek, není nic jednoduššího než se tomu vyhnout - všechny řetězce ukončuj, používej apostrofy, proměnné vkládej do řetězců pomocí tečkového operátoru atd atd atd (nic z toho není nijak závazné, ale možná ti to pomůže zpřehlednit řetězce).
5) ten kód bych já osobně napsal takhle: echo '<img src="' . $color . '.gif" alt="barva" />';