Architetture Web parte 2

Transcript

1 Architetture Web parte 2 Programmazione in Ambienti Distribuiti A.A Sessione Un insieme di richieste, provenienti dallo stesso browser e dirette allo stesso server, confinate in un dato lasso di tempo Per l identificazione e la gestione di una sessione non è necessario identificare l utente in modo esplicito: sessione anonima È possibile creare anche sessioni nominali 1

2 Logica di gestione Il Web server identifica le richieste provenienti da un dato client e le associa ad un identificatore univoco (SessionID) Il server può tenere traccia della sequenza di azioni eseguite dal client associando loro il relativo SessionID Il server crea nuove sessioni, invalida quelle vecchie e definisce politiche di persistenza per le sessioni attive Dopo un certo periodo di inattività dell utente (dell ordine delle decine di minuti) la sessione scade e ne viene perso lo stato Logica di gestione Richiesta iniziale - Generazione di un ID - TimeOut - Distruzione della sessione ID Richieste ulteriori - Accesso ai dati di sessione Dati di sessione 2

3 Identificazione di una sessione Ogni sessione è identificata da un ID, generato in modo univoco dal server Di solito un ID è un numero generato progressivamente a partire da un valore dato generato casualmente in un intervallo molto ampio La seconda soluzione è più complessa ma anche più immune ad attacchi da parte di client maliziosi Gestione dell ID Per identificare in modo univoco le richieste successive provenienti da un client è necessario trasferirgli l ID della sessione Esistono vari modi per farlo: Passaggio esplicito nel contenuto del documento Mediante l uso di cookies Mediante la tecnica di riscrittura dei link Coordinando le sessioni dal lato client 3

4 Passaggio Esplicito Meccanismo obsoleto Adatto unicamente per sessioni composte da form successive, che l utente deve completare Si utilizza all interno della form un campo del tipo hidden il cui valore è il SessionID Il programma lato server dovrà propagare in modo esplicito il SessionID nel nuovo documento generato Passaggio Mediante Cookie Un cookie è una coppia (chiave=valore) che un server può memorizzare in modo transitorio o semi-permanente su un client Il client provvede a rimandare automaticamente il cookie come parte dell intestazione ogni qual volta effettua una richiesta al server che lo ha inviato 4

5 Passaggio Mediante Cookie Richiesta iniziale GET /file.html HTTP1.0 ACCEPT text/html ACCEPT image/gif Risposta Content-Type: text/html Set-Cookie: ID=002345;expires=DATE; path=/; domain= <html>... </html> Passaggio Mediante Cookie Richieste successive GET /file.html HTTP1.0 ACCEPT text/html ACCEPT image/gif Cookie: ID= Il cookie viene allegato dal client ad ogni richiesta fino che non scade o non viene cancellato esplicitamente Non tutti i client supportano i cookie È sempre possibile disabilitarne il funzionamento 5

6 Riscrittura dei Link Se un browser non supporta i cookie è possibile mantenere ugualmente traccia della sessione in corso riscrivendo opportunamente i link del documento che deve essere trasferito Meccanismo adatto solo nel caso di documenti HTML: A fronte della prima richiesta, il server analizza il testo del documento che viene inviato verso il client e modifica automaticamente gli indirizzi interni in esso contenuti, aggiungendo l informazione relativa alla sessione in corso Nel corso delle richieste successive, il server estrae il dato di sessione, lo rende disponibili per un eventuale elaborazione e lo re-introduce all atto della trasmissione della pagina Riscrittura dei Link Il documento <html> <body> <ul> <li><a href= link1.html >uno</a> <li><a href= link2.html >due</a> <li><a href= >tre</a> </ul> </body></html> diventa <html> <body> <ul> <li><a href= link1.html;$id$ >uno</a> <li><a href= link2.html;$id$ >due</a> <li><a href= >tre</a> </ul> </body></html> 6

7 Altre Tecniche I metodi precedenti non richiedono capacità di elaborazione sul client diversa dalla gestione del protocollo HTTP In alcuni casi è possibile eseguire sul client un modulo opportuno (applet Java, controllo ActiveX,...) in grado di interfacciarsi direttamente con un oggetto server remoto e svolgere le funzioni di coordinamento della sessione Soluzione poco generalizzabile Java Applet La pagina HTML contiene al proprio interno (o in un frame associato) un applet che coordina le richieste verso il server L applet mette a disposizione l interfaccia di navigazione e può: visualizzare direttamente i risultati dell elaborazione nelle diverse fasi; richiedere al server l aggiornamento del documento visualizzato in un secondo frame 7

8 Comunicazioni con il Server L applet può interagire con il server: tramite il protocollo HTTP (showdocument(url)) aprendo un socket raw verso il server utilizzando RMI - Remote Method Invocation utilizzando il procollo IIOP Internet Inter-ORB Protocol La presenza di firewall può condizionare l utilizzabilità delle diverse tecniche È possibile incapsulare i protocolli RMI e IIOP all interno dell HTTP, per minimizzare i problemi di confiurazione (e peggiorarne le prestazioni) Sicurezza di una Sessione Quando una sessione è cominciata, ogni richiesta viene identificata dal relativo ID Ogni richiesta contente lo stesso valore viene mappata sulla sessione Un hacker potrebbe catturare o indovinare un ID di una sessione diversa dalla propria e interferire con questa 8

9 Sicurezza di una Sessione Esistono varie tecniche per aumentare il livello di sicurezza di una sessione: uso di un canale SSL con autenticazione del server uso di ID difficili da indovinare uso di un canale SSL con autenticazione dell utente (sessione nominale) Uso di Canali SSL Cifrando la comunicazione tra client e server con il protocollo SSL, si può impedire che l ID venga trasmesso in chiaro sulla rete, indipendentemente da come viene mantenuto sul client Questo impone però un degrado sulle prestazioni del sistema, che aumenta al crescere del numero di richieste contemporanee 9

10 ID Difficili da Indovinare L uso di comunicazioni crittografate non impedisce di supporre il valore di in ID in uso Per questo motivo è possibile utilizzare valori scelti a caso in un vasto intervallo o valori consecutivi crittografati con una chiave scelta casualmente quando viene inizializzato il server Microsoft IIS ASP Cookie Gli ID sono interi a 32 bit con valori progressivi Ogni volta che il server viene inizializzato, si sceglie un numero casuale come ID di partenza ed un valore casuale come chiave di cifratura L ID viene crittografato con la chiave e trasformato in un cookie formato da 16 caratteri 10

11 Autenticazione dell Utente Se necessario, è possibile aumentare la sicurezza del sistema richidendo l uso di canali SSL con autenticazione del client Questo richiede che ogni client disponga di un opportuno certificato che identifica l utente in modo univoco Metodo non adatto con utenti occasionali Oltre il CGI PHP e ASP Nel CGI l aspetto finale di una pagina è determinato dall esecuzione del codice Scarsa visibilità e manutenibilità Le pagine sono definite da grafici che non hanno competenze sui programmi Approccio alternativo: includere il codice nell html Utilizzando appositi tag, si introduce la logica dell applicazione All atto della richiesta, il web server filtra la pagina richiesta eseguendo il codice in essa contenuto 11

12 PHP Client 5 1 Server Web file. php 1: Invio dei dati contenuti nel form 2: Reperimento del file php 3: Attivazione dell interprete PHP Interprete PHP 4: Comunicazione del risultato dell elaborazione 5: Trasferimento del risultato al client PHP un esempio <html> <head> <title>example</title> </head> <body> <?php echo "Hi, I'm a PHP script!";?> </body> </html> 12

13 PHP - Potenzialità Raccogliere i dati dai form Il contenuto dei singoli campi viene assegnato ad opportune variabili, indipendentemente dal metodo utilizzato (GET o POST) Generare contenuto dinamico Leggere e scrivere cookie Interfacciarsi con i maggiori DBMS Inviare e leggere messaggi di posta, news, aprire connessioni di rete utilizzando vari tipi di protocolli PHP - limiti Codice interpretato Prestazioni limitate Diverse versioni funzionalità differenti Difficoltà ad organizzare il codice È complesso estendere le librerie fornite Manca il concetto di package Loosely typed Linguaggio object based non object oriented 13

14 PHP Fattori ulteriori Gratis Disponibile il codice sorgente Vasta comunità di sviluppatori Documentazione diffusa Alto livello di cooperazione nella comunità Internet Disponibile per la maggior parte di server Web Servlet Moduli scritti in linguaggio Java che vengono attivati dal server Web a fronte di una richiesta Funzionano all intero del server, non necessitano la creazione di nuovi processi all atto delle richieste Analogamente ai programmi CGI: La pagina prodotta è racchiusa all interno del codice Analogamente a PHP Esiste una vasta libreria di funzioni per la gestione delle richieste, per l interfacciamento con DBMS, per l accesso ad altri componenti software 14

15 Servlet (II) A differenza del PHP: Sono fortemente tipati Sono compilati (in bytecode o, direttamente, per la piattaforma hardware che li ospita) Possono essere racchiusi in package Forniscono un supporto di maggior livello per la gestione delle sessioni Sono facilmente estensibili Esempio di servlet public void doget (HttpServletRequest request, HttpServletResponse response) throws ServletException, IOException { // Obtain the Session object HttpSession session = request.getsession(true); // Get the some data value stored in current session Integer ival=(integer) session.getvalue( MyState"); if (ival == null) ival = new Integer(1); else ival = new Integer(ival.intValue() + 1); session.putvalue( MyState", ival); // Output the page response.setcontenttype("text/html"); ServletOutputStream out=response.getoutputstream(); out.println("<html><body>"); out.println( Current state is: + ival); out.println("</body></html>"); } 15

16 JSP Java Server Pages Analogamente al PHP, consentono la scrittura di pagine sostanzialmente simili all HTML, con l aggiunta di comandi da eseguire sul lato server Tramite un apposito compilatore vengono trasformati automaticamente in servlet, con tutti i benefici che questo comporta Costituiscono la base per la maggior parte degli application server Limiti Tutte le soluzioni viste, dal poco al tanto, si limitano a semplificare: la gestione delle sessioni l interfacciamento con DB l integrazione della logica applicativa con quella di presentazione (HTML) Le applicazioni tendono a restare monolitiche, si integrano difficilmente tra loro, non offrono supporto per la scalabilità ed il riuso Per realizzare applicazioni più complesse occorre introdurre un nuovo concetto: il componente software 16