Rozdzia│ 16. Autentykacja HTTP w PHP
Autentykacja HTTP za pomoc▒ PHP jest mo┐liwa tylko w przypadku gdy PHP pracuje jako modu│ Apache - nie dostΩpne w wersji CGI. W skrypcie mo┐na u┐ywaµ funkcji Header() kt≤ra wysy│a komunikat "Authentication Required" do przegl▒darki, ta za╢ wy╢wietla okno ┐▒daj▒ce wprowadzenia Username/Password. Po wype│nieniu przez u┐ytkownika p≤l username i password, URL zawieraj▒cy skrypt PHP zostaje ponownie wywo│any ze zmiennymi $PHP_AUTH_USER, $PHP_AUTH_PW oraz $PHP_AUTH_TYPE okre╢laj▒cymi odpowiednio nazwΩ u┐ytkownika, has│o i typ autentykacji. Jedynym typem autentykacji wspieranym przez PHP jest "Basic". Zobacz opis funkcji Header() dla szczeg≤│≤w.
Oto fragment skryptu kt≤ry wymusi autentykacjΩ klienta dla tej strony www w kt≤rej jest umieszczony:
|
Przyk│ad 16-1. Autentykacja HTTP
<?php
if(!isset($PHP_AUTH_USER)) {
Header("WWW-Authenticate: Basic realm=\"My Realm\"");
Header("HTTP/1.0 401 Unauthorized");
echo "Tekst wysy│any gdu user wci╢nie przycisk Cancel \n";
exit;
} else {
echo "Witaj $PHP_AUTH_USER.<P>";
echo "Poda│e╢ nastΩpuj▒ce has│o: $PHP_AUTH_PW <P>";
}
?>
|
Oczywi╢cie zamiast wy╢wietlaµ nazwΩ uzytkownika i jego has│o ($PHP_AUTH_USER i $PHP_AUTH_PW), mo┐esz sprawdziµ ich autentyczno╢µ, przesy│aj▒c zapytanie do bazy danych lub odnajduj▒c je w pliku *.dbm (plik bazy danych zawieraj▒cy tylko pary klucz-warto╢µ).
Aby zapobiec pisaniu skrypt≤w kt≤re odkrywaj▒ has│o dla strony kt≤ra wcze╢niej zosta│a udostΩpniona przy zastosowaniu sprawdzenia autentykacji tradycyjnym zewnΩtrznym mechanizmem, zmienne PHP_AUTH nie bΩd▒ ustawione je┐eli zewnΩtrzna autentykacja jest dostepna dla okre╢lonej strony. W tym przypadku zmienna $REMOTE_USER mo┐e byµ u┐yta do identyfikacji uzytkownika korzystaj▒cego z zewnΩtrznych mechanizm≤w autentykacji.
Jednak powy┐sze metody nie zapobiegaj▒ wykradaniu hase│ do stron po╢wiadczanych je┐eli kto╢ kontroluje strony nie potrzebuj▒ce po╢wiadczenia na tym samym serwerze.
Zar≤wno Netscape jak i Internet Explorer czyszcz▒ bufor autentykacji dla okre╢lonej witryny je╢li otrzymaj▒ od serwera odpowied╝ o kodzie 401, co mo┐e powodowaµ wylogowanie u┐ytkownika, zmuszenie go do ponownego wprowadzenia login/has│o. Niekt≤re witryny stosuj▒ ograniczenia czasowe dla sesji u┐ytkownik≤w lub umieszczaj▒ przycisk "log-out".
|
Przyk│ad 16-2. Autentykacja HTTP wymuszaj▒ca wprowadzenie nowego name/password
<?php
function authenticate() {
Header( "WWW-authenticate: basic realm='Test Auth'");
Header( "HTTP/1.0 401 Unauthorized");
echo "Musisz wprowadziµ poprawny login i has│o aby
uzyskaµ dostΩp do zasob≤w tej witryny\n";
exit;
}
if(!isset($PHP_AUTH_USER) || ($SeenBefore == 1 && !strcmp($OldAuth, $PHP_AUTH_USER)) ) {
authenticate();
}
else {
echo "Witaj: $PHP_AUTH_USER<BR>";
echo "Stare: $OldAuth";
echo "<FORM ACTION=\"$PHP_SELF\" METHOD=POST>\n";
echo "<INPUT TYPE=HIDDEN NAME=\"SeenBefore\" VALUE=\"1\">\n";
echo "<INPUT TYPE=HIDDEN NAME=\"OldAuth\" VALUE=\"$PHP_AUTH_USER\">\n";
echo "<INPUT TYPE=Submit VALUE=\"Re Authenticate\">\n";
echo "</FORM>\n";
}
?>
|
Takie zachowanie nie jest wymagane w standardzie HTTP Basic authentication, wiΩc nie musisz siΩ tym martwiµ. Lynx nie czy╢ci bufora autentykacji przy kodzie b│Ωdu 401, naci╢niΩcie back i forward dalej umo┐liwia korzystanie z zabezpieczonych zasob≤w choµ takiej mo┐liwo╢ci nie powinno byµ (back wychodzi z zabezpieczonych zasob≤w a forward ponownie wchodzi wiΩc wymagana jest ponowna autentykacja).
| 
