Systemy webowe. Protokół http. Transakcja webowa.
•Download as PPT, PDF•
0 likes•499 views
Systemy webowe. Protokół http. Transakcja webowa.
![[object Object],Protokół HTTP. ,[object Object],Paweł Łukasik 166761@student.pwr.wroc.pl ,[object Object]](data:image/gif;base64,R0lGODlhAQABAIAAAAAAAP///yH5BAEAAAAALAAAAAABAAEAAAIBRAA7)
Recommended
Recommended
More Related Content
Featured
Featured (20)
Systemy webowe. Protokół http. Transakcja webowa.
- 1. PROTOKÓŁ HTTP. TRANSAKCJA WEBOWA. WYDAJNOŚĆ I NIEZAWODNOŚĆ USŁUGI WWW.
- 4. Protokół HTTP. Paweł Łukasik 166761@student.pwr.wroc.pl Metody HTTP: GET HEAD PUT POST DELETE OPTIONS TRACE CONNECT
- 5. Protokół HTTP. Paweł Łukasik 166761@student.pwr.wroc.pl
- 6. Protokół HTTP. Paweł Łukasik 166761@student.pwr.wroc.pl Kody stanu i komunikaty protokołu HTTP Jednostka żądania zbyt duża 413 Użyj proxy 305 Nieobsługiwana wersja HTTP 505 Warunek wstępny nie powiódł się 412 Nie zmodyfikowany 304 Przeterminowanie bramy 504 Wymagana długość 411 Zobacz inny 303 Usługa niedostępna 503 Minęło 410 Znaleziony 302 Zła brama 502 Konflikt 409 Przeniesiony na stałe 301 Nie zaimplementowany 501 Przeterminowanie żądania 408 Wiele opcji 300 Wewnętrzny błąd serwera 500 Wymagane uwierzytelnienie proxy 407 Treść częściowa 206 Oczekiwanie nie powiodło się 417 Nie do przyjęcia 406 Resetuj treść 205 Żądany zakres nie do spełnienia 416 Metoda niedozwolona 405 Bez treści 204 Nieobsługiwana wersja HTTP 505 Nie znaleziony 404 Nie autorytatywny 203 Przeterminowanie bramy 504 Wzbroniony 403 Przyjęty 202 Usługa niedostępna 503 Wymagana opłata 402 Utworzony 201 Zła brama 502 Nieautoryzowany 401 OK 200 Nieobsługiwany typ nośnika 415 Złe żądanie 400 Przełączanie protokołów 101 URI żądania zbyt duży 414 Readresowanie tymczasowe 307 Kontynuuj 100 Komunikat Kod stanu Komunikat Kod stanu Komunikat Kod stanu
- 8. Transakcja webowa. Paweł Łukasik 166761@student.pwr.wroc.pl Transakcje statyczne.
- 9. Transakcja webowa. Paweł Łukasik 166761@student.pwr.wroc.pl Transakcje dynamiczne.
- 10. Transakcja webowa. Paweł Łukasik 166761@student.pwr.wroc.pl Transakcje bazodanowe.
- 11. Transakcja webowa. Paweł Łukasik 166761@student.pwr.wroc.pl Transakcje Aplikacji (Rich Client Asynchronus)
- 12. Wydajność i niezawodność usługi WWW. Paweł Łukasik 166761@student.pwr.wroc.pl Bezpieczeństwo w środowisku internetowym
- 13. Bibliografia. Paweł Łukasik 166761@student.pwr.wroc.pl Strony www: http://itpedia.pl/index.php/Web_services http://itpedia.pl/index.php/Klient-Serwer http://itpedia.pl/index.php/Dostęp_do_zasobów:_identyfikacja,_uwierzytelnianie_i_autoryzacja http://edu.pjwstk.edu.pl/wyklady http://pl.wikipedia.org/wiki/Protokoły_komunikacyjne http://pl.wikipedia.org/wiki/Hypertext_Transfer_Protocol http://www.users.pjwstk.edu.pl/~s3452/prezentacja/html/http.html http://www.securitum.pl/baza-wiedzy/publikacje/audyt-bezpieczenstwa-aplikacji-www http://www.securitum.pl/baza-wiedzy/publikacje/testy-penetracyjne-aplikacji-www http://www.slideshare.net/fulvio.corno/web-transactions
Editor's Notes
- Systemy webowe. Temat : Protokół HTTP. Transakcja webowa. Wydajność i niezawodność usługi WWW. Opracowanie : Paweł Łukasik, 166761@student.pwr.wroc.pl
- Zacznijmy od tego czym jest protokół? W najbardziej ogólnym sensie jest to zestaw regół umożliwiających porozumienie. Natomiast w sensie technicznym jest to ścisła specyfikacja automatycznych działań jakie podejmują urządzenia komunikacyjne takie jak : faksy, modemy, komputery, itp. aby ustanowić między sobą połączenie a następnie móc przekazywać dane. Dzięki temu, ż e połączenia odbywają się całkowicie automatycznie, użytkownicy nie muszą o nich nic wiedzieć. Protokoły służące do komunikowanie się przez internet są określone przez IETF(Internet Engineering Task Force) w dokumentach RFC (Request for Comments). Co oznacza HTTP ? Gdzie można znaleźć definicję protokołu http ? HTTP (ang. Hypertext Transfer Protocol) to protokół sieci WWW (ang. World Wide Web). Obecną definycję można znaeżć w RFC 2616.
- Jak to się dzieje ? Za pomocą protokołu HTTP przesyła się żądania udostępnienia dokumentów WWW i informacje o kliknięciu odnośnika oraz informacje z formularzy. Zadaniem stron WWW jest publikowanie informacji - natomiast protokół HTTP właśnie to umożliwia. Protokół HTTP określa formę żądań klienta dotyczących danych oraz formę odpowiedzi serwera na te żądania. Jest zaliczany do protokołów bezstanowych (ang. stateless) z racji tego, że nie zachowuje żadnych informacji o poprzednich transakcjach z klientem (po zakończeniu transakcji wszystko "przepada"). Pozwala to znacznie zmniejszyć obciążenie serwera, jednak jest kłopotliwe w sytuacji, gdy np. trzeba zapamiętać konkretny stan dla użytkownika, który wcześniej łączył się już z serwerem. Częstym rozwiązaniem tego problemu jest wprowadzenie mechanizmu cookies. Inne podejścia to m.in. sesje po stronie serwera.
- Interakcja przeglądarki z serwerem WWW odbywa się według modelu bezpołączeniowego: (1)żądanie jest wysyłane przez klienta, (2)Serwer przekazuje (zawsze z inicjatywy klienta) żądane zasoby lub informacja o ich niedostępności, (3)połączenie zostaje zamknięte. Protokół określa format żądania oraz odpowiedzi. Należy podkreślić, że zakres funkcjonalności protokołu HTTP znacząco wykracza poza samo pobieranie zasobów znajdujących się na serwerze. Między innymi, projektanci przewidzieli obsługę poprzez żądania HTTP pełnego zestawu operacji "CRUD" (czyli Create, Retrieve, Update, Delete ), definiując odpowiednie metody żądań: GET — pobiera informacje (w formie jednostki) zidentyfikowane przez URI, do którego zostało zgłoszone żądanie. Jeżeli URI zidentyfikuje proces wytwarzający dane, to wytworzone dane zostaną zwrócone jako jednostka. Warunkowy komunikat GET zawiera pole nagłówka If-Modified-Since, If-Unmodified-Since, If-Match, If-None-Match, lub If-Range. Pozwala to na odświeżanie buforowanych jednostek bez potrzeby wielokrotnego przesyłu, czy żądania danych, które są już w posiadaniu klienta. GET częściowy żąda, aby przesłana została tylko część jednostki, określona przez pole nagłówka Range. HEAD — identyczny z GET, z tym że serwer nie zwraca w odpowiedzi treści komunikatu. Metoda ta uzyskuje informacje dotyczące jednostki nie przesyłając samej treści jednostki i jest wykorzystywana do testowania ważności, dostępności oraz niedawnych modyfikacji łączy hipertekstowych. PUT — żąda, aby jednostka załączona w żądaniu została zapamiętana pod URI, do którego zostało zgłoszone żądanie. Jeżeli dany zasób wspomniany w URI już istnieje, to przesyłaną jednostkę uznaje się za wersję zmodyfikowaną. Jeżeli URI nie wskazuje na istniejący zasób, a żądający użytkownik może zdefiniować URI jako nowy zasób, to zasób jest tworzony na serwerze. POST — żąda, aby serwery przyjmowały jednostkę załączoną w żądaniu, jako nowego podwładnego zasobu zidentyfikowanego przez URI, do którego zostało zgłoszone żądanie (podobnie, jak mówi się, że plik umieszczony w katalogu jest nowym podwładnym tego katalogu). POST jest wykorzystywany do przypisywania zasobów, do wysyłania komunikatów (na przykład do elektronicznego biuletynu informacyjnego), do przedkładania danych formularzy oraz do rozszerzania bazy danych poprzez operację dołączania. Funkcja pełniona przez metodę POST określana jest przez serwer i zazwyczaj jest uzależniona od URI. DELETE — żąda, aby serwer usunął zasób zidentyfikowany przez URI. OPTIONS — pozwala klientowi ustalić opcje i/lub wymagania związane z danym zasobem, albo możliwości danego serwera, nie implikując działań zasobu i nie inicjując pobierania zasobu. TRACE — wywołuje zdalną pętlę zwrotną komunikatu żądania. Ostateczny odbiorca żądania odbija otrzymany komunikat z powrotem do klienta. TRACE pozwala klientowi zobaczyć co jest odbierane na drugim końcu łańcucha żądania. Informacja ta może być wykorzystywana do testowania, lub znajdywania uszkodzeń. CONNECT — nazwa metody zarezerwowana do wykorzystywania wraz z proxy, który może dynamicznie przełączyć się na pełnienie funkcji tunelu, przy użyciu, na przykład, tunelowania z wykorzystaniem warstwy zabezpieczeń łączy (SSL). Proxy to program pośredniczący, pełniący zarówno funkcję serwera, jak i klienta, w celu zgłaszania żądań w imieniu innych klientów. (Metoda CONNECT nie jest częścią standardu HTTP/1.1, jednak jest powszechnie implementowana na podstawie dokumentu internet-draft wygasłego w 1999 roku ) Przykład zapytania i odpwiedzi w protokole HTTP.
- Przykład zapytania i odpwiedzi w protokole HTTP.
- Kody stanu HTTP są wykorzystywane przez metody podczas normalnej pracy, albo wysyłane do użytkownika, jeżeli wystąpi błąd. Jest pięć klasyfikacji kodów stanu: Informacyjny (1xx) — sygnalizuje prowizoryczną (zazwyczaj pośrednią) odpowiedź. Te kody wskazują, że dana metoda przebiega normalnie i miało miejsce oczekiwane zdarzenie. Jeżeli serwer protokołu HTTP 1.1 wykryje klienta protokołu HTTP 1.0, to nie będzie wysyłał komunikatów informacyjnych, ponieważ nie są one zdefiniowane dla HTTP 1.0. Pomyślny (2xx) — sygnalizuje, że żądanie klienta zostało pomyślnie otrzymane, zrozumiane i przyjęte. Readresowanie (3xx) — sygnalizuje, że agent użytkownika musi podjąć dalsze działania, aby spełnić żądanie. Działania te mogą być przeprowadzane automatycznie przez agenta użytkownika (jeżeli wykorzystywaną metodą jest GET, lub HEAD) albo mogą wymagać interwencji użytkownika. Błąd klienta(4xx) — sygnalizuje, że występuje, lub wydaje się, że występuje, błąd klienta. Za wyjątkiem przypadku odpowiadania na żądanie HEAD, komunikat zawiera wyjaśnienie błędu i informuje użytkownika, czy jest on tymczasowy, czy stały. Błąd serwera (5xx) — sygnalizuje, że serwer zdaje sobie sprawę, iż wygenerował błąd, albo że nie jest w stanie wykonać żądania. Za wyjątkiem przypadku odpowiadania na żądanie HEAD, komunikat zawiera wyjaśnienie błędu i informuje użytkownika, czy jest on tymczasowy, czy stały.
- Czym są transakcje webowe ? Jeżeli przeanalizujemy technologie jakie są obecnie używane to możemy wyróżnić kilka głównych grup: Serwisy statyczno-informacyjne, Dynamiczne i interaktywne, Zintegrowane Zorientowane na aplikacje (Rich Client Asynchronus)
- Transakcje statyczne adobtują takie standardy jak: URL (uniform resource locator) - do odnajdywania stron internetowych. HTML – do pisania dokumentów. GIF/JPEG/PNG – do publikowania obrazów. HTTP – do interakcji klient/serwer TCP/IP – do przesyłu danych
- Transakcje dynamiczne adobtują takie standardy jak: HTTP-POST – do przesyłania danych użytkownika, CGI (Common Gateway Interface), ISAPI (Internet Information Server Application Programming Interface), Server-Side script java servlet do zintegrowania logiki biznesowej na serwerze. 3.ASP (Active Server Pages) PHP, PERL – jako nowe języki do tworzenia aplikacji webowych
- Transakcje bazodanowe adobtują takie standardy jak: Cookies – do przechowywania stanu sesji, Java, Java-Script, ActiveX, Flash – do programowania interfejsów użytkownika w przeglądarce, SQL (Structured Query Language), ODBC (Open DataBase Connectivity) – celem dostępu do bazy danych.
- Transakcje aplikacji adobtują takie standardy jak: Dynamiczny HTML : DOM, JavaScript, CSS - JavaScript, Flash (ActionScript) – do obsługi środowiska strony w przeglądarce - DOM (XHTML Document Object Model) – do obsługi modyfikacji na stronie wywyołanych przez użytkownika w locie, - CSS 2.1 – do modyfikowania atrybutów i obługi obiektów 2. AJAX : Asynchronus Javascript and XML - XMLHttpRequest – do komunikacji asynchronicznej z serwerem - Formaty przenoszonych danych : JSON(JavaScript Object Notation), XML, RSS, ...
- Stuprocentowe zabezpieczenie systemu wymagałoby fizycznego odizolowania go od wszelkich potencjalnych intruzów. W wypadku oprogramowania działającego w Internecie z założenia trzeba ów dostęp dopuścić. Dla aplikacji internetowych należy wyróżnić trzy elementy wraz ze specyficznymi dlań rodzajami zagrożeń: - Serwer - Komputer klienta - Łącze sieciowe Analizując zagrożenia należy uwzględnić zarówno niedoskonałości techniczne wykorzystywanych rozwiązań jak i czynnik ludzki. Zagrożenia po stronie serwera mogą wynikać z: - Niedoskonałości oprogramowania serwera (luki w bezpieczeństwie) - Niewłaściwej jego konfiguracji - Nieprzemyślanych rozwiązań w kodzie stron WWW Ryzyko ograniczy wyłączenie wszelkich nieużywanych opcji. Np. starsze rozwiązania technologii dynamicznych jak np. CGI uchodzą za szczególnie podatne na powstawanie takich luk. Jeśli nasza aplikacja ich nie wykorzystuje - warto wyłączyć ich wsparcie w konfiguracji serwera WWW. Podstawowym zagrożeniem po stronie serwera jest nieuprawniony dostęp do danych zgromadzonych przez aplikację WWW. Istotnym sposobem ochrony serwera pracującego na potrzeby sieci wewnętrznej jest użycie zapory (firewall). Należy pamiętać o aktualizacjach oprogramowania, celem łatania znanych luk (informacje o nich są upowszechniane, z czego mogą skorzystać także intruzi!). Dotyczy to zarówno bezpieczeństwa serwera jak i oprogramowania klienta.