Scarica Programmazione web dispense e più Dispense in PDF di Programmazione e Tecnologie Web 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 direttive
- 3.2 azioni
- 3.2.1 Scriplet
- 3.2.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
- 4 Custom tags
- 4.1 Tag handler
- 4.1.1 Interfaccia Tag - lifecycle
- 4.1.2 Interfaccia BodyTag - lifecycle
5 Autenticazione 14 5.1 Approccio dichiarativo........................ 14 5.1.1 Tipologie........................... 15 5.2 Approccio programmato....................... 16 5.3 Approccio combinato......................... 16 5.4 Principali e Ruoli........................... 16
6 Standard JavaBean 16 6.1 Contesti di visibilità......................... 17
7 Utilizzare MySQL 17 7.1 Libreria JDBC............................ 17 7.1.1 Passaggi per una connessione................ 17 7.1.2 PreparedStatement...................... 18 7.1.3 Transazioni.......................... 18
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( 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.2 azioni
3.2.1 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 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.2 Azioni standard
Azioni per controllare il comportamento del container, sintassi body
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 (opzionale) tag annidato , speci ca coppie nome/valore di dati da allegare ad altre azioni
per incapsulare codice riutilizzabile 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
- tag: attraverso property=* si fa corrispondere tutti i parametri dell'oggetto richiesta ai metodi set del bean
- tag:
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
- importa la libreria tramite direttiva taglib; la sintassi per il custom tag è 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 Tag handler
Per de nire un tag handler
- de nisce i protocolli di comunicazione base con la JSP
- de nisce il lifecycle ed i metodi da invocare all'inizio e alla ne del cus- tom tag
- ha accesso alle informazioni della pagina (request, response, session ...) tramite i metodi de niti dall'oggetto pageContext
- tutte le eccezioni che possono veri carsi durante l'elaborazione del custom tag devono essere catturate e deve essere lanciato un JspException
4.1.1 Interfaccia Tag - lifecycle
- il metodo setPageContext(pageContext) con gura il context di pagina associato al tag
- il metodo setParent(Tag) associa il genitore al tag
(a) null per i livelli superiori (b) tag contenitore per i tag annidati
- il metodo doStartTag() restiuisce un intero che in uenza 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
- il metodo doEndTag() viene chiamato in corrispondenza del tag di chiusura: restituisce un intero che in uenza 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 consider- ata
- il metodo release() rilascia le risorse del tag handler
4.1.2 Interfaccia BodyTag - lifecycle
- il metodo doStartTag() restiuisce un intero che in uenza 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
- il metodo setBodyContent() con gura le proprietà dell'oggetto BodyContent
(a) non invocato per tag vuoti (b) il valore dell'oggetto implicito out viene sostituito nell'oggetto pageContext
- il metodo doInitiBody() viene invocato dopo setBodyContent() e prima che il body venga valutato
- il metodo doAfterBody() restiuisce un intero che in uenza l'elaborazione dei tag
(a) SKIP_BODY: il body del tag viene ignorato (b) EVAL_BODY_AGAIN: il body del tag viene valutato nuovamente
- il metodo doEndTag() viene chiamato in corrispondenza del tag di chiusura: restituisce un intero che in uenza 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 consider- ata
5 Autenticazione
Si possono de nire 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
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 de nisce un metodo di autenticazione (BASIC, FORM, DIGEST) per identi care gli utenti ed i rispettivi ruoli
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
5.3 Approccio combinato
- si fa a damento sul server per la gestione di username/password e ruoli attraverso metodi di autenticazione dichiarativi
- si gestisce l'accesso alle risorse in modo esplicito dalle servlet o dalle JSP
- redirezione essibile in base ai diritti dell'utente, eventualmente si possono visualizzare contenuti diversi in base al ruolo
5.4 Principali e Ruoli
Le restrizioni speci cate nel descrittore associano i ruoli alle risorse
entità denominate, che in genere rappresentano singoli individui o società possono ricoprire uno o più ruoli
- 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 incapsula dati e logica di esecuzione
- ha tutte le proprietà private (usare i metodi get/set)
- ha un costruttore senza argomenti
6.1 Contesti di visibilità
Si può accedere ad un bean da più JSP/servlet in base al suo scope:
- request: visibile a tutte le JSP/servlet nella stessa richiesta
- session: visibile a tutte le JSP/servlet a cui accede l'utente, anche se naviga attraverso varie pagine
- application: visibile a tutte le JSP/servlet nello stesso application context, attraverso le sessioni utente
7 Utilizzare MySQL
- per poter utilizzare un le di script script.sql si esegue il comando source script.sql
- per de nire una query si utilizza l'interfaccia Statament
7.1 Libreria JDBC
Per l'accesso a DB relazionali
API, che de niscono le modalità di connesione/interrogazione/creazione di query parametrizzate e le strutture dati con cui trattare il risultato di una query driver manager, che comunica con i driver speci ci dell'applicativo in uso per realizzare il DB
- l'applicativo inoltra alle API le chiamate per l'apertura di una connessione col DB, recupera ed aggiorna i dati, esegue i comandi previsti e chiude la connessione
- i driver si connettono ad un DB speci co o ad un middleware
provvede a tutti i problemi di conversione tra i comandi JDBC ed il DB engine
7.1.1 Passaggi per una connessione
- caricare il driver
(a) avviene in modo dinamico, a tempo di esecuzione (b) il codice che inizializza la classe del driver provvede a registrarlo presso il driver manager (c) cambiando il driver è possibile utilizzare un altro tipo di DB senza modi care il codice
