Model klient-serwer i peer-to-peer, podział pracy strony WWW między serwerem (PHP) a przeglądarką (JavaScript), walidacja formularzy i CMS.
W modelu klient-serwer jedna strona udostępnia usługę, a druga z niej korzysta. Serwer czeka na żądania i odpowiada na nie – serwer WWW wysyła strony, serwer poczty przechowuje i przekazuje listy, serwer DNS zamienia nazwy na adresy. Klient, czyli przeglądarka, program pocztowy albo aplikacja w telefonie, inicjuje połączenie i prosi o konkretną rzecz. Role są stałe: klient nie obsługuje innych klientów, a serwer musi być dostępny cały czas pod znanym adresem. Rozmowa przeglądarki z serwerem WWW toczy się protokołem HTTP lub HTTPS.
W modelu peer-to-peer (P2P) każdy węzeł jest jednocześnie klientem i serwerem. Nie ma centralnej maszyny – komputery łączą się ze sobą bezpośrednio i wymieniają dane między sobą. Tak działa BitTorrent: pobierając plik, jednocześnie udostępnia się już pobrane fragmenty innym. Zaletą jest brak pojedynczego punktu awarii i rosnąca wydajność wraz z liczbą uczestników, wadą – trudniejsza kontrola nad tym, kto i co udostępnia.
Strona internetowa powstaje w dwóch miejscach naraz i podział ten decyduje o tym, co jest możliwe i co jest bezpieczne. Kod po stronie serwera wykonuje się na maszynie, na której stoi strona – zanim cokolwiek trafi do przeglądarki. Ma dostęp do bazy danych i plików, a użytkownik nigdy nie widzi jego treści; dostaje wyłącznie wynik. Typowym przykładem jest PHP. Kod po stronie klienta wykonuje przeglądarka na komputerze użytkownika. Odpowiada za interakcję: reakcję na kliknięcie, animacje, ukrywanie i pokazywanie elementów bez przeładowania strony. To domena JavaScriptu. Ten kod jest w całości widoczny dla każdego, kto otworzy podgląd źródła.
Z tej różnicy wynika najważniejsza konsekwencja praktyczna: kodowi po stronie klienta nie można ufać. Użytkownik może go podejrzeć, zmienić albo wyłączyć.
Cztery zasady, które porządkują całą resztę:
| Czynność | Gdzie się wykonuje | Dlaczego tam |
|---|---|---|
| Pobranie rekordów z bazy danych | serwer | tylko kod serwerowy sięga do bazy; jej hasło nie może trafić do przeglądarki |
| Zbudowanie kodu HTML strony z danych | serwer | do klienta ma pójść gotowy wynik, a nie sposób jego powstania |
| Sprawdzenie formatu adresu e-mail w trakcie wpisywania | klient | natychmiastowy komunikat bez wysyłania formularza |
| Ostateczne sprawdzenie danych przed zapisem | serwer | walidację u klienta da się ominąć |
| Rozwinięcie menu po kliknięciu | klient | zmiana dotyczy wyglądu już wczytanej strony |
| Animacja i efekt przy przewijaniu | klient | dzieje się w oknie przeglądarki, bez udziału sieci |
| Sprawdzenie hasła przy logowaniu | serwer | wysłanie hasła do przeglądarki dałoby je każdemu |
| Zapamiętanie, kto jest zalogowany | serwer | klient trzyma tylko identyfikator sesji, uprawnienia przyznaje serwer |
| Zapisanie zamówienia w sklepie | serwer | zapis ma być trwały i wspólny dla wszystkich |
| Podpowiedzi wyszukiwania w trakcie pisania | obie strony | JavaScript pyta w tle, ale szuka w bazie serwer |
| Cecha | Serwer (PHP) | Klient (JavaScript) |
|---|---|---|
| Gdzie się wykonuje | na serwerze | w przeglądarce |
| Widoczność kodu | ukryty | w pełni widoczny |
| Dostęp do bazy danych | tak | nie bezpośrednio |
| Działa bez przeładowania strony | nie | tak |
| Można wyłączyć | nie | tak |
| Nazwa angielska | server-side, back-end | client-side, front-end |
CMS (system zarządzania treścią) pozwala prowadzić stronę bez pisania kodu. Treść dodaje się przez panel administracyjny w przeglądarce, podobnie jak w edytorze tekstu, a system sam składa z niej gotowe podstrony. To typowa aplikacja klient-serwer: panel działa w przeglądarce, a treść i logika siedzą na serwerze.
Kluczowa idea to oddzielenie treści od wyglądu. Teksty i zdjęcia trafiają do bazy danych, a o wygląd dba szablon. Zmiana szablonu przebudowuje całą stronę bez ruszania treści; dodanie artykułu nie wymaga znajomości HTML. Najbardziej znane systemy to WordPress, Joomla i Drupal. Rozbudowuje się je wtyczkami, które dokładają funkcje – sklep, formularz kontaktowy, galerię.
Strona oparta na CMS jest generowana dynamicznie – treść pobierana jest z bazy danych przy każdym wejściu, w odróżnieniu od strony statycznej, gdzie każdy plik istnieje gotowy na serwerze. Wadą jest to, że gotowy system bywa cięższy i wolniejszy od strony napisanej ręcznie, a jego popularność czyni go celem ataków. Nieaktualizowany CMS z przestarzałymi wtyczkami to jedno z najczęstszych źródeł włamań na strony.
W porównaniu ze stroną pisaną ręcznie CMS wygrywa krótkim czasem uruchomienia i tym, że aktualizacja treści nie wymaga wiedzy programistycznej. Strona pisana ręcznie jest za to wydajniejsza i ma mniejszą powierzchnię ataku – bez panelu logowania i wtyczek – ale każdą nową funkcję trzeba w niej napisać samodzielnie.
Uznanie, że w podglądzie źródła widać całą stronę. Widać wyłącznie to, co serwer wysłał: HTML, style i JavaScript. Kod PHP wykonał się wcześniej – w źródle jest jego wynik, a nie polecenie. Zdanie „użytkownik może zobaczyć kod PHP" jest w teście prawda/fałsz zawsze fałszywe.
Traktowanie walidacji w JavaScripcie jako zabezpieczenia. JavaScript można wyłączyć, podmienić w narzędziach przeglądarki albo pominąć, wysyłając dane bez formularza. Sprawdzenie u klienta daje natychmiastowy komunikat, ale o przyjęciu danych rozstrzyga dopiero serwer. W odpowiedzi opisowej trzeba napisać oba zdania – za samo „sprawdzam poprawność w JavaScripcie" punktu nie ma.
Uznanie, że JavaScript nie może pobierać żadnych danych. Może: czyta pola formularza wypełniane przez użytkownika i potrafi w tle dopytać serwer, bez przeładowania strony. Fałszywe jest natomiast zdanie z tego samego zestawu maturalnego, że PHP zawsze pobiera dane od klienta – strona bez formularza wykonuje się bez żadnej informacji od użytkownika.
Mylenie modelu logicznego z topologią i twierdzenie, że w P2P nie ma serwera. Klient-serwer i peer-to-peer mówią o rolach programów, a nie o układzie kabli – tym zajmują się topologie sieci. W sieci P2P funkcja serwera nie znika – pełni ją każdy węzeł, równolegle z rolą klienta. Poprawna odpowiedź brzmi „nie ma serwera centralnego", a nie „nie ma serwera".
Mylenie CMS-u z językiem albo z hostingiem. CMS to gotowy program zainstalowany na serwerze, hosting to miejsce, w którym on stoi, a HTML i PHP to języki, w których go napisano. WordPress nie jest ani językiem, ani serwerem.
Fragment sklepu internetowego:
| Element strony | Co obserwujemy |
|---|---|
| Pole „adres e-mail" | po wpisaniu adresu bez znaku małpy od razu pojawia się komunikat |
| Przycisk „Zaloguj" | strona wczytuje się na nowo i pokazuje imię zalogowanego użytkownika |
| Lista produktów | przy każdym wejściu inna, bo pochodzi z bazy sklepu |
| Podgląd źródła strony | widać HTML i funkcje JavaScriptu, nie widać ani jednej linii PHP |
Uzupełnij tabelę:
| Pytanie | Odpowiedź |
|---|---|
| Sprawdzenie formatu adresu e-mail w trakcie wpisywania – klient czy serwer? | |
| Pobranie listy produktów z bazy – klient czy serwer? | |
| Porównanie hasła z zapisanym w bazie – klient czy serwer? | |
| Animacja przy przewijaniu – klient czy serwer? | |
| Język, którego kodu nie widać w podglądzie źródła | |
| Język, którego kod widzi każdy odwiedzający stronę | |
| Skrót systemu pozwalającego prowadzić stronę bez pisania kodu |
Sprawdzanie danych w przeglądarce służy i nie jest zabezpieczeniem, bo można je . Model sieci, w którym każdy komputer jest naraz klientem i serwerem, to .
Bo wykonał się na serwerze, a do przeglądarki poszedł wyłącznie jego wynik w postaci HTML. Kod źródłowy nigdy nie opuszcza serwera.
Dla wygody użytkownika – natychmiastowy komunikat o błędzie jest przyjemniejszy niż przeładowanie strony. To dodatek do walidacji serwerowej, nie jej zamiennik.
Historycznie tak, ale istnieją środowiska pozwalające uruchamiać go również po stronie serwera. Na maturze obowiązuje jednak klasyczny podział.
W klient-serwer jest jedna maszyna, która obsługuje wszystkich; gdy padnie, usługa znika. W peer-to-peer uczestnicy wymieniają dane bezpośrednio między sobą, więc nie ma centralnego punktu awarii, ale też nikt nie gwarantuje, że dany zasób będzie dostępny.
Przy typowej stronie informacyjnej zwykle tak. Przy nietypowych funkcjach i integracjach nadal potrzebny jest ktoś, kto napisze kod.
Statyczna to gotowe pliki wysyłane bez zmian. Dynamiczna jest składana przy każdym wejściu z danych w bazie – i tak działa CMS.
Bo łatają znane luki. Skoro system jest popularny, atakujący masowo skanują sieć w poszukiwaniu nieaktualnych instalacji.
Do tego hasła nie mamy jeszcze przypisanych pojedynczych zadań. Cały spis zadań maturalnych z tego działu jest tutaj:
Zagadnienia z tego samego obszaru matury – warto je powtórzyć razem: