Docsity
Docsity

Prepara i tuoi esami
Prepara i tuoi esami

Studia grazie alle numerose risorse presenti su Docsity


Ottieni i punti per scaricare
Ottieni i punti per scaricare

Guadagna punti aiutando altri studenti oppure acquistali con un piano Premium


Guide e consigli
Guide e consigli


Riassunto Programmazione web, Appunti di Programmazione e Tecnologie Web

Sintesi del corso di programmazione web prof bartolini

Tipologia: Appunti

2019/2020

Caricato il 21/06/2020

Bellodigrazia
Bellodigrazia 🇮🇹

3

(1)

2 documenti

1 / 11

Toggle sidebar

Questa pagina non è visibile nell’anteprima

Non perderti parti importanti!

bg1
Programmazione web
1 WIS (Web-based Information System)
Sistema informatico basato sul web (non è un insieme di pagine)
_ ha un elevata complessità sia in termini di dati che di applicazioni
_ speso integrato con sistemi diversi tipo DBMS
_ tipologie di servizi elettronici
informativi: per richieste di informazioni strutturate e classificate
di comunicazione: interazione bidirezionale tra host
transazionali: per servizi online o per trasmettere dati
1.1 Componenti principali
Web browser
_ comunica tramite HTTP
_ interpreta la formattazione HTML
definisce dei tag
tra un tag aperto e chiuso può trovarsi qualsiasi testo o altri tag
ogni tag può avere una lista di attributi
ogni tag aperto deve essere chiuso (XHTML)
2
ogni documento inizia con il tag <html>
il tag <head> definisce il titolo del documento, i fogli di stile e scripts
il tag <body> è il contenuto principale della pagina
_ visualizza file di tipo diverso tramite estensioni MIME
standard che specifica tipi di oggetto non testuali per la trasmissione
è possibile associate un oggetto ad unapplicazione che lo gestisca
specifica solo il formato degli oggetti, che vengono trasmessi secondo
la codifica standard base64
non è detto che lapplicativo in questione supporti tutte le estensioni
di MIME
Web Server
_ programma in grado di fornire pagine web attraverso HTTP
_ processo daemon con socket in ascolto su porta TCP 80
_ lURL oggetto della richiesta è usato per selezionare la risorsa lato server
che si vuole usare
HTTP
_ protocollo per trasferimento di hypertext
corrisponde al livello TCP/IP application
meccanismo client/server, è possibile un trasferimento bidirezionale
di informazioni
basato sul meccanismo di naming degli URI
lURL oggetto della richiesta serve a selezionare lato server che si
vuole utilizzare
stateless: il server non mantiene informazioni sulla sessione, ogni
richiesta successiva del client è indipendente
_ la prima linea della richiesta contiene il nome del comando, un URL e la
versione del protocollo in uso
alla richiesta vengono appesse informazioni opzionali
_ il server elabora la richiesta e risponde specificando la versione del protocollo
e uno status code (header)
altre informazioni del header sono il server software e il content-type
della risposta
_ comando GET
3
i parametri della richiesta sono visibili (appesi allURL)
la lunghezza della query string è limitata dal browser
la richiesta può essere salvata e ripetuta varie volte
da non usare per gestire informazioni sensibili
_ comando POST
pf3
pf4
pf5
pf8
pf9
pfa

Anteprima parziale del testo

Scarica Riassunto Programmazione web e più Appunti in PDF di Programmazione e Tecnologie Web solo su Docsity!

Programmazione web

1 WIS (Web-based Information System)

Sistema informatico basato sul web (non è un insieme di pagine) _ ha un elevata complessità sia in termini di dati che di applicazioni _ speso integrato con sistemi diversi tipo DBMS _ tipologie di servizi elettronici

  • informativi: per richieste di informazioni strutturate e classificate
  • di comunicazione: interazione bidirezionale tra host
  • transazionali: per servizi online o per trasmettere dati

1.1 Componenti principali

Web browser _ comunica tramite HTTP _ interpreta la formattazione HTML

  • definisce dei tag
  • tra un tag aperto e chiuso può trovarsi qualsiasi testo o altri tag
  • ogni tag può avere una lista di attributi
  • ogni tag aperto deve essere chiuso (XHTML) 2
  • ogni documento inizia con il tag
  • il tag definisce il titolo del documento, i fogli di stile e scripts
  • il tag è il contenuto principale della pagina _ visualizza file di tipo diverso tramite estensioni MIME
  • standard che specifica tipi di oggetto non testuali per la trasmissione
  • è possibile associate un oggetto ad un’applicazione che lo gestisca
  • specifica solo il formato degli oggetti, che vengono trasmessi secondo la codifica standard base
  • non è detto che l’applicativo in questione supporti tutte le estensioni di MIME Web Server _ programma in grado di fornire pagine web attraverso HTTP _ processo daemon con socket in ascolto su porta TCP 80 _ l’URL oggetto della richiesta è usato per selezionare la risorsa lato server che si vuole usare HTTP _ protocollo per trasferimento di hypertext
  • corrisponde al livello TCP/IP application
  • meccanismo client/server, è possibile un trasferimento bidirezionale di informazioni
  • basato sul meccanismo di naming degli URI
  • l’URL oggetto della richiesta serve a selezionare lato server che si vuole utilizzare
  • stateless: il server non mantiene informazioni sulla sessione, ogni richiesta successiva del client è indipendente _ la prima linea della richiesta contiene il nome del comando, un URL e la versione del protocollo in uso
  • alla richiesta vengono appesse informazioni opzionali _ il server elabora la richiesta e risponde specificando la versione del protocollo e uno status code (header)
  • altre informazioni del header sono il server software e il content-type della risposta _ comando GET 3
  • i parametri della richiesta sono visibili (appesi all’URL)
  • la lunghezza della query string è limitata dal browser
  • la richiesta può essere salvata e ripetuta varie volte
  • da non usare per gestire informazioni sensibili _ comando POST
  • i parametri della richiesta non sono visibili
  • la quantità di dati che si può inviare è illimitata
  • le richieste non possono essere salvate e ripetute Web app _ tecnologie lato client
  • all’interno di applet, attraverso metodi di scripting, in app standalone
  • richiedono il supporto del client
  • problemi di prestazioni e portabilità _ tecnologie lato server
  • servlet, enterprise javabean, API e servizi di transaction management, application server e protocolli di programmazione distribuita
  • non richiedono alcun supporto da parte del client
  • accesso ad informazioni disponibili esclusivamente lato server
  • minimi requisiti in termini di potenza di calcolo e storage da parte del client

2 Servlet

Una servlet è un programma java in esecuzione su un web server _ supportate direttamente o tramite plugin _ ricevono e rispondono alle richieste dei client attraverso (solitamente) HTTP _ la risposta contiene codice HTML dinamico L’interfaccia Servlet definisce i metodi che tutte le servlet devono implementare: le classi GenericServlet e HttpServlet implementano questa interfaccia. Possibili utilizzi: _ supportare richieste multiple in concorrenza 4 _ gestire un database remoto tramite TCP/IP _ autenticazione degli utenti e gestione di sessioni di navigazione _ load balancing tramite redirezione di richieste verso altre servlet in altri server

2.1 Container

Un servlet container (anche detto web container o servlet engine), parte del web server, supporta solo le servlet API (incluse JSP e JSTL) _ può ospitare più servlet: quando una servlet viene invocata per la prima volta, il container genera un thread che inizializza l’oggetto Servlet _ gli oggetti ServletRequest e ServletResponse forniscono l’accesso agli stream I/O, permettendo la ricezione ed invio di informazioni al client _ l’oggetto ServletConfig viene utilizzato dal container per passare informazioni alla servlet al momento della sua creazione

  • la servlet ottine questo oggetto tramite il metodo getServletConfig
  • contiene un oggetto che implementa l’interfaccia servletContext
  • definisce i metodi che una servlet può utilizzare per comunicare con il container
  • esiste un solo context per ciascuna web app
  • nel container esistono uno o più context e ogni servlet deve essere contenuta in uno di essi

2.2 Lifecycle

  1. Il web server riceve una richiesta HTTP, la redireziona al container e viene caricata in memoria la servlet (se non è ancora presente)
  2. il container invoca il metodo init (a) invocato una sola volta (b) inizializzazione delle variabili globali (c) la servlet è in grado di rispondere alla prima richiesta
  3. vengono gestite le richieste del client col metodo service (a) invocato ad ogni richiesta del client (b) riceve la richiesta HttpServletRequest ed effettua le sue elaborazioni (c) genera un oggetto risposta HttpServletResponse che viene passato

_ la chiave è un ID per la sessione _ il valore è l’oggetto che contiene informazioni associate a quella sessione Il container mette a disposizione delle API per una gestione trasparente della sessione _ in tutte le risposte il server aggiunge automaticamente un cookie con l’ID di sessione JSESSIONID _ nel processare una richiesta, si chiede all’oggetto HttpRequest l’oggetto associato alla sessione 7 _ se nella richiesta non viene trovato un ID allora, se getSession(true), si procede alla creazione della sessione (nuovo ID, oggetto di sessione, relativa entry nella session map) _ il container estrae dalla richiesta l’ID di sessione e lo usa per recuperare, dalla session map, l’oggetto associato 2.5.3 Classe HttpSession Il container utilizza questa interfaccia per creare una sessione tra un client ed un server _ una sessione corrisponde ad un solo utente _ permette alle servlet di

  • vedere e manipolare informazioni sulla sessione (ID, tempo di creazione, ultimo accesso)
  • associare oggetti alle sessioni, permettendo la persistenza delle informazioni utente attraverso varie connessioni _ per la cancellazione di una sessione si deve far uso del metodo invalidate Il server riconosce le richieste della stessa connessione e le associa all’oggetto corretto tramite cookie JSESSIONID _ la servlet deve essere in grado di gestire casi in cui il client non vuole partecipare ad una sessione, tipo quando i cookie sono intenzionalmente disabilitati
  • finchè il client non partecipa alla sessione, il metodo isNew restituisce true
  • se il client non partecipa alla sessione, il metodo getSession restituisce una sessione differente ad ogni richiesta, e isNew restituisce sempre true _ le informazioni di sessione fanno parte del ServletContext della web app attuale, quindi le informazioni salvate in un context non sono direttamente visibili all’esterno NB: non si memorizzano le informazioni dell’utente negli attributi delle servlet perchè più utenti possono accedere in parallelo alla stessa servlet 2.5.4 URL rewriting Se il client rifiuta i cookie, è possibile chiedere al container di appendere l’ID della sessione all’URL degli hyperlink presenti nel codice HTML della risposta _ tramite il metodo HttpServletResponse.encodeURL 8 _ pagine di risposta generate da sessioni diverse conterranno URL diversi (con diversi ID di sessione appessi all’URL) _ identificazione trasparente della sessione _ consente la gestione della sessione solo se l’utente naviga attraverso gli hyperlink della pagina di risposta; la sessione viene persa se
  • l’utente accede direttamente all’URL dalla barra di ricerca o tramite segnalibro
  • l’utente torna indietro raggiungendo una pagina richiesta precedentemente senza identificativo riscritto Se il programmatore richiede la riscrittura degli URL il comportamento del container è quello di commutare automaticamente tra le due modalità _ se il browser accetta i cookie la sessione viene gestita solo con i cookie (URL inalterato) _ se i cookie vengono rifiutati, viene attivata la riscrittura degli URL
  • l’encoding dell’URL costituisce un carico di lavoro in più sul server per riscrivere le stringhe, ed un carico in più sulla rete perchè ogni risposta conterrà diversi URL riscritti Non possiamo sapere a priori se il client accetta i cookies
  1. creato l’oggetto HttpSession, il cookie viene sempre automaticamente aggiunto all’oggetto di risposta
  2. invocato il metodo encodeUrl la prima volta vengono inviati sia il jsessionid cookie che gli URL riscritti
  3. dalla richieste successive si controlla il metodo request.isRequestedSessionIdFromCookie

3 JSP (JavaServer Pages)

Estensione della tecnologia servlet

3.1 direttive

Istruzioni dirette al container che specificano come gestire la JSP. Sintassi <%@ ... %> _ <%@ page attribute=”value” %>: definisce impostazioni e opzioni per la pagina _ <%@ include file=”resource” %>: per importare contenuti esterni/package _ <%@ taglib uri=”taglibURI” prefix=”taglibPrefix” %>: per importare un tag library 9

3.2 Scriplet

Blocchi di codice java eseguiti nel contesto della pagina _ codice puro <% javaCode %>

  • blocco di codice java inserito, al momento della traduzione, nel metodo _jspService (quindi non si possono definire metodi)
  • le variabili così definite sono locali, quindi devono essere inizializzate _ dichiarazioni <%! field or method declaration %>
  • per definire variabili e metodi che faranno parte della classe Servlet corrispondente
  • le variabili così definite sono automaticamente inizializzate _ espressioni <%= statement %>
  • il codice viene eseguito e scritto nell’out dell’oggetto response (implicitamente out.print()) _ commenti <%-- comment --%>

3.3 Azioni standard

Azioni per controllare il comportamento del container, sintassi body _ tag:

  • consente l’inclusione di contenuto dinamico nella JSP
  • più flessibile della direttiva include, importa il codice solo al momento dell’esecuzione _ tag:
  • consente alla JSP di inoltrare la richiesta ad altre risorse
  • (opzionale) tag annidato , specifica coppie nome/valore di dati da allegare ad altre azioni _ tag:
  • id è l’etichetta che viene assegnata al bean all’interno dell’app
  • scope definisce le modalità con cui l’istanza del bean deve essere ricercata _ tag: 10
  • attraverso property=“*” si fa corrispondere tutti i parametri dell’oggetto richiesta ai metodi set del bean _ tag:
  • stampa il valore di property

tag handler (b) all’interno della cartella WEB-INF (escluse le sottocartelle classes o lib; nella sottocartella tags solo se nominato come implicit.tld)

  1. importa la libreria tramite direttiva taglib; sintassi body (a) prefix è il nome assegnato alla libreria con la direttiva taglib (b) tag è il nome del tag all’interno della libreria (c) attr1="value" ... attrN="value" sono gli eventuali attributi del tag

4.1 Interfaccia Tag

Definisce i protocolli base per la comunicazione tra tag handler e JSP 4.1.1 Lifecycle

  1. il metodo setPageContext(pageContext) configura il context di pagina associato al tag
  2. il metodo setParent(Tag) associa il genitore al tag (a) null per i livelli superiori (b) tag contenitore per i tag annidati
  3. il metodo doStartTag() restiuisce un intero che influenza l’elaborazione dei tag (a) SKIP_BODY: il body del tag viene ignorato (b) EVAL_BODY_INCLUDE: il body del tag deve essere trascritto invariato
  4. il metodo doEndTag() viene chiamato in corrispondenza del tag di chiusura: restituisce un intero che influenza l’elaborazione della parte di pagina che segue il tag (a) SKIP_PAGE: la parte di pagina oltre il tag di chiusura viene ignorata (b) EVAL_PAGE: la parte di pagina oltre il tag di chiusura viene considerata
  5. il metodo release() rilascia le risorse del tag handler

4.2 Interfaccia BodyTag

Interfaccia che estende Tag, definisce metodi per elaborare il corpo del tag 13 4.2.1 Lifecycle

  1. il metodo doStartTag() restiuisce un intero che influenza l’elaborazione dei tag (a) SKIP_BODY: il body del tag viene ignorato (b) EVAL_BODY_INCLUDE: viene elaborato il body del custom tag, si passa direttamente al metodo doAfterBody() (c) EVAL_BODY_BUFFERED: viene elaborato il body del custom tag, si crea l’oggetto BodyContent
  2. il metodo setBodyContent() configura le proprietà dell’oggetto BodyContent (non invocato per tag vuoti)
  3. il metodo doInitiBody() viene invocato dopo setBodyContent() e prima che il body venga valutato
  4. il metodo doAfterBody() restiuisce un intero che influenza l’elaborazione dei tag (a) SKIP_BODY: il body del tag viene ignorato (b) EVAL_BODY_AGAIN: il body del tag viene valutato nuovamente
  5. il metodo doEndTag() viene chiamato in corrispondenza del tag di chiusura: restituisce un intero che influenza l’elaborazione della parte di pagina che segue il tag (a) SKIP_PAGE: la parte di pagina oltre il tag di chiusura viene ignorata (b) EVAL_PAGE: la parte di pagina oltre il tag di chiusura viene considerata 4.2.2 Classe BodyContent Estende la classe JspWriter, incapsula la valutazione del corpo così da essere disponibile al tag handler _ il container mantiene uno stack di oggetti BodyContent, così che un tag annidato non sovrascriva il corpo di uno dei suoi tag annidati _ ogni BodyContent mantiene un riferimento al Bodycontent del livello inferiore nello stack

5 Autenticazione

Si possono definire i privilegi di accesso per certe risorse della web app: se l’utente è stato già autenticato la risorsa viene resa disponibile, altrimenti si chiede l’autenticazione 14

5.1 Approccio dichiarativo

Gli aspetti relativi alla sicurezza sono interamente gestiti dal container _ si usa il descrittore della web app (web.xml) per dichiarare che certe risorse sono riservate ad utenti che rivestono certi ruoli _ si definisce un metodo di autenticazione (BASIC, FORM, DIGEST) per identificare gli utenti ed i rispettivi ruoli

  • processo trasparente alle servlet/JSP
  • quando viene richiesta una risorsa protetta, il server richiede username/ password e tiene traccia automaticamente degli utenti già autenticati
  • per preservare la sicurezza dei dati sulla rete si può specificare che certe risorse si possono accedere solo attraverso connessioni HTTPS (con eventuale redirezione da HTTP) _ problemi:
  • non è possibile proporre agli utenti contenuti diversi a seconda dei ruoli ricoperti: l’utente accede alla risorsa protetta oppure viene bloccato
  • l’accesso, basato esclusivamente su password, è completamente controllato dal server
  • la soluzione non è sempre portabile: server diversi potrebbero supportare l’accesso in modi diversi
  • è necessario modificare il descrittore 5.1.1 Tipologie La scelta del meccanismo viene dichiarata nel descrittore _ autenticazione BASIC
  • quando un utente tenta di accedere ad una risorsa protetta, il container invia automaticamente e in modo trasparente una finestra di richiesta username/password
  • metodo non sicuro (password trasmesse in base64) _ autenticazione basata su FORM
  • come il metodo BASIC ma viene visualizzata la pagina di login anzichè una finestra di dialogo: permette di controllare l’aspetto ed il comportamento della pagina di login
  • viene inoltre specificata una pagina di errore per il caso di mancata autorizzazione 15
  • nel descrittore specificare che si adotta l’autenticazione basata su FORM ed il nome della pagina di login/errore
  • metodo non sicuro (password trasmesse in base64) _ autenticazione DIGEST
  • quando un utente tenta di accedere ad una risorsa protetta, il container invia automaticamente e in modo trasparente una finestra di richiesta username/password
  • basato sul meccanismo domansa/risposta: il server propone al client una NONCE
  • l’utente per essere autenticato deve rispondere con un hash calcolato con {username, password, NONCE, HTTP, URI}
  • nel descrittore specificare che si adotta l’autenticazione basata su DIGEST

5.2 Approccio programmato

Le risorse protette sono responsabili della gestione della propria sicurezza _ approccio portabile: non ci sono elementi della web app che dipendono dal server utilizzato (non sono necessarie ulteriori specifiche nel descrittore) _ ogni servlet/JSP deve verificare manualmente se l’utente è autenticato

  1. chiudere la connessione 7.1.2 Prestazioni Per eseguire comandi simili ripetutamente, si usa uno statement precompilato e parametrizzato
  2. si crea uno statement in forma standard, compilato prima di essere utilizzato
  3. si rimpiazzano i parametri marcati con? utilizzando i metodi set Per impostazione predefinita, dopo l’esecuzione di un comando SQL, il commit viene eseguito immediatamente _ disattivando l’auto-commit si possono raggruppare due o più statement in una transazione _ la chiamata commit forza tutti i cambiamenti richiesti dall’ultima chiamata commit _ la chiamata rollback serve per il ripristino in caso di errori: elimina i cambiamenti richiesti a partire dall’ultima chiamata commit Si crea un ConnectionPool _ per mantenere i tempi di risposta sotto una certe soglia si riutilizzano le connessioni col DB _ alla registrazione del ConnectionPool viene creato un gruppo di connessioni JDBC _ per comunicare col db si chiede in prestito una connessione dal pool e alla chiusura si rilascia 18

8 Qualche domanda di verifica

8.1 Traduzione JSP in Servlet

Direttive Non vengono tradotte in linguaggio Java (sono comandi diretti al container) Scriptlet Ricopiate dalla pagina JSP nella servlet Commenti HTML viene stampato dalla servlet: out.write(“”) Commenti java Ignorati Azione standard Chiama il metodo jsp_runtime_library.include(request, response, “destination”, out) Azione standard Chiama il metodo PageContext.forward(“destination” + “?” + URLEncode(“paramName”)

  • “=” + URLEncode(“paramValue”)) Azione standard Si ottiene il bean tramite metodo PageContext.getParam(“beanName”, PageContext_SCOPE); se il bean è NULL viene istanziato e settato con PageContext.setParam(“beanName”, bean, PageContext_SCOPE). Se lo scope è application o session si richiede un accesso sincronizzato al PageContext. Azione standard Si esegue una reflection sull’oggetto bean e si chiama il metodo get/set corrispondente alla proprietà della classe bean Tag handler che implementa Tag Viene incluso il ciclo di vita del tag nella servlet 19 Tag handler che implementa BodyTag Viene incluso il ciclo di vita del tag nella servlet, inoltre si elabora l’eventuale body

8.2 Descrivere la struttura di una webApp

Gerarchia cartelle webapps/ context root

index.html META-INF/ WEB-INF/ web.xml src/ classes/ lib/ tags/ Modifiche da apportare per le JSP Nessuna Modifiche da apportare per i custom tag Definire un TLD

8.3 Come possono JSP e servlet accedere allo stesso bean

JSP e servlet possono accedere allo stesso context attraverso i vari oggetti definiti per lo scope, e così reperire la stessa istanza del bean 20