Dotaz: PHP login = MySQL user

[Martin Vesely]

Dobry den,

pisu takovy maly "informacni system" pro kamarady. Bude se do nej prihlasovat jen nekolik lidi. Z "urcitych duvodu" bych potreboval, aby login do aplikace korespondoval s loginem do MySQL. Tedy v zadnem PHP souboru nebude ulozene jmeno a heslo do DB.

Jenomze at googlim jak googlim, nachazim akorat clanky o tom, jak se prihlasovat pomoci tabulky 'users' a loginu ulozenem v 'config.php'.

Nemate nekdo zkusenosti s tim jak postupovat, pokud chci aby login do PHP aplikace byl zaroven loginem do MySQL? Mam pouzit mysql_pconnect? Skript 'login.php' otevre spojeni s DB a kdyz se povede tak presmeruje na index.php a spojeni zustane otevrene? Skript 'logout.php' spojeni zavre?

Nedari se mi nalezt jediny clanek, ktery by se timto zabyval. Ktery by mne upozornil na zasadni chyby, ukazal cestu...

Prosim nasmerujte mne nekdo. Dekuji. -Martin

Odpovědi

[Magog]

Proč to nejde udělat tak, že jméno a heslo z přihlašovacího formuláře bude zároveň jménem a heslem do MySQL? Problém bude v tom, jak udržovat spojení do databáze. Můžete si například pamatovat to jméno a heslo. Pamatovat si jej na straně serveru bude obtížné, protože nemáte k dispozici databázi, resp. ukládáte údaje nutné k přihlášení do DB. Pamatovat si to na straně klienta (např. v cookies nebo jako součást stránky) taky není ideální, protože při každém požadavku se jméno a heslo přenáší znovu na server.

Jinak řečeno logovat se do PHP systému loginem do DB serveru přináší spoustu problémů. Nestálo by za to zvážit, zda to nelze udělat jinak, jednodušeji?

Jinak standardní praxe je na začátku skriptu otevřít spojení do DB, vykonat svoje dotazy, zavřít spojení a odeslat výsledek.

[mess]

Nešlo by si pamatovat to přihlašovací jméno a heslo v $_SESSION. Samozřejmě za předpokladu, že se session bude ukládat někam jinam, než do databáze. Jak se dívám do dokumentace, tak se session ukládá do filesystému, takže s tím by problém být neměl.

[Magog]

Ano, sessions je možnost. Musí být ale povolené na serveru (což je dost často) a uživatel musí mít povolené cookies (což nemusí být tak časté, např. na mobilech nebo z důvodu paraonii).

(Session ID se ukládá do cookies u uživatele. Rozdíl je v tom, že se o to nemusíte starat vy jako autor dané aplikace)

[mess]

... a uživatel musí mít povolené cookies...

Uživatel, který má cookies zakázané se stejně nepřihlásí na většinu webů, jelikož je přihlášování většinou řešené právě tím to způsobem. Zadruhé, když je má zakázané, asi ví, co dělá a měla by mu stačit hláška, že si má cookies pro přihlášení povolit. Takže bych povolení/nepovolení cookies na straně uživatele jako problém neviděl.

[Šangala]

Lze to řešit ta že to bude $_SESSION proměná, ktéré se při standardním přihlášení ukládají do přednastaveného adresáře. Tento adresář lze změnit i ze skriptu (pokud máte server pod kontrolou a je Vám to umožněno) pomocí fce session_save_path().
Pokud takto učiníte máte další možnost kontroly tohoto ukládacího prostoru, a můžete jej promazávat dalšími prostředky aby tam něco nezůstávalo apod.
Pokud chcete zvýšit bezpečnost, můžete hesla do $_SESSION zašifrovaná na základě třeba něčeho v konfiguračním souboru php aplikace či certifikátu, a k tomuto souboru umožníte přístup jen pro čtení a jen uživateli, na kterého běží web server. (někdo bude argumentovat, že je to „security by obscurity“, ale není, je to jiná level, ne každý se může přihlásit na uživatele 'wwwrun', nebo jiného na kterého běží web server.) - já bych tam ještě před tím vložil nějaký obskurní prvek (otočil heslo, pokud má lichý počet znaků tak něco a tak), bo i to může být někdy součástí zabezpečení (buď to prodlouží, nepatrně čas k získání hesel, nebo to znemožní, člověku neznalému co se mu to dostalo do ruky, včetně certifikátu či master hesla to prokouknout).
A co se týče vypnutých cookie, zkuste si následující (na serveru s safe_mode=off):

<?php
error_reporting(0);
ini_set('display_errors', 'Off');

ini_set("session.use_only_cookies", "0");
ini_set("session.use_cookies", "1");
ini_set("session.use_trans_sid","1");
ini_set("session.name", "uidhash");
session_start();
echo ini_get();

error_reporting(E_ALL | E_STRICT);
ini_set('display_errors', 'On');

if(!isset($_SESSION['test']))
  $_SESSION['test'] = '???';
echo 'Last time: '.  $_SESSION['test'] . ', now: ' . time() . '<br />';

$_SESSION['test']=time();

?>
<form method="post" action="<?php echo $_SERVER['PHP_SELF'];?>" >
  <input type="submit" />
</form>
<a href="<?php echo $_SERVER['PHP_SELF'];?>">link</a>

Vypněte cookies v prohlížeči a refreshněte stránku a zkuste znovu - a podívejte se na zdrojová kód stránky.

[Šangala]

echo ini_get(); na 10. řádku je tam zbytečné-nesmyslné zakomentujte si jej :)

[Šangala]

Ono se to může ukládat i do DB, je potřeba jen napsat jednotlivé fce, zaregistrovate je pomocí session_set_save_handler() a pro připojení k DB použijete master heslo s uživatelem oprávněným zapisovat jen do té tabulky či db pro session proměnné.

[Jendа]

Při normálním HTTP přihlášení má na straně serveru jméno a heslo pořád dostupné v $_SERVER['PHP_AUTH_USER'] a $_SERVER['PHP_AUTH_PW'].

taky není ideální, protože při každém požadavku se jméno a heslo přenáší znovu na server

Jak to vadí?

[Magog]

Pokud jde přes HTTP, tak jde v plaintextu. A tím pádem se kdokoliv může kdekoliv po cestě kouknout. HTTPS je práce navíc.

[Jendа]

Pokud to jde nešifrovaně, tak kdokoli může

• odposlechnout heslo při přihlašování
• ukrást session při každém požadavku
• a pokud chce heslo a má session, může session zneplatnit a tím donutit oběť k dalšímu přihlášení heslem

[xkucf03]

Jestli se citlivé údaje přenášejí jen jednou nebo pokaždé je celkem jedno, rozdíl je minimální. HTTPS je více méně nutnost – ano, někdo to může považovat za práci/náklady navíc, ale v takovém případě bych doporučil zamyslet se nad tím, jakou bude mít práci a náklady v případě kompromitace, odposlechu.

[Martin Vesely]

Dobry den,

tedy predem dekuji za Vas zajem a pomoc. A abych trochu odkryl karty, proc vlastne resim tento zpusob prihlaseni do aplikace...

V prve rade jsem jej (snad naivne) pokladal za bezpecnejsi. Ale neuvedomil jsem si, ze stejne nekde budu muset mit uschovane to heslo. Kdyz jsem si precetl rozdil mezi mysql_connect a *_pconnect, zjistil jsem, ze slouzi docela jinemu ucelu, nez jsem se domnival.

Ve druhe rade budu mit uzivatele, kteri budou do DB prispivat a ty, kteri ji budou pouze cist. Delegovanim kontroly prav na MySQL jsem se chtel vyhnout tomu, abych to musel resit v samotne aplikaci. Tedy ne, ze bych to do jiste miry resit nemusel, ale i pri opomenuti/chybe by pripadny pokus o zapis zastavilo MySQL.

No a do tretice mne uz psani PHP kodu trochu omrzelo a zacal jsem objevovat schopnosti a silu samotneho (My)SQL. Snazim se na jeho bedra prenest velkou cast prace. Neresim do jake miry je to rozumne, chci si to zkratka vyzkouset.

Jak je login reseny napr. u PHPMyAdmin, netusite nekdo? Tedy koukam tady do kodu, ale moudry z toho nejsem.

Dekuji Vam, -Martin

[Šangala]

U phpMyAdmin definujete pomocí $cfg['Servers'][$i]['auth_type'] metodu přihlášení a od ní odvinutý způsob uložení informací viz třeba zde.
Kde v případě 'cookie' není heslo v session proměnné, jak píšou - kód jsem nezkoumal, ale přímo v zašifrované cookie (pomocí fráze v $cfg['blowfish_secret']), z hlediska bezpečnosti na to může být dvojí pohled. Heslo je zašifrované jinde, než je klíč - což je dobře, ale zašifrované heslo je veřejné - což nemusí vadit (mně to vadí z toho důvodu, že zašifrovná hesla se mohou nasbírat a pak stačí mít tu passfrázi (nechťa uteče :)). Pokud by byla zašifrovaná hesla na serveru jen nezbytně dlouho dobu, je těžké je nasbírat a není to tak zlé, bo ji(passfrazi) změním a hotovo, ale když to chodí pryč je třeba změnit všechna hesla hned.).