Projektowałem wiele serwisów, które miały zintegrowane z forum komponenty takie jak:

• rejestracja,
• przypomnienie hasła,
• zmiana hasła, nicku lub adresu email,
• usunięcie konta.

Wówczas nie było żadnego problemu - wystarczyło wszystkie te akcje z forum przekierować na URL’e obsługiwane przez CMS, który zajmował się zmianami  tabelach forum. Dlaczego przekierować? Jeżeli ktoś rejestruje się w serwisie, jest zarejestrowany na forum, natomiast, gdy rejestruje się na forum, nie jest rejestrowany w serwisie. To CMS integrujemy z forum, a nie forum z CMS’em (chyba, że zamierzamy inaczej, wtedy na odwrót).

Ostatnio klient zażyczył sobie, żeby zintegrowane było również logowanie. Nie najlepiej widzi mi się implementacja systemu autoryzacji z forum w CMS’ie, więc poszedłem “na łatwiznę”, bowiem miałem do czynienia z phpBB. Do osiągnięcia celu postanowiłem wykonać dwa kroki:

1. wysłać żądanie POST do forum na adres logowania z wypełnionymi polami POST z formularza logowania w CMS’ie,
2. przechwycić wysłane przez forum ciasteczka i przekazać je użytkownikowi.

Do połączenia się z forum via http użyłem HttpRequest. Wyszło z tego parę linijek kodu.

Projektując serwisy zaczynam ostrożnie podchodzić do usability. Temat jest bardzo wrażliwy, każdy webmaster to inne zdanie. Dziś chciałbym przedstawić problem logowania do serwisu. Oprócz hasła, przy logowaniu używamy:

• standardowo nazwy użytkownika,
• w niektórych serwisach adresu email, rzadziej spotykane zjawisko.

W trosce o użytkowników w kilku moich serwisach zastosowałem możliwość logowania się na adres email lub nazwę użytkownika. Wszystko po to, aby ułatwić dostęp do ukrytej części witryny, aby nikt nie “zwątpił” bo nazwy użytkownika, lub adresu email, który podał przy zakładaniu profilu. Sam używam w sieci kilku adresów email oraz kilku prefixów i suffixów do nicka Athlan. Mam problem z zalogowaniem, gdy danie nie pasują, a potrzebuję dostęp tylko na chwilę.

Przygotujmy zatem tok myślenia programu, który pobierze dane, w zależności od tego, jakie dane podał użytkownik. Pomijam walidację hasła etc:

1. Wykrycie, czy nick jest adresem email.
2. Jeżeli tak, pobierz dane użytkownika po polu user_mail i zapisz je do zmiennej $aUser.
3. Jeżeli nie, pobierz dane identyfikując rekord po kluczu user_name i zapisz pobrane dane do zmiennej $aUser.

Jak możemy zauważyć, w obu przypadkach dane zapisujemy do tej samej zmiennej $aUser, więc możemy je dalej tak samo wykorzystywać. Różni się tylko pobieranie, dlateg nie trzeba w żadnym wypadku powielać kodu.

• Przykładowy kod logowania.

Jak słusznie zauważył devnull, należy wykluczyć możliwość użycia znaku małpy w loginie przy rejestracji użytkownika. Wyjaśnienie znajdziecie w komentarzach.

Dla programisty nie jest wiele pracy, a warto ułatwić dostęp użytkownikowi do serwisu. Usability na pierwszym miejscu ;-)

Dla niektórych wygasanie sesji jest zabezpieczeniem (banki, etc.). Realizując jeden z projektów oczekiwałem od systemu tego, aby użytkownik nigdy nie gubił sesji, gdy ma otwarte okno w przeglądarce. Dlaczego? Może dodaje posta, być może uzupełnia dość obszerny tekst na stronie. Gdy klika zapisz, przerzuca go do strony logowania, a cały tekst zniknął za sprawą tego, że jego przeglądarka nie zapisuje wartości pól formularza. Skąd to znamy.

Jak użytkownik gubi sesję?

1. Jego ciastko wygasa, więc serwer nie może go zidentyfikować z sesją.
2. Po jakimś czasie, choćby odtworzył ciastko, plik sesji znika z naszego serwera (garbage collection).

Rozwiązania:

1. Wydłużenie czasu wygasania ciastka i sesji.
2. Odświeżenie strony w interwale mniejszym, niż wynosi czas wygasania sesji i ciastka.

Rozmyślając nad podtrzymaniem sesji, próbowałem znaleźć wszystkie metody oraz wybrać najlepszą. Wszystkie sprowadzają się do “odświeżenia” strony lub jej fragmentu tak, aby nasz silnik wykonał tylko potrzebne session_start(); czyli podtrzymanie aktywności sesji. Jest kilka mniej lub bardziej zadowalających sposobów:

1. Odświeżenie całej strony. To może spowodować, że dane wprowadzane przez użytkownika w formularzu zostaną utracone. Ponad to, jeżeli użytkownik czyta newsy, denerwującym może być fakt, że lista nagle zostanie przescrollowana do góry (prócz opery).
2. Wysłanie requestu ajax w tle. Minusem jest to, że trzeba używać biblioteki ajax lub pisać dodatkowy kod javascriptu. Jeżeli ktoś na stronie używa jakiegoś ajaxa - co za różnica. Poza tym same plusy.
3. Odświeżanie ukrytej ramki iframe lub elementu frameset. Minusów usablity prawie brak. Brak potrzeby instalacji javascriptów i ajaxa. Odświeżacz powinien wysłać nagłówek Refresh lub odpowiedni metatag.

Sposób 3 wydaje mi się najlepszy. Można go ulepszyć w ten sposób, aby ramka nie wysyłała żądania zaraz po załadowaniu strony. Powodowałoby to podwójne requesty do serwera.

• Przykład z ukrytym iframe.
• Przykład z Advajax.
• plik ping.php wygląda wówczas następująco: aplikacje nie używające frameworków ingerujących w standardowe działanie sesji session_start(); header('Refresh: 60');

Zapewne znajdą się osoby, które powiedzą: a co z użytkownikami, którzy mają wyłączone ramki, lub ich przeglądarki w ogóle ich nie obsługują. Zapytam wówczas: a co z użytkownikami, którzy nie akceptują cisteczek (wówczas sesje nie są dla nich użyteczne, chyba, że użyjemy przesłyki jej identyfikatora w adresie url). Dopytam również: a co z użytkownikami, którzy mają wyłączony Javascript? Patologiczne przepadki się po prostu pomija ;)

Rzadko bo rzadko, ale jestem zmuszony używać funkcji wordwrap(). Zawsze denerwowało mnie, że wordwrap łamie linię (ciągi znaków) a nie wyrazy (jak na to nazwa funkcji wskazuje). Czy aby na pewno nazwa funkcji jest trafna?

Zwraca łańcuch str zawinięty w kolumny o odpowiedniej ilości znaków określonej przez opcjonalny parametr szerokość . Linia jest łamana przy użyciu (opcjonalnego)parametru break .

Niestety, potrzebowałem załamać wyrazy, a nie linie. Z pomocą przychodzi preg_replace(). Założenie jest takie, że wyrazem jest każdy ciąg znaków nie zawierający spacji. Łamiemy nawet ciągi liczb oraz znaków specjalnych, niekoniecznie zawierających litery:

function _wordwrap($sString, $iLimit = 32)
{
  return preg_replace('/([^ ]{’ . (int)$iLimit . ‘})/’, ‘$1 ‘, $sString);
}

Paradoksy w nazewnictwie się zdarzają.

Google w dniu dzisiejszym zamieściła link na stronie głównej do swojego nowego projektu Google Chrome. Jest to nowa przeglądarka internetowa.

Zapowiada się całkiem nieźle. Wprowadzono wiele nowych opcji, które pomagają w przeglądaniu Internetu, takich jak:

• podświetlenie domeny na pasku adresu,
• ciekawy, chowający się pasek statusu,
• inaczej rozwiązane menu narzędzi, przeglądarka jest od razu otwarta w “trybie pełnoekranowym”, dostępnym normalnie w przeglądarkach po wciśnięciu klawisza F11, co zwiększa obszar przeglądanej strony.

Więcej featurów: http://www.google.com/chrome/intl/pl/features.html

Poza nowościami zostały zastosowane stare, konserwatywne techniki:

• karty (zakładki),
• ulubione (bookmarks), rozwiązanie identyczne jak w Firefox 3,
• strona startowa (splash) zastosowany w Operze (udoskonalona o opcję inteligentnego doboru stron).

Dla webmasterów dodano debugowanie JS (dostępne w FF i Operze) oraz (i tutaj uwaga) zużycie procesora przez każdą z kart!

Przeglądarka bardzo mi sie podoba, ustawiam jako defaultowa :)

Edit: Po wykryciu dziur, wracam defaultowo na ff.

Wszyscy cieszą się z Firefoxa 3, a deweloperzy ciągną się za włosy… dlaczego plugin Firebug nie jest kompatybilny z trójką. FF3 nie znajduje aktualizacji dla firebuga, a ten znajduje się na oficjalnej stronie dodatków. Co więcej… nie ma jej nawet na oficjalnej stronie wtyczki (beta? jakoś 1.1 beta jest, dlaczego nie ma 1.2). Dziwne. Dla tych, którzy jeszcze nie mają:

https://addons.mozilla.org/en-US/firefox/addon/1843

Dodatek oznaczony numerkiem 1.2.0b3

Stan na dziś: 6 milionów pobrań dodatków. Patrzcie ilu mamy deweloperów :)

Na forum.php.pl zmiana:

Forum Frameworki, które wcześniej znajdowało się w Gotowych rozwiązaniach, zostało przeniesione na forum PHP. Jest to uzasadnione jego rosnącą popularnością i naszą (ekipy php.pl) chęcią zwrócenia uwagi na ten aspekt wiedzy współczesnego programisty.

Możliwe, że niedługo zostanie podpięty mod, który będzie prosił o dodanie tagów (prefixów) do tematu przy zakładaniu wątku, w celu uporządkowania forum. Stworzymy tagi takie jak: [Zend Framework], [Symfony], [Kohana], [CakePHP], [Agavi], itp. Nieistniejące na liście można dopisać: [nazwatagu]. Bardzo użyteczna modyfikacja stworzona przez webdice zaimplementowana jakiś czas temu na forum Przedszkole.