logowanie .htaccess użytkownikami z psql’a

Apache pozwala na bardzo proste zabezpieczenie dostępu do serwisu z wykorzystaniem użytkowników znajdujących się w bazie danych, a dokładniej w tym przypadku w postgresie.

Oprócz modułu mod_auth należy dodać auth_pgsql oraz odpowiednio skonfigurować dane bazy:

AuthName "relam name"
AuthType basic
AuthBasicAuthoritative Off
Auth_PG_host localhost
Auth_PG_port 5432
Auth_PG_user db_user
Auth_PG_pwd db_password
Auth_PG_database db_name
Auth_PG_pwd_table table_name
Auth_PG_uid_field field_username
Auth_PG_pwd_field field_password
Auth_PG_encrypted off
require valid-user

Jak widać na przykładzie podajemy dane dostępowe do serwera, bazy danych, tabeli i nazwy pól. Mam nadzieję, że konwencja którą przyjąłem jest łatwa do odgadnięcia gdzie należy wpisać odpowiednie dane.

Przy autoryzacji tego typu należy pamiętać, że hasło jest z przeglądarki wysyłane otwartym tekstem, więc na połączeniu nieszyfrowanym jest ono łatwe do przechwycenia.

postgres na utf8 i serwis w latin2

Opiekuję się serwisem, który ze względu na długą historię życia jest napisany tak, że korzysta z kodowania ISO-8859-2, czyli tytułowego latin2. Jakiś czas temu była aktualizowana baza danych z pg 8.2 do pg 8.4 z konwersją bazy do utf-8 jako początkiem procesu zmiany strony kodowej całego serwisu w którym coraz częściej pojawia się potrzeba wykorzystania znaków z szerszego zakresu znaków niż oferuje latin2.

Obawa co do współpracy aplikacji z bazą były, ale jedno polecenie powoduje bezkłopotową konwersję znaków na poziomie połączenia z serwerem db.

Zapisuję dla pamięci

ALTER USER user SET client_encoding = 'LATIN2';

dzięki depesz

Call to undefined method stdClass

Przesiadłem się z laptopa na komp stacjonarny. Poszedł standardowy svn update plus konfiguracja virtuala. Potem restart apache’a i do pracy. Niestety nie do końca, bo przywitał mnie następujący komunikat:

Fatal error: Call to undefined method stdClass::IsConnected() in /home/illi/***/trunk/etc/init.inc.php on line 42

WTF!?

Dla porządku: php + postgresql, połączenie do bazy przez adodb_light.

Przyczyna błędu? Brak bazy :D Co mało ciekawe taki błąd występuje w wielu rodzajach softu i nie do końca wyniki z googla były pomocne, ba … wcale nie były. Tak to jest jak obiekt jakiejś klasy jest inicjalizowany przez funkcję spoza klasy, która sama w sobie nie ma obsługi poprawności inicjalizowanego obiektu.

jakie klucze stosować, jakie wybrać

Josh Berkus w cyklu „Primary KeyvilI, IIIII rozważa kwestie związane z używaniem kluczy głównych w tabelach. Zastanawia się nad kluczami będącymi w jego odczuciu surogatami prawdziwych kluczy głównych. Za taki surogat uważa klucze oparte na automatycznie inkrementowanych polach w bazie (autoincrement dla mysql’a oraz serial dla postgres’a) i przyznam, że podane argumenty są bardzo mocno i ciężko mi z nimi polemizować.

Generalnie autor zachęca do stosowania kluczy głównych które są rzeczywistym wyróżnikiem. Rozważmy sytuację w której mamy trzy proste tabele: users, groups, user2group – dwie pierwsze zawierają dane dotyczące odpowiednio: użytkowników oraz grup, ostatnia zawiera informację do których grup należy użytkownik.

Jeżeli zastosujemy jako klucze główne pola „ID” to w efekcie tabela user2group przyjmie zawartość:

+---------+----------+
| user_id | group_id |
+---------+----------+
|       1 |        1 |
|       2 |        2 |
|       2 |        6 |
+---------+----------+

Co jak widać niewiele mówi.

W przypadku w którym za klucze przyjmiemy odpowiednio email użytkownika oraz nazwę grupy to taka tabela będzie miała następującą zawartość:

+----------+----------+
| email    | group    |
+----------+----------+
| illi@x   | root     |
| gurthg@x | adm      |
| gurthg@x | www-data |
+----------+----------+

Trudno się nie zgodzić, że pomyłka w insercie typu: INSERT INTO tabela VALUES ( 1, 2 );
jest trudniejsza do wychwycenia niż w: INSERT INTO tabela VALUES ( 'illi@x', 'adm' );

Czytanie danych, szczególnie po latach albo obcych jest o niebo łatwiejsze wtedy kiedy naszymi kluczami są dane które coś znaczą.

Następnym drobnym zyskiem jest fakt zmniejszenia ilości zapytań lub joinów w zapytaniach.

Zauważymy, że w ostatnim przypadku żeby wylistować adresy email użytkowników należących do danej grupy, wtedy kiedy znamy tylko jej nazwę, wymusza w pierwszym przypadku użycie dwóch joinów. W drugim przypadku jest to prosty select. Oczywiście sytuacje tak proste raczej nie występują w życiu, ale są dobrym przykładem na zobrazowanie korzyści.

Oczywiście są sytuacje w których będę nadal używał kluczy opartych o inkrementowaną liczbę naturalną, ale tylko tam gdzie uznam to za naprawdę konieczne.

Natomiast w kwestiach prostych zostałem całkowicie przekonany do używania jako klucze główne takich danych, które niosą ze sobą rzeczywistą różnicę między rekordami.

Franchising.pl – franczyza, własny biznes

Ponieważ serwis istniał w sieci już od bardzo dawna, a pisany był w poprzednich latach w php3/php4 i pewne rzeczy ograniczały jego rozwój, to została podjęta decyzja o całkowitej przebudowie części użytkownika, tak żeby nie być ograniczonym przy dalszym rozwoju serwisu o historyczne zaszłość. W nowym serwisie użyto wzorca MVC, oddzielając warstwę logiki od warstwy prezentacji, a do tej ostatniej został użyty system szablonów smarty.

adres:
franchising.pl
w sieci
styczeń 2007
rodzaj
witryna informacyjna
cel
przepisanie starego serwisu w taki sposób, by był możliwy jego przyszły rozwój
zakres prac
import treści, konfiguracja serwisu, cięcie i implementacja grafiki
technologie
php, postgres, xhtml, smarty
projekt graficzny
Profitsystem