[WAI] usługi sieciowe

• elementy "budujące" technologię Web Service:
• SOAP - protokół komunikacyjny;
• służy do przekazywania zdalnych wywołań;
• WSDL - język opisu interfejsu usługi;
• służy do dystrybucji parametrów połączeń sieciowych;
• UDDI - specyfikacja bazy danych
• służy do rejestracji udostępnianych komponentów usługowych

• cykl życia WS:
1. serwer-wytwórca rejestruje usługę na zasobie UDDI (informacja na temat serwisu i providera);
2. klient wyszukuje usługę w rejestrze UDDI;
3. rejestr UDDI zwraca klientowi listę usług ze wskazaniem na zasoby WSDL;
4. klient wysyła żądanie pobrania definicji usługi (pobiera WSDL) pod URL otrzymany od UDDI - kieruje się na serwer;
5. serwer zwraca plik WSDL (z definicją usługi w formacie XML);
    - na podstawie tego pliku wytworzona może być aplikacja: klient usługi WS (Aplikacja obsługująca WS);
6. wywołanie WS - klient łączy się z servisem używając protokołu SOAP/HTTP(S);
7. serwer zwraca klientowi rezultaty wywołania serwisu

Zabezpieczanie usług sieciowych z wykorzystaniem HTTP Basic Authentication
oraz HTTPS
1. Wprowadzenie
Celem niniejszego laboratorium jest zabezpieczenie usług sieciowych dostępnych
na serwerze za pomocą mechanizmów HTTP Basic Authentication oraz HTTPS ([2], [1]).
Wywołanie metody dostępnej w ramach usługi sieciowej zainstalowanej na serwerze np.
Tomcat/AXIS jak pokazano w ćwiczeniu 4, następuje z wykorzystaniem protokołu SOAP,
w   którym   zakodowane   są   argumenty   wejściowe   jak   i   wyniki   działania   metody.   Do
przekazania danych pomiędzy klientem a serwerem wykorzystywany jest protokół HTTP.
Z punktu widzenia zabezpieczenia usługi rodzi to następujące problemy:
1. Klient nie jest identyfikowany, wywołania metody tej samej usługi przez np. różne osoby
nie   są   rozróżniane.   Stąd   niemożliwe   staje   się   np.   naliczanie   opłat   za   wywołanie
metody.
2. Argumenty   wejściowe   i   wyjściowe   metody   przekazywane   są   z   wykorzystaniem
protokołu   HTTP,   nie   są   więc   szyfrowane   co   potencjalnie   umożliwia   podsłuchanie
komunikacji pomiędzy klientem a serwerem.
W ramach przykładów, które rozwiążą ww. kwestie, wykorzystany zostanie serwer
Tomcat/AXIS, który pozwoli na zainstalowanie usługi sieciowej napisanej w Javie.
Podstawowa   konfiguracja   serwera   Tomcat/AXIS   jak   również   kod   klienta
wywołującego  metodę usługi sieciowej i jego  kompilacja  i uruchomienie  były  tematem
laboratorium   nr   1.   Na   potrzeby   tego   laboratorium   zakładamy,   że   pracujemy   jako
użytkownik  student  z  katalogiem domowym /home/student. Zakładamy,  że  treść  pliku
~/.bashrc zawiera konfigurację dla AXIS 1.4 i Javy (należy zmienić katalog na dystrybucję
Javy jeśli jest inna).
 export JAVA_HOME=/usr/local/jdk1.5.0_07
export AXIS_HOME=/home/student/axis­1_4
export AXIS_LIB=$AXIS_HOME/lib
export AXISCLASSPATH=$AXIS_LIB/axis.jar:$AXIS_LIB/axis­ant.jar:$AXIS_LIB/commons­discovery­0.2.jar:$AXIS_LIB/commons­logging­1.0.4.jar:\
$AXIS_LIB/jaxrpc.jar:$AXIS_LIB/saaj.jar:$AXIS_LIB/log4j­1.2.8.jar:
$AXIS_LIB/wsdl4j­1.5.1.jar
#export AXIS_HOME=/usr/local/axis­1_1
#export AXIS_LIB=$AXIS_HOME/lib
#export AXISCLASSPATH=$AXIS_LIB/axis.jar:$AXIS_LIB/commons­discovery.jar:
$AXIS_LIB/commons­logging.jar:$AXIS_LIB/jaxrpc.jar:$AXIS_LIB/s\
aaj.jar:$AXIS_LIB/log4j­1.2.8.jar:$AXIS_LIB/xml­apis.jar:$AXIS_LIB/xercesImpl.jar:
$AXIS_LIB/wsdl4j.jar                                
export CLASSPATH=$CLASSPATH:$AXISCLASSPATH
export PATH=$JAVA_HOME/bin:$PATH
Zakładamy   ponadto,   że   serwer   Tomcat   został   zainstalowany   w   katalogu
/home/student/apache­tomcat­5.5.28   jak   również   podkatalog   webapps/axis   dystrybucji
AXIS został skopiowany do katalogu webapps serwera Tomcat.
2. Wykorzystanie mechanizmu HTTP Basic Authentication
Mechanizm ten umożliwia wymuszenie zalogowania się przez klienta na serwerze
poprzez podanie loginu użytkownika oraz hasła. Niestety, login i hasła nie są szyfrowane
w   sposób   uniemożliwiający   ich   odczytanie.   Mechanizm   ten   pozwala   jednak   na
identyfikację   użytkownika   przy   założeniu,   iż   różni   użytkownicy   dysponują   różnymi
identyfikatorami użytkownika w postaci ciągu znaków login.
Ww.   sposób   wymaga   konfiguracji   serwera   w   postaci   określenia   użytkowników,
którzy mogą się do systemu logować, a w szczególności:
Login,   hasło   oraz   rolę   użytkownika   w   postaci   linii   w   pliku   /home/student/apache­
tomcat­5.5.28/conf/tomcat­users.xml:
<?xml version='1.0' encoding='utf­8'?>
<tomcat­users>
  <role rolename="tomcat"/>
  <role rolename="role1"/>
  <role rolename="runtaskuser"/>
  <user username="tomcat" password="tomcat" roles="tomcat"/>
  <user username="both" password="tomcat" roles="tomcat,role1"/>
  <user username="role1" password="tomcat" roles="role1"/>
  <user username="runtaskuser" password="uio9" roles="runtaskuser"/>
</tomcat­users>
Zdefiniowano  użytkownika runtaskuser, określono  hasło  oraz  rolę, do której referencja
występuje z kolei w pliku katalogu systemu AXIS tj.:
/home/student/apache­tomcat­5.5.28/webapps/axis/WEB­INF/web.xmlW pliku tym, na końcu elementu </web­app> należy zdefiniować URL, który obejmować
będzie rola określona powyżej poprzez umieszczenie np.:
<security­constraint>
    <web­resource­collection>
        <web­resource­name>RunTaskApplication</web­resource­name>
        <url­pattern>/*</url­pattern>
    </web­resource­collection>
    <auth­constraint>
        <role­name>runtaskuser</role­name>
    </auth­constraint>
</security­constraint>
<login­config>
    <auth­method>BASIC</auth­method>
    <realm­name>RunTask Application</realm­name>
</login­config>
login­config określa metodę identyfikacji użytkownika, web­resource­collection określa
zbiór  adresów URL (w tym przypadku  wszystkie strony  w danym katalogu systemu
AXIS), auth­constraint określa rolę, dla której zezwala się na dostęp do podanego URL.
Należy zauważyć, iż kod metod usługi sieciowej nie odwołuje się do roli, która ma dostęp
do usługi, uprawnienia są więc w tym przypadku elementem konfiguracji serwera.
Kod usługi sieciowej, wykorzystywany w niniejszej instrukcji, umożliwia uruchomienie na
serwerze polecenia podanego jako argument:
import java.io.*;

public class RunTaskServer {
  public int RunTask(String taskname)
  {
      try {
          Process p = Runtime.getRuntime().exec(taskname);
      } catch (IOException e1) {
          System.err.println(e1);
          System.exit(1);
      }
      return 0;
  }
}
Kod klienta wywołujący metodę podaną powyżej i zainstalowaną jako plik JWS (Java Web
Service)   w   katalogu   /home/student/apache­tomcat­5.5.28/webapps/axis/RunTaskServer.jws, uzupełniony jest o zdefiniowanie loginu i
przekazanie hasła w celu uwierzytelnienia na serwerze:
import org.apache.axis.client.Call;
import org.apache.axis.client.Service;
import org.apache.axis.encoding.XMLType;
import org.apache.axis.utils.Options;
import javax.xml.rpc.ParameterMode;
public class RunTaskClient
{
   public static void main(String [] args) throws Exception {
     
       Options options = new Options(args);
       String endpoint = "http://localhost:" + options.getPort() +
                         "/axis/RunTaskServer.jws";
       args = options.getRemainingArgs();
       String method = "RunTask";
       String s1 = new String(args[0]);
       Service  service = new Service();
       Call     call    = (Call) service.createCall();
       call.setTargetEndpointAddress( new java.net.URL(endpoint) );
       call.setOperationName( method );
       call.addParameter( "op1", XMLType.XSD_STRING, ParameterMode.IN );
       call.setReturnType( XMLType.XSD_INT );
       call.setUsername("runtaskuser");
       call.setPassword("uio9");      
       Integer ret=(Integer) call.invoke( new Object [] { s1 });
       System.out.println("Got result : " + ret);
   }
}
3. Wykorzystanie HTTPS do wywołania metody usługi sieciowej
Protokół   HTTPS   (HTTP+SSL)   pozwala   na   szyfrowanie   komunikacji   pomiędzy
klientem a serwerem, nie zachodzi więc obawa o podejrzenie przesyłanych danych przez
osoby   postronne.   Protokół   HTTPS   wykorzystuje   techniki   kryptografii   asymetrycznej   i
symetrycznej.
Konfiguracja   serwera   Tomcat   do   obsługi   HTTPS   sprowadza   się   do
odkomentowania odpowiednich deklaracji w pliku konfiguracyjnym /home/student/apache­
tomcat­5.5.28/conf/server.xml:
    <Connector port="8443" maxHttpHeaderSize="8192"
               maxThreads="150" minSpareThreads="25" maxSpareThreads="75"
               enableLookups="false" disableUploadTimeout="true"
               acceptCount="100" scheme="https" secure="true"
               clientAuth="false" sslProtocol="TLS" />
 
Tomcat   obsługiwać   będzie   odtąd   zgłoszenia   na   porcie   8080   oraz   8443   (domyślnie),
ostatnie z wykorzystaniem HTTPS.
Konfiguracja  klienta  usługi sieciowej, która  ma być wywołana  z  wykorzystaniem
HTTPS sprowadza się do ustawienia odpwiedniego adresu URL (HTTPS zamiast HTTP)
oraz wskazania odpowiedniego pliku keystore (certyfikat SSL), który umożliwi szyfrowaną
komunikację pomiędzy klientem a serwerem. Wygenerowanie pliku (jednego w przypadku
klienta i serwera na tej samej maszynie) sprowadza się do wywołania:
keytool -genkey -alias tomcat -keyalg RSA
Domyślne hasło to  changeit. Dodatkowe elementy  kodu klienta, które należy  umieścić
przed wywołaniem metody usługi sieciowej to:
       String endpoint = "https://localhost:8443/axis/RunTaskServer.jws";       System.setProperty("javax.net.ssl.trustStore",
                          "/home/student/.keystore");
4. Połączenie metod HTTP Basic Authentication oraz szyfrowanej transmisji HTTPS
Wyżej   wymienione   techniki   mogą   zostać   połączone   ze   sobą   w   celu   zapewnienia
identyfikacji użytkownika oraz szyfrowania transmisji danych. Należy przeprowadzić kroki
konfiguracji   serwera   dla   obu   wymienionych   metod   oraz   zmodyfikować   kod   klienta   z
elementami pokazanymi wyżej dla obu wymienionych metod.
Pomimo  tego, iż  użytkownik  został  zidentyfikowany  na  podstawie  loginu  i  hasła  oraz
stosowana jest komunikacja szyfrowana, serwer nie może mieć absolutnej pewności co
do tożsamości klienta tj. nie wie, kim faktycznie jest klient o danym loginie i haśle. W
praktyce   sklepy   internetowe   często   nie   rozwiązują   tego   problemu   zakładając,   iż
użytkownik zakładając konto w sklepie o danym loginie i haśle podaje również poprawne
dane osobowe oraz adres, pod który wysyłany jest następnie towar np. za zaliczeniem
pocztowym. Z reguły, używana jest szyfrowana transmisja HTTPS, zaś sama identyfikacja
użytkownika następuje na poziomie aplikacji poprzez przekazanie loginu i hasła np. przez
pola formularza.
Java   posiada   odpowiednie   API,   które   pozwala   na   implementację   podpisu   cyfrowego
danych oraz weryfikację podpisu. Klient generuje klucze prywatny i publiczny, następnie
podpisuje   dane   z   użyciem   klucza   prywatnego,   przekazuje   dane   wraz   z   podpisem   i
kluczem publicznym do weryfikacji serwerowi, który jest w stanie stwierdzić, czy podpis
faktycznie odnosi się do danych, które zostały przekazane. Serwer musi mieć pewność, iż
klucz publiczny należy do określonego klienta. Certyfikat klienta zawierać będzie klucz
publiczny. Certyfikat będzie podpisany przez jednostkę certyfikującą, która potwierdza, iż
klucz   publiczny   należy   do   określonego   klienta.   API   oraz   przykłady   Javy   odnośnie
podpisów cyfrowych można znaleźć w [3] i [4].
Przykładowy   klient   wykorzystujący   HTTP   Basic   Authentication   oraz   HTTPS   ma
następującą postać:
import org.apache.axis.client.Call;
import org.apache.axis.client.Service;
import org.apache.axis.encoding.XMLType;
import org.apache.axis.utils.Options;
import javax.xml.rpc.ParameterMode;
public class RunTaskClientHTTPSBASIC
{
   public static void main(String [] args) throws Exception {
     
       Options options = new Options(args);      
       String endpoint = "https://localhost:8443/axis/RunTaskServer.jws";
       System.setProperty("javax.net.ssl.trustStore",
  "/home/student/.keystore");
     
       args = options.getRemainingArgs();
       String method = "RunTask";
       String s1 = new String(args[0]);
       Service  service = new Service();
       Call     call    = (Call) service.createCall();
       call.setTargetEndpointAddress( new java.net.URL(endpoint) );
       call.setOperationName( method );
       call.addParameter( "op1", XMLType.XSD_STRING, ParameterMode.IN );
       call.setReturnType( XMLType.XSD_INT );
       call.setUsername("runtaskuser");
       call.setPassword("uio9");
       Integer ret=(Integer) call.invoke( new Object [] { s1 });
       System.out.println("Got result : " + ret);
     
   }
}
Uwaga:
można również testować wywołanie usługi sieciowej za pomocą przeglądarki wywołując
np.:
https://localhost:8443/axis/RunTaskServer.jws?method=RunTask&taskname=emacsLiteratura
1. AXIS User's Guide. http://ws.apache.org/axis/java/user­guide.html
2.   Gopalakrishnan   U,   Rajesh   Kumar   Ravi,   Web   services   security,   Part   I,
http://www­106.ibm.com/developerworks/webservices/library/ws­sec1.html
3.     Thomas   Gutschmidt   Introduction   to   Digital   Signatures   in   Java,
http://www.developer.com/java/other/article.php/630851
4. The   Java
TM
  Tutorial,   Trail:   Security   in   Java   2   SDK   1.2,   Lesson:   Generating   and
Verifying   Signatures,
http://java.sun.com/docs/books/tutorial/security1.2/apisign/index.html

[WAI] serwlety

Struktura serwletu


public class Repository extends HttpServlet {

   @Override
   public void init() throws ServletException {
     super.init();
   }

   @Override
   protected void doGet(HttpServletRequest request, HttpServletResponse response
   throws ServletException, IOException {
    // 
   }


   @Override
   protected void doPost(HttpServletRequest request, HttpServletResponse response
   throws ServletException, IOException {
    // 
   }
}




Podstawowe metody serwletu:
• init – inicjalizacja serwletu, wywoływana przy jego pierwszym uruchomieniu,
• doGet – obsługa żądań GET,
• doPost – obsługa żądań POST.

Parametry żądania i odpowiedzi:
• HttpServletRequest – dostarcza informacje na temat żądania:
◦ String getParameter(String name) – zwraca wartość parametru żądania,
• HttpServletResponse – dostarcza informacje na temat odpowiedzi.

[PT] zasady zaliczenia

1. Każdy student otrzymuję arkusz egzaminacyjny z pytaniami (20 - 25 pytań).

2. Część pytań wymaga odpowiedzi słownych, inne wymagają wskazania poprawnych odpowiedzi spośród kilku podanych,np. a., b., c.

3. Za poprawną odpowiedź za każde pytanie uzyskuje się 1 pkt.

4. Jeśli poprawna odpowiedź na pytanie wymaga zaznaczenia np. trzech odpowiedzi spośród pięciu, to zaznaczenie tylko dwóch odpowiedzi jest zaliczane jako 2/3 pkt.

5. Zaznaczenie błędnej odpowiedzi powoduje odjęcie 0.5 pkt. Nie stosuje się punktów ujemnych - najniższa punktacja wynosi 0 pkt.



Pytania przykładowe:

1. Mechanizm AutoPostBack na platformie .NET pozwala na :
  a. Wykorzystanie wbudowanego mechanizmu wykonywania kopii bazy
     danych
  b. Automatyczne ustanawianie sesji
  c. Automatyczne wysyłanie żądania do serwera po zmianie stanu
     obiektu w przeglądarce
  d. Automatyczne logowanie użytkownika w  oparciu o mechanizm MS
     Passport

2. Komponenty zarządzane (określane także jako beany zarządzane) są
  to klasy Javy odpowiedzialne za  . . . . . . . . . . . . . .
  aplikacji JSF.

3. W strukturze pliku wykonywalnego (.exe) przeznaczonego dla
  środowiska .NET można wyróżnić następujące elementy:
  a. Pieniek wspólnego środowiska uruchomienia
  b. Skonsolidowany  zbiór z  zasobami (np. rysunkami)
  c. Kod funkcji importowanych
  d. Maszynę wirtualną CLR

4. Omówić rodzaje i przeznaczenie warstw w Java EE.

5. Omówić cykle życia komponentów (beanów) EJB.

6. Wyjaśnić na czym polega różnica między transakcjami zarządzanymi
  przez komponent (bean) i przez kontener EJB.

[WAI] egzamin opracowanie pytań

• wyjaśnij różnice pomiędzy ciasteczkami a obiektem sesji
  
  SESJE
• PHP udostępnia mechanizm śledzenia sesji zwany popularnie po prostu sesjami. 
• To, w jaki sposób przechowywane są dane sesji (czy po stronie serwera, czy w przeglądarce), uzależnione jest od konfiguracji PHP. Zwykle jednak pozostawia się konfigurację...
• Sesja może zostać uruchomiona na trzy sposoby: 
• automatycznie – jeżeli opcja session.auto_start w konfiguracji jest ustawiona na jeden; 
• jawnie – poprzez wywołanie funkcji session_start() ;
• niejawnie – poprzez wywołanie funkcji session_register() ;
  
  materiały od Czarnula:
• Sesja
• Sesja jest obiektem klasy HttpSession. Może zostać pobrana np. poprzez wywołanie odpowiedniej metody na obiekcie żądania: request.getSession().
• Podstawowe operacje na obiekcie sesji:
• Object getAttribute(String name) – pobranie obiektu z sesji,
• void setAttribute(String name, Object obj) – dodanie obiektu do sesji,
• void invalidate() - zniszczenie obiektu sesji,
• void removeAttribute(String name) – usunięcie obiektu z sesji.

           CIASTECZKA

• Ciasteczka (ang. cookies) to mechanizm pozwalający na zapamiętywanie po stronie klienta (przez przeglądarkę) danych wysłanych przez stronę WWW.
•  Ciasteczka charakteryzują się różnym czasem trwałości — można tworzyć ciasteczka, których ważność wygasa...

z netu:

1. You don't need login/logout mechanisms in order to have sessions.
2. In java servlets, HTTP sessions are tracked using two mechanisms, HTTP cookie (the most commonly used) or URL rewriting (to support browser without cookies or with disabled cookies). Using only cookies is simple, you don't have to do anything special. For URL re-writing, you need to modify all URLs pointing back to your servlets/filters.
3. Each time you call request.getSession(true), the HttpRequest object will be inspected in order to find a session ID encoded either in a cookie OR/AND in the URL path parameter (what's following a semi-colon). If the session ID cannot be found, a new session will be created by the servlet container (i.e. the server).
4. The session ID is added to the response as a Cookie. If you want to support URL re-writing also, the links in your HTML documents should be modified using the response.encodeURL() method. Calling request.getSession(false) or simply request.getSession() will return null in the event the session ID is not found or the session ID refers to an invalid session.
5. There is a single HTTP session by visit, as Java session cookies are not stored permanently in the browser. So sessions object are not shared between clients. Each user has his own private session.
6. Sessions are destroyed automatically if not used for a given time. The time-out value can be configured in the web.xml file.
7. A given session can be explicitly invalidated using the invalidate() method.
8. When people are talking about JSESSIONID, they are referring to the standard name of the HTTP cookie used to do session-tracking in Java.

The servlet container (for example Tomcat) takes care of this utilizing its JSESSIONID.
The story goes like this :

1. User first logs onto website.
2. Servlet container sets a COOKIE on the user's browser, storing a UNIQUE jsessionId.
3. Every time the user hits the website, the JSESSIONID cookie is sent back.
4. The servlet container uses this to keep track of who is who.
5. Likewise, this is how it keeps track of the separation of data. Every user has their own bucket of objects uniquely identified by the JSESSIONID.

[Z THINKING IN ENTERPRISE JAVA]

Handling sessions with servlets

HTTP is a “sessionless” protocol, so you cannot tell from one server hit to another if you’ve got the same person repeatedly querying your site, or if it is a completely different person. A great deal of effort has gone into mechanisms that will allow Web developers to track sessions. Companies could not do e-commerce without keeping track of a client and the items they have put into their shopping cart, for example.

There are several methods of session tracking, but the most common method is with persistent “cookies,” which are an integral part of the Internet standards. The HTTP Working Group of the Internet Engineering Task Force has written cookies into the official standard in RFC 2109 (ds.internic.net/rfc/rfc2109.txt or check www.cookiecentral.com).

A cookie is nothing more than a small piece of information sent by a Web server to a browser. The browser stores the cookie on the local disk, and whenever another call is made to the URL that the cookie is associated with, the cookie is quietly sent along with the call, thus providing the desired information back to that server (generally, providing some way that the server can be told that it’s you calling). Clients can, however, turn off the browser’s ability to accept cookies. If your site must track a client who has turned off cookies, then another method of session tracking (URL rewriting or hidden form fields) must be incorporated by hand, since the session tracking capabilities built into the servlet API are designed around cookies.

The Cookie class

The servlet API (version 2.0 and up) provides the Cookie class. This class incorporates all the HTTP header details and allows the setting of various cookie attributes. Using the cookie is simply a matter of adding it to the response object. The constructor takes a cookie name as the first argument and a value as the second. Cookies are added to the response object before you send any content.

Cookie oreo = new Cookie("TIJava", "2002");

res.addCookie(oreo);

Cookies are recovered by calling the getCookies( ) method of the HttpServletRequest object, which returns an array of cookie objects.

Cookie[] cookies = req.getCookies();

You can then call getValue( ) for each cookie, to produce a String containing the cookie contents. In the above example, getValue("TIJava") will produce a String containing “2002.”

The Session class

A session is one or more page requests by a client to a Web site during a defined period of time. If you buy groceries online, for example, you want a session to be confined to the period from when you first add an item to “my shopping cart” to the point where you check out. Each item you add to the shopping cart will result in a new HTTP connection, which has no knowledge of previous connections or items in the shopping cart. To compensate for this lack of information, the mechanics supplied by the cookie specification allow your servlet to perform session tracking.

A servlet Session object lives on the server side of the communication channel; its goal is to capture useful data about this client as the client moves through and interacts with your Web site. This data may be pertinent for the present session, such as items in the shopping cart, or it may be data such as authentication information that was entered when the client first entered your Web site, and which should not have to be reentered during a particular set of transactions.

The Session class of the servlet API uses the Cookie class to do its work. However, all the Session object needs is some kind of unique identifier stored on the client and passed to the server. Web sites may also use the other types of session tracking but these mechanisms will be more difficult to implement as they are not encapsulated into the servlet API (that is, you must write them by hand to deal with the situation when the client has disabled cookies).

Inside the service( ) method, getSession( ) is called for the request object, which returns the Session object associated with this request. The Session object does not travel across the network, but instead it lives on the server and is associated with a client and its requests.

getSession( ) comes in two versions: no parameter, as used here, and getSession(boolean). getSession(true) is equivalent to getSession( ). The only reason for the boolean is to state whether you want the session object created if it is not found. getSession(true) is the most likely call, hence getSession( ).

The Session object, if it is not new, will give us details about the client from previous visits. If the Session object is new then the program will start to gather information about this client’s activities on this visit. Capturing this client information is done through the setAttribute( ) and getAttribute( ) methods of the session object.

java.lang.Object getAttribute(java.lang.String)

void setAttribute(java.lang.String name,

java.lang.Object value)

The Session object uses a simple name-value pairing for loading information. The name is a String, and the value can be any object derived from java.lang.Object. SessionPeek keeps track of how many times the client has been back during this session. This is done with an Integer object named sesspeek.cntr. If the name is not found an Integer is created with value of one, otherwise an Integer is created with the incremented value of the previously held Integer. The new Integer is placed into the Session object. If you use same key in a setAttribute( ) call, then the new object overwrites the old one. The incremented counter is used to display the number of times that the client has visited during this session.

getAttributeNames( ) is related to getAttribute( ) and setAttribute( ); it returns an enumeration of the names of the objects that are bound to the Session object. A while loop in SessionPeek shows this method in action.

You may wonder how long a Session object hangs around. The answer depends on the servlet container you are using; they usually default to 30 minutes (1800 seconds), which is what you should see from the ServletPeek call to getMaxInactiveInterval( ). Tests seem to produce mixed results between servlet containers. Sometimes the Session object can hang around overnight, but I have never seen a case where the Session object disappears in less than the time specified by the inactive interval. You can try this by setting the inactive interval with setMaxInactiveInterval( ) to 5 seconds and see if your Session object hangs around or if it is cleaned up at the appropriate time. This may be an attribute you will want to investigate while choosing a servlet container. 

•  Wyjaśnij metody podtrzymania sesji w komunikacji w Internecie z wykorzystaniem HTTP. (5pkt)

         Istnieją 3 sposoby na utrzymanie sesji

• Cookies 
• Ukryte pola formularza 
• Przepisywanie URL’a  
• [Serwlety]
• Będą używać  cookies jeśli to możliwe
• Będą przepisywać  URL jeśli nie ma Cookiem
• Klient wysyła do serwera żądanie. 
• Gdy sesja się rozpoczyna zostaje przypisane ID. 
• Dane sesji zapisywane są w pamięci, pliku lub BD. 
• Serwer wysyła odpowiedź a z nią id sesji (np. set cookie). 
• Przy kolejnych żądaniach serwer odczytuje ciasteczko. 
• Ciasteczko jest usuwane, jeśli upłynął czas jego ważności, bądź po wylogowaniu użytkownika.
   
• Jeśli nie ma włączonych cookies, to serwer przypisuje id sesji do adresu URL

33) Wyjaśnij znaczenie mechanizmu sesji. Podaj podstawowe mechanizmy utrzymywania sesji.

Sesja jest potrzebna, gdy serwer chce śledzić poczynania użytkownika (tzn. jego kolejne żądania):

- Utrzymywanie koszyka zakupów użytkownika

- Zapisywanie informacji o autoryzacji dostępu

-- Sesje są problemem dla serwerów HTTP 

-- Brak mechanizmu sesji HTTP (bezstanowość)

-- Współdzielenie sesji przez wszystkie przeglądarki (jednego typu)

Utrzymywanie sesji.

- Cookies

- Ukryte pola formularza 

- Przepisywanie URL’a 

- Serwlety

-- Będą używać  cookies jeśli to możliwe

-- Będą przepisywać  URL jeśli nie ma cookies 

Każda sesja ma unikalne ID. Gdy sesja się rozpoczyna zostaje przypisane ID. Każde następne „podzapytanie” musi przesyłać ID (przez cookie lub URL)

26) Jaka jest różnica w wywołaniu metod GET i POST ? Podaj przykłady użycia poszczególnych metod.

POST:

Przesłanie danych do zasobu o danym URI, dane w treści żądania

wysyła wszystkie dane z formularza przy pomocy nagłówków http

można przesyłać nieograniczoną ilość informacji

możliwość wysyłania plików na serwer

używany głównie do przesyłania danych z formularza html do skryptu cgi

GET:

Uzyskanie zasobu o danym URI

przesyła informacje do serwera doklejając je do adresu

nadaje się tylko do przesyłania małej ilości informacji, gdyż długość adresów jest ograniczona

• Wyjaśnij jak zabezpieczyć warstwę prezentacji aplikacji internetowej.
• sprawdzenie parametrów stron
• sprawdzenie parametrów w kontekście sekwencji wywołań (bardzo wiele możliwości)
• weryfikacja parametrów w kontekście wcześniej złożonego żądania
• usuwanie niebezpiecznych znaków z pól tekstowych itp. – możliwość np. przedłużenia zapytania SQL lub polecenia w Shellu etc.

• Podaj znane Ci standardy bezpieczeństwa wykorzystywane przez aplikacje internetowe.
• Uwierzytelnianie i autoryzacja w oparciu o serwery i aplikacje
• • Autentyfikacja jest procesem identyfikacji użytkownika w systemie komputerowym, a następnie weryfikacji jego tożsamości. 
  • Autoryzacja dotyczy nadania użytkownikowi określonych uprawnień.
• HTPPS
• HTTP-AUTH
• HTTP Basic Authentication:
• Mechanizm ten umożliwia wymuszenie zalogowania się przez klienta na serwerze poprzez podanie loginu użytkownika oraz hasła. 
• Niestety, login i hasła nie są szyfrowane w   sposób   uniemożliwiający   ich   odczytanie.   
• Mechanizm   ten   pozwala   jednak   na identyfikację   użytkownika   przy   założeniu,   iż   różni   użytkownicy   dysponują   różnymi identyfikatorami użytkownika w postaci ciągu znaków login.
• Ww.   sposób   wymaga   konfiguracji   serwera   w   postaci   określenia   użytkowników, którzy mogą się do systemu logować, a w szczególności:
• Login,   hasło   oraz   rolę   użytkownika   w   postaci   linii   w   pliku   /home/student/apache-tomcat­5.5.28/conf/tomcat­users.xml:

            <?xml version='1.0' encoding='utf­8'?> 

                 <tomcat­users> 

                   <role rolename="tomcat"/>   

                   <role rolename="role1"/> 

                   <role rolename="runtaskuser"/> 

                   <user username="tomcat" password="tomcat" roles="tomcat"/>

                   <user username="both" password="tomcat" roles="tomcat,role1"/>      

                   <user username="role1" password="tomcat" roles="role1"/> 

                   <user username="runtaskuser" password="uio9" roles="runtaskuser"/> 

                  </tomcat­users> 

[WAI] zagadnienia

1) Internet - pojęcie szerokie i niejednoznaczne.

Międzynarodowa sieć komputerowa łącząca inne sieci i komputery

z firm, uniwersystetów itp.

Globalny system informacyjny, który:

• jest logiczniepołączony w ramach przestrzeni unikalnych adresów bazującej na Internet Protocol (IP)lub jego rozszerzeniach i następcach,

• jest w staniezapewnić komunikację prz użyciu Transmission

Control Protocol/Internet Protocol (TCP/IP)lub jego rozszerzeniach i następcach oraz innych protokołów kompatybilnych z IP,

• zapewnia, używa lub udostępnia, publicznie lub prywatnie, usługi wysokiego poziomu oparte o komunikację i infrastrukturę tutaj opisaną

2) Wyzwania Internetu

• Zmierzch tradycyjnej gazety (w zasadzie już następuje) na rzecz gazet internetowych.

• Duże zmiany w organizacji telewizji

– telewizja interakcyjna,

– wideo na żądanie

– zanik licencji i przydziałów pasma (?)

• Duże zmiany w telefonii (przewiduje się całkowite zintegrowanie telefonii z Internetem) VoiceML

• Duże zmiany w organizacji i metodach nauczania

• Duże zmiany w organizacji i kontroli pracy (umożliwienie pracy w domu przy zapewnieniu pełnej kontroli ze strony pracodawcy)

– szansa dla niepełnosprawnych

• Handel, biznes, administracja oparte na Internecie

3) Modele przetwarzania

   Główne modele przetwarzania w Internecie

1. Klient - serwer

  Cechy usług:

•  Serwer usługi czeka na nawiązanie połączenia przez klienta
• Wiele klientów może korzystać z usługi 
• Komunikacja w ramach usługi opiera się o powszechnie znany, standardowy 
• Do usługi przypisany jest domyślny port, lub zestaw portów, na których nasłuchuje serwer

  Przykładowe usługi:

• Poczta elektroniczna - protokoły SMTP, POP3, 
• Repozytoria plików - protokół 
• World Wide Web (WWW) - protokół 
• Istnieją różne warianty usług, np. bezpieczne, szyfrowane wersje

2. Klient - pośrednik - serwer

  Cechy usług:

•  Klient łączy się z pośrednikiem w celu wydobycia informacji o 
• Konieczna znajomość lokalizacji 
• Pośrednik odsyła konieczne informacje o serwerze do 
• Klient łączy się z 
• Komunikacja w ramach usługi opiera się o powszechnie znany, standardowy protokół

  Przykładowe usługi:

• Wyszukiwanie nazw – 
• Wyszukiwanie usług - UDDI

4) Usługi Internetowe

• Popularnie, Internet jest w Polsce kojarzony z WWW (protokół HTTP).

– W tej chwili obejmuje on jednak ogromną liczbę innych usług.

Wszystkie są oparte na tym samym protokole TCP/IP.

• Email, News (Usenet), Electronic news

• FTP, SFTP

• ICQ (ułatwiający kontakt w internecie)

• Telnet, SSH (Secure Shell)

• IRC

• Gopher, HyperG

• Nie jest wykluczone, że może w każdej chwili pojawić się zupełnie nowa usługa, która zdominuje pewien sektor obecnie opanowany przez WWW.

– Takim komercyjnym buzzem jest w tej chwili P2P

• Napster, Gnutella, Audio Galaxy, WinMX, KaZaA, ....

– Większość nowych usług traktuje HTTP jako „protokół transportowy”.

Architektura trzywarstwowa i wielowarstowa

5) Logika przetwarzania

• Model przetwarzania klient-serwer realizuje się w architekturze trójwarstwoej:

– interfejs użytkownika,

– logikę przetwarzania (reguły biznesu, logikę biznesu)

– serwer (serwery) bazy danych.

• Warstwy są zaprojektowane i istnieją niezależnie, co ma duże znaczenie dla

„pielęgnacyjności” systemu ze względu na możliwość zmian w dowolnej warstwie bez konieczności zmian w pozostałych warstwach.

• Środkowa warstwa może składać się z wielu warstw, co jest określane jako architektura wielowarstwowa.

6) Cienki i gruby klient

• Terminy cienki klient oraz gruby klient odnoszą się do mocy i jakości przetwarzania po stronie klienta w architekturze klient-serwer.

• Model cienkiego klienta: klient posiada niezbyt wielką moc przetwarzania, ograniczoną do prezentacji danych na ekranie. Przykładem jest klient w postaci przeglądarki WWW.

• Model grubego klienta: klient posiada znacznie bogatsze możliwości przetwarzania, w szczególności może zajmować się nie tylko warstwą prezentacji, lecz także warstwą przetwarzania aplikacyjnego (logiki biznesu).
• Powyższy podział posiada oczywiście pewną gradację.
• Model cienkiego klienta jest najczęstszym rozwiązaniem w sytuacji, kiedy system scentralizowany jest zamieniany na architekturę klient-serwer. Wadą jest duże obciążenie serwera i linii komunikacyjnych.
• Model grubego klienta używa większej mocy komputera klienta do przetwarzania zarówno prezentacji jak i logiki biznesu. Serwer zajmuje się tylko obsługą transakcji bazy danych. Popularnym przykładem grubego klienta jest bankomat. Zarządzanie w modelu grubego klienta jest bardziej złożone.

7) Warstwa klienta Warstwa klienta - Interfejs użytkownika

• często najbardziej istotna cecha serwisu dla odbiorcy końcowego
• bardzo pracochłonny dla twórców serwisu (grafika)
• Cienki klient (thin client) i gruby klient (thick client) - pojęcia różnie rozumiane, płynna granica. Cienki klient - to najczęściej:
• "Czysta" przeglądarka WWW, kod HTML i DHTML bez obiektów 
• Kod strony WWW niezależny od przeglądarki i systemu operacyjnego

        

• Gruby klient - to najczęściej:
• Przeglądarka zawierająca obiekty osadzone, uruchamiane w ramach systemu operacyjnego
•  lub osobna aplikacja systemu operacyjnego działająca w środowisku WWW

         

• Specyfika pracy w ramach cienkiego klienta:
• komunikacja w trybie żądanie - odpowiedź (request - response) w ramach HTTP tylko jako efekt działania użytkownika.
• DHTML pozwala na częściowe ominięcie tych ograniczeń, ale jego użycie również może uzależnić od przeglądarki

• Technologie warstwy klienta
• HTML - wizualizacja i struktura rozmieszczenia danych
• CSS - wizualizacja danych
• DHTML - interakcja z użytkownikiem, zmiany w wyglądzie i działaniu interfejsu użytkownika po stronie klienta
• Języki skryptowe (JavaScript, JScript, VBScript) -przetwarzanie danych po stronie klienta
• Obiekty osadzone (aplety j. Java, ActiveX, prezentacje Flash itp.) – rozszerzenie funkcjonalności serwisu poza możliwości samej przeglądarki

8) Warstwa serwera

• Warstwa serwera - przetwarzanie 
• w typowych serwisach realizuje większość zadań 
• punkt centralny systemu rozproszonego - wrażliwość na przeciążenia => ataki typu DoS (Denial of Service)
• odpowiedzialna za synchronizację pracy klientów i, częściowo, zachowanie spójności w warstwie danych
• Oprogramowanie serwisu w ramach warstwy serwera:
• integruje się z właściwym serwerem WWW, faktycznie komunikującym się z klientem
• jest uruchamiane prze serwer WWW w reakcji na żądanie klienta, serwer WWW przekazuje klientowi wynik działania oprogramowania
• Przetwarzanie typu wejście/wyjście - serwer WWW przekazuje do modułu oprogramowania żądanie klienta i traktuje wynik działania modułu jako pełną odpowiedź przekazywaną klientowi
• Przetwarzanie wsadowe - serwer WWW przekazuje klientowi statyczny zasób (np. kod HTML), przetwarzając tylko niektóre, specjalnie oznaczone fragmenty; wynik przetwarzania umieszczany jest w ramach zasobu zamiast danego fragmentu

• Technologie po stronie serwera
•  CGI podstawowy interfejs wymiany danych pomiędzy serwerem WWW i oprogramowaniem; potocznie - moduły w języku Perl, C lub skrypty systemu operacyjnego działające w ramach przetwarzania typu wejście/wyjście
• Serwlety j. Java - poza implementacją CGI – większość możliwości środowiska Java i kilka specyficznych udoskonaleń obecnie część większego standardu J2EE
• ASP pierwsza poważna technologia przetwarzania wsadowego w zasadzie tylko serwery WWW Microsoft (IIS)
• PHP najpopularniejsza i najbardziej dynamicznie rozwijająca się technologia przetwarzania wsadowego pod wieloma względami lepsze od ASP, ale część możliwości zależna od systemu operacyjnego i zewnętrznych bibliotek
• JSP "odpowiedź" j. Java na PHP razem z serwletami tworzą środowisko łatwe do projektowania i "podziału kompetencji"

9) Warstwa danych

• Warstwa danych - przechowanie i udostępnianie danych:
• Źle zaprojektowana struktura danych przy ich dużej ilości => spadek wydajności systemu
• Zmiany w strukturze danych w trakcie implementacji - bardzo kosztowne

• System Zarządzania Bazą Danych (DBMS):
• efektywne fizyczne przechowanie danych
• możliwości selektywnego odczytu, zapisu i modyfikacji
• wbudowane techniki kontroli spójności danych i replikacji

10) Wzorzec MVC

• Wzorzec Model - View - Controller: podział na zadania w ramach warstwy serwera
• Model - reprezentacja danych i realizacja komunikacji z warstwą danych
• View - tworzenie końcowej postaci wizualizacji danych przed przesłaniem do klienta
• Controller - przetwarzanie danych wejściowych i zarządzanie procesem realizacji funkcji

• Realizacja "naturalna":
• Model - Data Access Object (DAO) - klasa (lub zestaw klas) realizująca komunikację z bazą danych
• View - kod JSP
• Controller - serwlet

• Zastosowanie architektur
• Dwuwarstwowa architektura z cienkim klientem
• Systemy spadkowe ( legacy), gdzie oddzielenie przetwarzania i zarządzania danymi jest niepraktyczne.
• Aplikacje zorientowane na obliczenia, np. kompilatory, gdzie nie występuje lub jest bardzo mała interakcja z bazą danych.
• Aplikacje zorientowane na dane (przeglądanie i zadawanie pytań) gdzie nie występuje lub jest bardzo małe przetwarzanie.

• Dwuwarstwowa architektura z grubym klientem
• Aplikacje w których przetwarzanie jest zapewnione przez wyspecjalizowane oprogramowanie klienta, np. MS Excel.
• Aplikacje ze złożonym przetwarzaniem (np. wizualizacją danych, przetwarzaniem multimediów).
• Aplikacje ze stabilną funkcjonalnością dla użytkownika, użyte w środowisku z dobrze określonym zarządzaniem.
  
• Trzywarstwowa lub wielowarstwowa architektura
• Aplikacje o dużej skali z setkami lub tysiącami klientów.
• Aplikacje gdzie zarówno dane jak i aplikacje są ulotne (zmienne).
• Aplikacje integrujące dane z wielu rozproszonych źródeł.
• W architekturze klient-serwer istnieje wyraźna asymetria pomiędzy klientem i serwerem; w szczególności, nie występuje tam komunikacja bezpośrednio pomiędzy klientami. Model taki dla wielu zastosowań jest mało elastyczny i zapewnia zbyt małą skalowalność.
  
• Architektura rozproszonych obiektów znosi podział na klientów i serwery.
• Każde miejsce w rozproszonym systemie jest jednocześnie klientem i serwerem.
• Konieczne jest sprowadzenie wszystkich danych i usług do jednego standardu.
• Taki standard obejmuje:
• Model (pojęciowy i logiczny) danych i usług, który jest w stanie "przykryć" wszystkie możliwe dane i usługi, które mogą kiedykolwiek pojawić się w systemie rozproszonym;
• Specjalne oprogramowanie zwane pośrednikiem (broker), które akceptuje wspólny model danych i usług umożliwiając ich udostępnienie dla dowolnych miejsc w systemie rozproszonym.
• Specjalne oprogramowanie, zwane osłoną, adapterem lub mediatorem, które przystosowuje konkretne miejsce do modelu przyjętego przez pośrednika.

Zaawansowane AI

Aplikacje wielowarstwowe - w ramach warstwy serwera kilka pod-warstw, zarządzanych względnie niezależnie od oprogramowania

Praktyka aplikacji wielowarstwowych: użycie serwerów aplikacji

• skalowalność: serwer może łączyć w sobie kilka komputerów i decydować w sposób optymalny gdzie fizycznie dany moduł będzie działać

• elastyczność: oprogramowanie może być wysoce konfigurowalne za pomocą samego serwera

• wydajność: przy zachowaniu zgodności ze standardami i wzorcami projektowymi można oczekiwać określonej minimalnej wydajności

Technologie serwerów aplikacji: J2EE i .NET

Zaawansowane AI

Web Services - uruchamianie zdalnych procedur przy pomocy składni opartej o XML, głównie poprzez HTTP (czyli w środowisku WWW) serwery aplikacji mogą udostępniać funkcje aplikacji jako Web Services

Web Services mogą stanowić punkt wejścia do "głębszej" aplikacji w ramach systemów heterogenicznych

Zaawansowane AI

Sysetmy agentowe i sieci semantyczne - elementy sztucznej inteligencji w Internecie

– Agent -niezależny proces mający właściciela (twórcę) i zadanie do wykonania

– Mobilny agent - agent, który może samodzielnie przemieszczać się w sieci zachowując przy tym aktualny stan

– Inteligentny agent - agent, przeważnie mobilny, którego zachowaniem sterują elementy sztucznej inteligencji

– Sieć semantyczna - projektowany zbiór opisów zasobów WWW i logicznych powiązań między nimi, pozwalający na "inteligentne", kontekstowe wyszukiwanie informacji (RDF, ontologie)

11)Uniform Resource Indicator, Uniform Resource Name, Uniform Resource Locator

• URI (IRI) [RFC 2369] jest elementem, który wskazuje (w sposób szczególny) na zasób w internecie. Może to być nazwa, adres lub obydwa atrybuty.
• URI jest, zazwyczaj krótkim, łańcuchem znaków, zapisanym zgodnie z określoną w standardzie składnią. Łańcuch ten określa nazwę lub adres zasobu, którego dotyczy dany URI.
• URI składa się z URL i URN.
  
• URN (Uniform Resource Name) jest to URI, który wskazuje na przestrzeń (namespace) zasobu, bez określenia gdzie się on znajduje i jaki jest schemat dostępu (NID i NSS) np. nazwa książki.
  
• Uniform Resource Locator
• Ustandaryzowana nazwa adresu dla zasobu (dokumentu, obrazu, pliku …) w sieci.
• [RFC2396, RFC1738] - podzbiór URI
  
  
• Przykłady:
• URL składa się z dwóch częsci:
• [schemat protokołu] :// [określenie zasobu specyficzne dla schematu]
• http://www.imdb.com
• ftp://astro.caltech.edu
• Uniform Resource Locator
• Dwa rodzaje URL: ogólny i względny
• Składnia ogólnego URL
• protokół://lokalizacja_serwera:port/ścieżka_na_serwerze?parametry
• http://my.host:1234/resource?p1=1&p2=2
• protokół://użytkownik:hasło@LokalizacjaSerwera:port/ścieżkaNaSerwer
• ftp://nobody:unknown@ftp.site/index.html
• schemat:użytkownik@lokalizacja_serwera
• mailto:user@my.mail

Pominięcie niektórych części (np. portu) powoduje przyjęcie rozwiązań domyślnych

Względny URL [RFC2396, RFC1808] - w zasadzie odpowiada lokalizacji zasobu na serwerze, z dopuszczeniem znaków specjalnego znaczenia "." i ".."

12) Hypertext Transfer Protocol (HTTP)

• Protokół warstwy aplikacyjnej Http jest protokołem żądanie-odpowiedź (request/response) pomiędzy klientami i serwerami
• Klienci: zazwyczaj przeglądarki
• Serwery www (Web servers): oprogramowanie, które zazwyczaj działa jako tzw. Demon (daemon), oczekuje na żądania od klientów i przesyła w odpowiedzi dokumenty z serwera.
  
• HTTP
• Protokół bezstanowy (stateless)
• Serwer nie pamięta stanu klienta pomiędzy kolejnymi żądaniami
• Format żądanie i odpowiedź:
• Nagłówek z dokładnie określonym formatem pierwszej linii
• W kolejnych liniach opcjonalne pola nagłówka postaci nazwa: wartość
• Opcjonalna treść oddzielona od nagłówka pojedynczą pustą linią
• Domyślny port: 80
• Aktualnie działające wersje: 1.0 (RFC 1945) i 1.1 (RFC 2068+, obecnie 2616)
• W ramach jednego połączenia może wystąpić:
• Dokładnie jedna sekwencja żądanie - odpowiedź: wersja HTTP 1.0
• Jedna lub więcej sekwencji żądanie - odpowiedź: wersja HTTP 1.1
  
• Proces pobierania zasobu z sieci
• Wysyłanie żądania
• Uruchamiamy serwer www
• Klient tworzy połączenie z serwerem na określonym porcie
• Gdy port nie jest określony przyjmuje 80
• Żądanie musi określone być w postaci URL
• Struktura żądania
• Komenda + komunikat
• Odpowiedź
• Serwer oczekuje na żądania (łańcuchy tekstowe) i wysyła odpowiedź również w postaci łańcucha znaków
• Format odpowiedzi: Linia statusu + komunikat
• Komunikat składa się z nagłówka i ciała (body) dokumentu
• Całość przesyłana przez sieć
• Przeglądarka wydobywa z odpowiedzi body i wyświetla w oknie
  
• Komendy żądania
• GET - uzyskanie zasobu o podanym URI
• POST -przesłanie danych do zasobu o podanym URI, dane zawarte są w treści żądania
• HEAD - jak GET, ale w odpowiedzi uzyskujemy sam nagłówek
• OPTIONS (HTTP 1.1) - uzyskanie informacji o metodach akceptowalnych przez dany zasób lub serwer
• PUT (HTTP 1.1) - umieszczenie na serwerze zasobu w podanym URI, zawartość zasobu określona jest przez treść żądania
• DELETE (HTTP 1.1) - usunięcie z serwera zasobu o podanym URI
• TRACE (HTTP 1.1) - wykonanie rodzaju testu przesłania wiadomości w pętli zwrotnej na samym serwerze – odpowiedź do faktycznego klienta zawiera to co klient przesłał

13) HTTPS

• Domyślny port 443
• SSL (Secure Socket Layer) - protokół kryptograficzny opracowany przez Netscape
• W ramach sesji SSL używa się kryptografii przy pomocy algorytmów asymetrycznego (para kluczy: publiczny i prywatny) oraz symetrycznego (jeden klucz)
• Wszystkie dane przed wysłaniem kodowane są własnym kluczem symetrycznym
• Bezpieczeństwo transmisji zależy głównie od rozmiaru kluczy
• Za wystarczające uznaje się (jeszcze) 128 bitów dla klucza sesji i 1024 dla klucza publicznego
  
• Przebieg sesji połączenia przez SSL:

1. Wymiana certyfikatów (CA) pomiędzy klientem i serwerem.
• CA zawiera uwierzytelnione informacje o właścicielach i klucze publiczne. Przeglądarka może podać własny CA, jeżeli brakuje CA użytkownika
2. Uzgodnienie algorytmu kryptograficznego opartego o klucz symetryczny - wybierany jest zawsze najmocniejszy algorytm znany obu stronom
3. Wygenerowanie osobno przez klienta i serwer tzw. symetrycznego klucza sesji
4. Wymiana kluczy sesji zakodowanych kluczem publicznym "rozmówcy"
5. Odkodowanie kluczy sesji przy pomocy własnego klucza prywatnego i rozpoczęcie wymiany danych

14) Serwlety

• Jednostka (klasa) kodu Javy, która jest uruchomiona po stronie serwera (serverside)
• Klasa ta jest wyspecjalizowana w obsłudze protokołów usług internetowych
• Uruchomiona w kontenerze, który dostarcza tzw. kontekst (context)
• Nie posiada interfejsu użytkownika
• CGI, w Javie, wzbogacone o biblioteki ułatwiające życie programiście (np. utrzymywanie sesji, wspólne zasoby serwletów, ciasteczka, obsługa GET/POST/PUT)
• Pomimo podobieństw, serwlet to nie jest palet uruchamiany na serwerze
• Pomaga w komunikacji klient – serwer
• nie koniecznie z wykorzystaniem HTTP
• jednakże zazwyczaj z HTTP
• serwlety mogą korzystać ze standardowych klas Javy (z VM), klas wchodzących w skład Servlet API oraz ewentualnie z dodatkowych bibliotek zainstalowanych na serwerze.
  
• Web containters
• W obecnych implementacjach serwety uruchamiane są w ramach tzw. Web Container, który może stanowić osobny i jedyny mechanizm serwera (Apacze Tomcat) lub jedną z jego części (serwery aplikacji)
• Tomcat 5.5
• GlassFish
• Jetty
• Enhydra
  
• Cel stosowania serwletów
• Zasadniczo:
• do wyświetlania dynamicznych stron WWW
• przetwarzanie formularzy (logika biznesowa)
• w serwletach zaleca się umieszczanie tylko lekkich funkcji biznesowych, ale w małych aplikacjach cała logika może być w serwletach i JSP
• forwarding (przekierowywanie żądań)
• wyświetlania wyników zapytań do DB (tu zaleca się strony JSP)
  
• Zalety
• Dobrze pracują w środowisku heterogenicznym
• Niezależne od platformy i OS
• Pracują ze wszytkimi głównymi serwerami WWW (IIS, Apache,etc..) (dla zainteresowanych Microsoft's Java SDK: http://www.microsoft.com/java )
• Dobrze zdefiniowane ramy dla Aplikacji Web (dużo usług, API)
• Łatwa i czysta separacja logiki od prezentacji
• Wydajne i dobrze skalowalne
  
  
• Cykl życia serwletu:

1. strona html 
2. ladownie strony html(klient)
3. (klient)wypełnia formularz html i przesyla zadanie(request)
4. servlet reqest
5. (servlet) przetwarza zadnie
6. servlet response
7. (klient) wyswietla odpowiedz(response)

• Powołanie do życia
• Automatycznie przy starcie Web Serwera
• Przy żądaniu klienta
• Przy powtórnym ładowaniu
  
• Zakończenie działania
• Wykonanie (świadome) metody destroy
• Zamknięcie Web serwera
  
• Załadowanie serwletu - klasa serwletu umieszczana jest w pamięci Web Container, wykonywana jest metoda public void init(ServletConfig config)
  
• Obsługa żądania - w momencie przekazania żądania do serwletu jest ono obsługiwane w ramach metody
• GenericServlet, service(ServletRequest req, ServletResponse res)
• HttpServlet doGet(...), doPost(...), ...
  
• Usunięcie serwletu - serwlet może być również usunięty w przypadku zmiany kodu serwletu. 
• W ramach usuwania wywoływana jest metoda public void destroy()

15) Komponenty J2EE

• Serwlety
• Strony JSP (do prezentacji)
• Java Beans (Używane jako obiekty z wartościami, przekazujące dane do JSP)
• Biblioteki Znaczników (Tag Libraries) – Elementy JSP w formacie XML (JSTL)
• Deskryptor Web Deployment – /web-inf/web.xml

16) Sesja

• Potrzebna gdy serwer chce śledzić poczynania użytkownika (tzn. jego kolejne żądania)
• Utrzymywanie koszyka zakupów użytkownika
• Zapisywanie informacji o autoryzacji dostępu
• Sesje są problemem dla serwerów HTTP
• Brak mechanizmu sesji HTTP (bezstanowość)
• API serwletów dostarcza API sesji
• Współdzielenie sesji przez wszystkie przeglądarki (jednego typu)
• Śledzenie sesji
• Istnieją 3 sposoby na utrzymanie sesji

1. Cookies
2. Ukryte pola formularza
3. Przepisywanie URL’a
4. Serwlety

• Będą używać cookies jeśli to możliwe
• Będą przepisywać URL jeśli nie ma cookies
• Jak serwlet śledzi sesję?
• Każda sesja ma unikalne ID
• Gdy sesja się rozpoczyna zostaje przypisane ID
• Każde następne „podzapytanie” musi przesyłać ID (przez cookie lub URL)
• Sesja
• Pozyskanie nowej sesji (z obiektu żądania) :
• HttpSession s = request.getSession(true);
• Zapamiętanie obiektów w czasie sesji:
• s.putValue("item-name", myobject);
• Pozyskanie obiektów :
• s.getValue("item-name");
• Można nasłuchiwać czy obiekty są dodane lub usunięte z sesji – listener’y

17) Filtry

• Obiektów implementujących interfejs Filter używa się do modyfikowania

komunikatów między klientem a docelowym serwletem na serwerze.

• Modyfikacja może odbywac się w kierunku do i od serwletu, a także między serwletami

• Filtry można łączyć w łańcuchy.

• Przykładowe zastosowania filtrów to: autentykacja, szyfrowanie, kompresja.

Sposób użycia

• Zadeklarowanie filtru

• Przypisanie filtru do zasobu (nazwa lub URL)

• Określenie na jakie żądania ma reagować filtr: REQUEST,

FORWARD, INCLUDE, ERROR

• Domyślana operacja to REQUEST. Istnieje możliwość łączenia operacji.

18) JSP- Java Server Pages

• JSP to technologia przetwarzania wsadowego do użytku w ramach Web

Container

• jest bardzo ściśle powiązana z serwletami. Przy pierwszym uruchomieniu strona JSP tłumaczona jest na klasę Java, która faktycznie jest wyspecjalizowanym serwletem

Znaczniki JSP

• Komentarz <%-- …...text…... --%>

• Deklaracja <%! int i; %>

<%! int numOfStudents(arg1,..) {} %>

• Wyrażenie <%= 1+1 %>

• Skryptlet <% … kod java … %>

• Dyrektywa <%@ include file=“*.jsp” %>

• Akcja <jsp:forward page=”…”

Notacje znaczników JSP

• JSP może być wyrażony jako HTML lub XML

• Dla uzyskania zgodności z regułami składni XML, znaczniki muszą być inne (ale realizują te same operacje)

• HTML: <%= expression%>

XML: <jsp:expression> expression</jsp:expression>

• HTML: <% code%>

XML: <jsp:scriptlet> code</jsp:scriptlet>

• HTML: <%! declarations%>

XML: <jsp:declaration> declarations</jsp:declaration>

• HTML: <%@ include file= URL%>

XML: <jsp:directive.include file=" URL"/>

Obiekty JSP

• JSP może operować na zestawie "wbudowanych" obiektów, wywodzących się w większości z mechanizmu serwletów. Te obiekty to m.in.:

􀂃 request - obiekt typu javax.servlet.http.HttpServletRequest, aktualnie obsługiwane żądanie

􀂃 response - obiekt typu javax.servlet.http.HttpServletResponse, aktualnie generowana odpowiedź

􀂃 session - obiekt typu javax.servlet.http.HttpSession, aktualna sesja HTTP

􀂃 application - obiekt typu javax.servlet.ServletContext, kontekst aplikacji WWW w ramach Web Container

􀂃 config - obiekt typu javax.servlet.ServletConfig, konfiguracja strony jako serwletu

􀂃 page - obiekt typu java.lang.Object, odpowiednik this, czyli aktualnie przetwarzana strona

􀂃 out - obiekt typu javax.servlet.jsp.JspWriter, standardowe wyjście strony, odpowiednik JSP dla java.io.PrintWriter

􀂃 pageContext - obiekt typu javax.servlet.jsp.PageContext, daje dodatkowe możliwości np. w zakresie obsługi błędów

􀂃 exception - obiekt typu java.lang.Throwable, obsługiwany błąd, dostępny tylko dla stron odpowiedniego typu

Wybrane dyrektywy JSP

Dyrektywa page - określa różne parametry strony, głównie językowe. Może być kilka dyrektyw tego typu w ramach strony, przy kompilacji zostaną potraktowane jako jedna całość. Niektóre atrybuty:

􀂃 language - określa język kodu strony JSP, jedyna prawidłowa i wymagana wartość to java

􀂃 import - określa zestaw klas i pakietów, oddzielonych przecinkami, które powinny być zaimportowane w ramach docelowej klasy tej strony. Przykład:

<%@ page import="java.io.*, java.util.*, java.text.SimpleDateFormat" %>

􀂃 session - określa, czy strona powinna używać sesji. Jeżeli wartość jest równa true obiekt JSP session jest zdefiniowany i można się do niego odwoływać. Domyślnie wartość true

􀂃 isErrorPage - określa, że strona powinna być traktowana jako strona do obsługi błędów. Jeżeli wartość jest równa true obiekt JSP exception jest zdefiniowany i można się do niego odwoływać. Domyślnie wartość false

􀂃 contentType - określa typ MIME i zestaw znaków dla odpowiedzi aktualnej strony JSP. Format zgodny ze standardem MIME, np. text/html; charset=iso-8859-2

􀂃 pageEncoding - określa zestaw znaków używanych do kodowania strony JSP, domyśnie ISO-8859-1

Dyrektywa include - określa przy pomocy atrybutu file (wartość - relatywny URL) zasób, która ma być włączony do dokumentu w miejscu wystąpienia dyrektywy. Zasób jest dołączany na etapie kompilacjistrony

Dyrektywa taglib - określa bibliotekę znaczników, z której będzie można skorzystać w ramach strony

Wybrane akcje JSP

Akcja w JSP oznacza działanie, które należy podjąć podczas wykonywania kodu JSP. Wiąże się np. z obsługą żądania, jego atrybutów, czy kontrolą przepływu danych. Akcje w JSP określane są w postaci znaczników zgodnych z XML, jak gdyby przestrzeń nazw miała prefix jsp

􀂃 include - (<jsp:include page="..." flush="...">) - działa podobnie jak dyrektywa <%@ include %>, ale zasób, określony przez atrybut page, dołączany jest w momencie działania, nie kompilacji. Atrybut flush mówi, czy przed dołączeniem zasobu aktualny bufor standardowego wyjścia JSP powinien zostać wysłany jako w ramach odpowiedzi

􀂃 forward - (<jsp:forward page="...">) - działa podobnie jak przekazanie sterowania z poziomu serwletu do podanego zasobu

• param - (<jsp:param name="..." value="...">) - pozwala zdefiniować parametr, którego znaczenie zależy od kontekstu użycia. Przykładowo:

dołącza p1 jako atrybut żądania

• useBean - (<jsp:useBean ...>) - pozwala operować na instancji klasy Java. Przyjmowane jest, że instancja ta jest zgodna z JavaBean. Jeżeli instancji nie ma w danym zakresie widoczności, jest ona tworzona według parametrów podanych w ramach akcji.

Java Bean - Jeszcze jedna technologia Java do nauki

• Java beans są zwykłymi klasami Java, które muszą spełniać kilka prostych zasad:

– Musi mieć konstruktora bez paramterów

– Nie może mieć atrybutów publicznych

– Dostęp do wszystkich atrybutów powinien być przez metody get lub set

• Get zwraca wartość atrybutu i pobiera pojedynczy parametr, który jest nową wartością atrybutu – zgodne typy !

• Get i set powinny być nazwane przez prefixy get i set + nazwa

atrybutu np.. Atrybut name = getName i setName

• Uwaga pierwsza litera atrybutu powinna być zapisana dużą literą w

nazwie metody get i set

JSP i JavaBeans

• Główną ideą użycia JB w JSP jest separacja kodu od widoku HTML

• Programiści integrują JB używając tagów lub skryptletów.

– Dołączenie (utworzenie) bean’a.

• jsp:useBean

– Inicjalizcja.

– Ustawienie atrybutów

• jsp:setProperty

– Pobieranie atrybutów

• jsp:getProperty

Niektóre atrybuty useBean:

• id - nazwa beana, za pomocą której będzie identyfikowany w ramach strony JSP, unikalna w zakresie kompilacji

• scope - zakres widoczności. Może przyjmować wartości page (domyślnie), request, session, application, co odpowiada atrybutom na poszczególnych poziomach

• class - pełna nazwa klasy, której instancją jest bean

Przykład: definicja: jest odpowiednikiem (do pewnego stopnia) wywołania:

<jsb:useBean id="mode" class="java.lang.String" scope="request"/>

<% String mode=(String)request.getAttribute("mode"); %>

Z akcją useBean wiążą się dodatkowe akcje setProperty i

getProperty, pozwalające zarządzać polami instancji JavaBean

setProperty - (<jsp:setProperty name="..." />) - ustawia wartość pola instancji JavaBean identyfikowanej przez name. Pozostałe atrybuty:

• property - może zawierać nazwę zmienianego pola. W przypadku podania "*", przeszukiwane są parametry żądania i pasujące pola wypełniane są odpowiednimi wartościami parametrów

• param - zawiera nazwę parametru żądania, którego wartość ma zostać wpisana dla danego pola instancji Java Bean. Nie może występować razem z value

• value - zawiera konkretną wartość, która będzie wpisana dla danego pola instancji JavaBean Biblioteki znaczników

• Taglib, czyli biblioteka znaczników pozwala na rozszerzenie funkcjonalności JSP.

• Jest to jednocześnie sposób na ukrycie implementacji działania kodu w ramach strony, przy zachowaniu jej funkcjonalności

• Istnieje spora liczba bibliotek, które weszły już do standardów programowania JSP.

Najbardziej znana to JavaServer Pages Standard Tag Library (JSTL) udostępniana przez firmę Sun.

Cookies (RFC 2109)

• Utworzenie nowego cookie

– Cookie c = new Cookie("item-name", "item-value");

• Modyfikacja atrybutów cookie:

– c.setValue("item-value");

– c.setComment("Jakiś");

– c.setMaxAge(60 * 60 * 24 * 365);

• Odczytanieatrybutów

– String value = c.getValue();

– String comment = c.getComment();

• Ustawienie cookie przez HttpServletResponse:

– response.addCookie(c);

• Pozyskanie cookie prze HttpServletRequest:

– Cookie[] cookieArray = request.getCookies();