Oprócz ciasteczek (cookies) dwoma podstawowymi sposobami przekazywania parametrów na wejście serwera HTTP są metody znane jako GET i POST. Ta pierwsza wykorzystuje do tego sam adres URL, umieszczając dodatkowe dane po znaku zapytania, np.: /forum/showthread.php?id=12345&filter=none. W przypadku tej drugiej parametry są przekazywane poprzez treść samego żądania HTTP; z punktu widzenia użytkownika są więc one niewidoczne.
Metoda GET zwykle służy do wymiany danych między stronami połączonymi za pomocą zwykłych linków. POST z kolei wykorzystuje się do wysyłania informacji wprowadzanych przez użytkownika w różnego rodzaju formularzach. Przekierowanie następuje wówczas po jego wysłaniu, co zwykle czyni się odpowiednim przyciskiem (submit).
Bywa jednak tak, że chcemy dokonać takiego przekierowania – z ustalonymi parametrami – po zwykłym kliknięciu na link, z pominięciem wypełniania formularza przez użytkownika. Dobrym przykładem jest sytuacja, gdy nasza strona korzysta w jakiś sposób z innego serwisu, do którego przejście wymaga logowania. Jeśli chcielibyśmy, by odbywało się ono automatycznie – po kliknięciu jakiegoś linku – to musimy wysłać odpowiednie żądanie HTTP z parametrami przesłanymi metodą POST. Do tego nie wystarczy niestety sam znacznik <a>
.
Rozwiązaniem jest wtedy użycie dodatkowej strony przekierowującej, na której umieścimy już odpowiednio “wypełniony” formularz:
Oczywiście nazwy i wartości parametrów (zapewne generowane dynamicznie po stronie serwera) zależą ściśle od tego, dokąd chcemy nasz wyrób formularzopodobny wysłać. Wszystkie je deklarujemy jednak jako <input type="hidden" />
, bo w założeniu użytkownik nie powinien ich (łatwo) zobaczyć. Ponadto, jeśli – tak jak wyżej – mówimy o loginie/haśle czy innych danych, które powinno się chronić przed niepowołanym dostępem, to powinniśmy jeszcze wysyłać razem z naszą stroną nagłówki HTTP zabraniające cache‘owania:
W końcu, skoro mamy już gotowy “formularz”, to trzeba jeszcze zadbać o to, by wysłał się on sam natychmiast po załadowaniu strony przekierowującej. Do tego już trzeba wykorzystać skrypt uruchamiany w przeglądarce:
Tak przygotowaną stronę możemy podlinkować pod nasz serwis. Jak widać trochę z tym zabawy, ale tak to jest, gdy chcemy zrobić coś niestandardowego :)
A co się stanie jeżeli użytkownik wyłączy obsługę javascript w przeglądarce? – przekierowanie nie nastąpi i wystarczy obejrzeć kod strony, żeby zobaczyć ukryte dane. To nie jest dobry sposób – chyba że dane wysyłane przez post nie są aż tak ważne.
Jeśli wykorzystujemy ten sposób do logowania do jakiegoś systemu powiązanego, do którego hasło użytkownik i tak nam podaje (np. rejestrując się), to pokazywanie go jemu samemu nie nazwałbym jakimś wielkim naruszeniem bezpieczeństwa. Gorzej, jeśli by to zostało w jakichś plikach tymczasowych współużytkowanego komputera, ale podane w notce nagłówki powinny temu zapobiec.
Jeśli rzecz się dzieje lokalnie na jednym komputerze, to takie rozwiązanie można uznać za bezpieczne (mówię o tych danych do logowania).
Ale można to rozwiązać też inaczej (bezpieczniej). Dane do logowania powinien mieć skrypt działąjacy po stronie serwera www (np. a PHP) i to on powinien logować danego użytkownika do dodatkowego serwisu (np. przy użyciu biblioteki cURL w PHP). No i jeszcze logowanie następuje przy użyciu bezpiecznego połączenia SSL.
A jeśli dopuścimy możliwość trzymania danych logowania w jednym skrypcie HTML, to automatyczne logowanie do zewnętrznej strony da się zrobić bez pośrednictwa dodatkowego skryptu.
Wystarczy, zamiast tworzyć link do naszego skryptu pośredniczącego w logowaniu, stworzyć w naszym kodzie strony niezależny formularz (form) z danymi jak w zaprezentowanym skrypcie przekierowującym i ostylować CSS-em przycisk submit oraz nadać mu stosowną nazwę (jak w linku), np tak:
[/code]input[type=submit] { background: none; text-decoration: underline; color: blue; border: none; cursor: pointer; }[/code]
i gotowe. Teraz po kliknięciu na tego linka (przycisk) wywołany zostanie submit tego formularza i automatyczne zalogowanie.