Scarica Programmazione web 2018 e più Appunti in PDF di Programmazione Java solo su Docsity!
Programmazione web
- 1 WIS (Web-based Information System) Contents
- 1.1 Componenti principali
- 2 Servlet
- 2.1 Container
- 2.2 Lifecycle
- 2.3 Struttura Web App
- 2.4 Redirezione richiesta
- 2.4.1 Lato client
- 2.4.2 Lato server
- 2.5 Gestione della sessione
- 2.5.1 Hidden form parameter
- 2.5.2 Cookies
- 2.5.3 Classe HttpSession
- 2.5.4 URL rewriting
- 3 JSP (JavaServer Pages)
- 3.1 Scriplet
- 3.2 Azioni standard
- 3.3 Contesti di visibilità
- 3.3.1 application scope
- 3.3.2 page scope
- 3.3.3 request scope
- 3.3.4 session scope
- 3.4 Lifecycle
- 3.5 JSP o Servlet?
- 4 Custom tags
- 4.1 Interfaccia Tag:
- 4.2 De nire un tag handler
- 4.2.1 Classe TagSupport
- 4.2.2 Classe BodyTagSupport
- 4.3 Lifecycle
5 Autenticazione 15 5.1 Approccio dichiarativo........................ 15 5.1.1 Tipologie........................... 16 5.2 Approccio programmato....................... 17 5.3 Approccio combinato......................... 17 5.4 Principali e Ruoli........................... 17
6 Standard JavaBean 17 6.1 Contesti di visibilità......................... 18
7 Utilizzare MySQL 18 7.1 Libreria JDBC............................ 18 7.1.1 Passaggi per una connessione................ 18 7.1.2 PreparedStatement...................... 19 7.1.3 Transazioni.......................... 19
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 classi cate 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
de nisce 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) ogni documento inizia con il tag il tag de nisce il titolo del documento, i fogli di stile e scripts il tag è il contenuto principale della pagina
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
all'interno di applet, attraverso metodi di scripting, in app stan- dalone richiedono il supporto del client problemi di prestazioni e portabilità
servlet, enterprise javabean, API e servizi di transaction man- agement, application server e protocolli di programmazione dis- tribuita 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 de nisce i metodi che tutte le servlet devono implementare: le classi GenericServlet e HttpServlet implementano questa interfaccia. Pos- sibili utilizzi:
- supportare richieste multiple in concorrenza
- 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 in- formazioni alla servlet al momento della sua creazione
la servlet ottine questo oggetto tramite il metodo getServletConfig contiene un oggetto che implementa l'interfaccia servletContext de nisce 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
- Il web server riceve una richiesta HTTP, la redireziona al container e viene caricata in memoria la servlet (se non è ancora presente)
- 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
- vengono gestite le richieste del client col metodo service
(a) invocato ad ogni richiesta del client (b) riceve la richiesta HttpServletRequest ed eettua le sue elaborazioni (c) genera un oggetto risposta HttpServletResponse che viene passato al web server
- la servlet viene messa fuori servizio e distrutta tramite il metodo destroy, quindi rilascia le risorse allocate (garbage collect)
può essere utilizzato sia per richieste GET che POST
- il metodo forward trasferisce il controllo completo alla pagina di desti- nazione
- il metodo include inserisce l'output della pagina di destinazione e con- tinua l'elaborazione
- per fornire dati alla pagina di destinazione si includono tramite HttpServletRequest.setAttribute(key value)
2.5 Gestione della sessione
2.5.1 Hidden form parameter
La sessione viene mantenuta solo navigando attraverso FORM opportunamente scritti
- soluzione lato server, per sole informazioni testuali
- funziona anche se il client non accetta i cookie
- se l'utente clicca un regolare hyperlink il form non viene inviato
2.5.2 Cookies
Un cookie è un oggetto spedito dalla servlet tramite il metodo HttpServletResponse.addCookie
- soluzione lato client (che può ri utare di salvarli), per sole informazioni testuali
- cancellati automaticamente quando scadono
- i dati sensibili restano su server, il cookie creato non è trasferibile da un computer ad un altro in quanto contiene un ID generato automaticamente
- il browser rispedisce il cookie aggiungendo dei campi alla richiesta HTTP, la servlet lo recupera tramite il metodo HttpServletRequest.getCookie
Il server gestisce una session map: ogni voce rappresenta una sessione distinta
- 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
- 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 infor- mazioni 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
nchè il client non partecipa alla sessione, il metodo isNew restituisce true se il client non partecipa alla sessione, il metodo getSession resti- tuisce una sessione dierente 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 diretta- mente 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 ri uta 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
3.1 Scriplet
Blocchi di codice java eseguiti nel contesto della pagina, per creare pagine di- namiche
blocco di codice java inserito, al momento della traduzione, nel metodo _jspService (quindi non si possono de nire meotodi) le variabili così de nite sono locali, quindi devono essere inizializzate
- dichiarazioni <%! declaration %>
per de nire variabili e metodi che faranno parte della classe Servlet corrispondente le variabili così de nite sono automaticamente inizializzate
- espressioni <%= statement %>
espressioni java che vengono valutate alla richiesta della pagina il container converte il risultato di un'espressione in un oggetto String e lo invia in output come parte della risposta
- commenti <%-- comment --%>
3.2 Azioni standard
Azioni per controllare il comportamento del container
consente l'inclusione di contenuto dinamico nella JSP più essibile della direttiva include, importa il codice solo al mo- mento dell'esecuzione
consente alla JSP di inoltrare la richiesta ad altre risorse tag annidato , speci ca coppie nome/valore di dati da allegare ad altre azioni
per incapsulare codice scriplet in una classe apposita nel package bean id è l'etichetta che viene assegnata al bean all'interno dell'app scope de nisce le modalità con cui l'istanza del bean deve essere ricercata
si possono de nire le proprietà con si possono leggere le proprietà con
3.3 Contesti di visibilità
Le JSP possono accedere ad oggetti de niti in diverse aree di visibilità (scope)
3.3.1 application scope
- associato al servlet context
- si accede tramite ServletContext.getAttribute
- oggetto implicito application
fornisce informazioni sul contesto di esecuzione della JSP (ServletContext) rappresenta la web app a cui la JSP appartiene consente di interagire con l'ambiente di esecuzione (risorse server- side, parametri di inizializzazione/attributi dell'app)
3.3.2 page scope
- visibilità ristretta al codice presenta nella stessa pagina
- completata la richiesta della pagina si perde ogni riferimento ad esso as- sociato
- si accede tramite PageContext.getAttribute
- oggetto implicito page
rappresenta l'istanza corrente della servlet associata alla JSP istanza dell'interfaccia HttpJspPage può essere utilizzato per accedere a tutti i metodi de niti nelle servlet
- oggetto implicito pageContext
fornisce informazioni sul contesto di esecuzione della JSP rappresenta l'insieme degli oggetti impliciti di una JSP, consente l'accesso ad essi attraverso i corrispettivi get utile per costruire custom tags
- oggetto implicito exception
rappresenta l'eccezione che non viene gestita da nessun blocco try/catch disponibile nelle pagine con errorPage=true
4 Custom tags
Meccanismo di estensione dei tag JSP prede niti
il prefix distingue i tag per una libreria tag è il nome attr1="value" ... attrN="value" sono gli attributi che modi - cano il comportamento del tag
- per utilizzare una JSP che ha dei tag personalizzati
de nire, per ogni tag, una classe tag handler che ne implementi le funzionalità de nire una tag library, che de nisce un insieme di custom tag e contiene gli oggetti che implementano i tag
- quando il container incontra un tag personalizzato
crea l'oggetto tag handler invoca i metodi dell'interfaccia Tag
- i tag hanno accesso alle informazioni della pagina tramite l'oggetto PageContext
prevede un insieme di metodi per l'accesso agli oggetti impliciti nell'ambito della pagina
4.1 Interfaccia Tag:
- de nisce i protocolli di comunicazione base tra un tag handler e una JSP
- de nisce il lifecycle ed i metodi da invocare all'inizio e alla ne del tag
- speci ca i metodi get/set per le proprietà del PageContext e dei parenti
la JSP invoca i metodi setPageContext e setParent prima di in- vocare doStartTag o doEndTag
4.1.1 Dichiarare i tag
Ogni tag deve essere dichiarato nella TLD con un elemento , che a sua volta contiene gli elementi
- nome univoco
- nome del tag handler
- speci ca il tipo di body valido per il tag
tagdependent: il body viene interpretato dall'implementazione stessa del tag empty scriptless: il body accetta solo testo statico, espressioni EL, cus- tom tag
Un tag può contenere degli attributi dichiarando l'elemento , che a sua volta contiene gli elementi
- nome univoco
- (opzionale)
- (opzionale) se il valore dell'attributo può essere calcolato dinamicamente a runtime da un espressione EL
quando il container incontra il tag crea l'oggetto tag handler ed invoca i metodi set necessari per impostare i valori degli attributi
- è prassi comune implementare i metodi get nel tag handler per permettere ai tag annidati di accedere alle proprietà degli antenati
4.2 De nire un tag handler
- solitamente si estende una di queste due classi, che implementano l'interfaccia Tag e orono metodi in più
TagSupport per tag che non elaborano il contenuto del proprio body BodyTagSupport per tag che elaborano il contenuto del proprio body
- obbligatoriamente de niti all'interno dei package
- tutte le eccezioni che possono veri carsi durante l'elaborazione di un tag devono essere catturate e deve essere lanciato un JspException
4.2.1 Classe TagSupport
4.2.2 Classe BodyTagSupport
4.3 Lifecycle
- il metodo setPageContext con gura il context di pagina associato al tag
- il metodo setParent associa il genitore al tag
null per i livelli superiori tag contenitore per i tag annidati
- entrambi i metodi sono rivolti a coloro che implementano il container e non agli sviluppatori JSP
non è possibile proporre agli utenti contenuti diversi a seconda dei ruoli ricoperti l'accesso, basato esclusivamente su password, è completamente con- trollato dal server la soluzione non è sempre portabile: server diversi potrebbero sup- portare l'accesso in modi diversi è necessario modi care il descrittore
5.1.1 Tipologie
La scelta del meccanismo viene dichiarata nel descrittore in corrispondenza dei tag e
quando un utente tenta di accedere ad una risorsa protetta, il con- tainer invia automaticamente e in modo trasparente una nestra di richiesta username/password questo metodo manca di sicurezza (password trasmesse in base64)
- autenticazione basata su FORM
come il metodo BASIC ma viene visualizzata la pagina di login anzichè una nestra di dialogo: permette di controllare l'aspetto ed il comportamento della pagina di login viene inoltre speci cata una pagina di errore per il caso di mancata autorizzazione nel descrittore speci care che si adotta l'autenticazione basata su FORM ed il nome della pagina di login/errore
quando un utente tenta di accedere ad una risorsa protetta, il con- tainer invia automaticamente e in modo trasparente una nestra 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 speci care 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 speci che nel descrittore)
- per prevenire accessi non autorizzati: ciascuna servlet o JSP deve aut- enticare l'utente o veri care che sia già stato autenticato
- per preservare la sicurezza dei dati sulla rete
ogni servlet o JSP deve controllare il protocollo utilizzato se gli utenti provano ad utilizzare una connessione HTTP bisogna redirezionarla su HTTPS
5.3 Approccio combinato
- si fa a damento sul server per la gestione di username/password e ruoli attraverso metodi dichiarativi: autenticazione BASIC, FORM o DI- GEST
- si gestisce l'accesso alle risorse in modo esplicito dalle servlet o dalle JSP
- redirezione essibile in base ai diritti dell'utente
5.4 Principali e Ruoli
entità denominate, che in genere rappresentano singoli individui o società possono ricoprire uno o più ruoli
- le restrizioni speci cate nel descrittore associano i ruoli alle risorse
- l'associazione dei ruoli ai principali è compito del container
- le applicazioni non possono impostare principali e ruoli; questi possono essere impostati solo dai container
6 Standard JavaBean
Ai ni dello sviluppo di servlet e JSP si de nisce bean una classe che
- ha tutte le proprietà private (usare i metodi get/set)
- ha un costruttore senza argomenti
- de nire l'URL per la connessione al DB
- instaurare la connessione
- creare un oggetto statement che rappresenta la query da inoltrare
- eseguire la query
- elaborare il risultato
- chiudere la connessione
7.1.2 PreparedStatement
Per eseguire e cacemente comandi simili ripetutamente, si usa uno statement precompilato e parametrizzato
- si crea uno statement in forma standard, compilato prima di essere uti- lizzato
- si rimpiazzano i parametri marcati con? utilizzando i metodi set
7.1.3 Transazioni
- per impostazione prede nita, 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
