Embed Size (px)
DESCRIPTION
Tecnologies Web Seminaris d’empresa 2013. inLab FIB Jaume Moral. Índex. Tecnologies de client: del HTML a AJAX. Responsive design , web en el mòbil i accessibilitat Conceptes bàsics d'aplicacions web. Les arquitectures basades en Java - PowerPoint PPT Presentation
Citation preview
Tecnologies Web
Seminaris d’empresa2013
inLab FIBJaume Moral
Índex
• Tecnologies de client: del HTML a AJAX.• Responsive design, web en el mòbil i accessibilitat• Conceptes bàsics d'aplicacions web.• Les arquitectures basades en Java • El mon dels frameworks: Spring, Struts, Hibernate...• Programar pensant en la seguretat• Casos pràctics:
– L’entorn de desenvolupament Java + web a inLab FIB– Com hem muntat el web de inLab amb Drupal– El Racó i la API del Racó– Single Sign On a la FIB
Les tecnologies del clientDel HTML a AJAX
De què parlarem?
• CSS• DOM• Javascript• HTML5• AJAX• JQuery
Les pàgines web: HTML + CSS
• El HTML és el que conté la informació de la pàgina.• Els fulls d’estil CSS contenen la forma en que es visualitzen• Defineixen atributs de visualització de:
– Els tags HTML normals i corrents– Classes que podem associar a una part del text– Elements amb un identificador únic
<span class=”titol”>Aixo es un titol</span><span id=”menu1”>Primer menu</span>
• Separar la presentació del contingut, faciliten la coherència
Tipus de propietats que hi ha a CSS
• Podem jugar amb– Marges– Mides– Posicions en pantalla– Tipus de lletra– Imatges i colors de fons– Visualització o no d’un element
• S’apliquen a certs elements de la pantalla amb uns filtres anomenats selectors– .navegacio li -> tots els li dintre de class=“navegacio” – #cap a:hover -> tots els links del id=“contingut” quan
passem per sobre
L’estructura de la pàgina i el DOM
• Document Object Model: model d'objectes de la pàgina que exposa el navegador als llenguatges de script.
• API que ens permet accedir al que esta mostrant el navegador o manipular el seu comportament
• DOM = Javascript? NO.– Javascript ens permet accedir a la pàgina mostrada i al
navegador utilitzant el DOM • Accedint al DOM podem veure i manipular les propietats
definides a través de CSS• Podem accedir a elements qualsevol de la pàgina si els
identifiquem amb un ID únic al HTML
Example: àrea desplegable
<script>function desplegar(id) { valor=document.getElementById(id).style.display; if (valor!="block") {valor="block";} else {valor="none";} document.getElementById(id).style.display=valor;}</script><style> .desplegable {display:none}</style>...<div><a href=”javascript:desplegar('op1')">Desplegar</a></div><div class="desplegable" id="op1">Aquest text apareixerà i desapareixerà</div>
HTML 5
• http://www.html5rocks.com• HTML5 =~ HTML + CSS + Javascript
– Nous tags HTML– CSS3– Les API per accedir al DOM ja formen part de l’especificació– Pensat més per aplicacions i no simplement per pàgines
• Com identificar una pàgina com HTML 5?– <!doctype HTML>
Novetats més importants de HTML 5
• Emmagatzemament local– Clau valor– Base de dades (Indexed DB i SQL, ja deprecated)
• Cache i suport per aplicacions off-line• Interfície d’usuari
– Drag & drop– Nous camps per formularis: mail, numero, telefon...
• Nous tags d’estructura• Multimedia
– Tags audio, video, canvas, webgl– No hi ha acord amb els formats
• API per Geolocalització, Websockets...
On podem fer servir HTML5?
• IE9, Chrome, Safari i Firefox 4+ (si no... Modernizr)• Mòbils
– Camps de formularis adaptats– Geolocalització– Aplicacions off-line– Efectes i estil de mòbils: jQuery Mobile / PhoneGap
• Substitut per Flash– Tag video– Canvas + Javascript o animacions CSS3
• Aplicacions per windows 8
Javascript avançat
• Amb la manipulació del DOM, Javascript demostra que serveix per mes que validar formularis
• Necessitem capacitats més avançades per fer que poguem realment “programar aplicacions” en Javascript.– Crear ojectes i classes– Passar com a paràmetres estructures complexes– Crear “callbacks” en resposta a events– Facilitar la comunicació directa amb el servidor (AJAX)– Accedir facilment al DOM
• Algunes d’aquestes capacitats depenen del navegador i es fa necessari una llibreria que ens abstregui
Funcions anònimes
• function avisar(x) {alert(x)
}
• var avisar= function (x) {alert(x)
}
• document.getElement(“boto”).onclick=function(event) {alert(“hola”);
}
JSON (Javascript Object Notation)
• Notació per dades estructurades (arrays i arrays associatius){ aula:’Tecnologies web’, professors:[ {nom:’Jaume’,cognom:’Moral’}, {nom:’Daniel’,cognom:’Golobart’}
]}
• Permet “simular” passar paràmetres a una funció per nom o pasar estructures complexes
• Molt utilitzat en llibreries, per simplificar les API.• Similar a XML, pero més llegible per les persones
La revolució AJAX
• AJAX=Asynchronous JavaScript+XML– http://www.adaptivepath.com/ideas/essays/archives/000385.php
• Treballar des del navegador comunicant-se amb el servidor pero sense necessitat de recarregar les pàgines
• Ús extensiu de l’objecte XMLHttpRequest– Permet fer peticions HTTP des de Javascript– Executa codi JavaScript en resposta a la crida
• Manipulem el DOM de la pàgina• Problemes:
– depenem molt del navegador– dificultat de desenvolupament
Flux d’execució de AJAX
• Tenim un objecte AJAX• Creem una instancia i li diem:
– URL a la que connecta– Funció de callback
• Cridarem aquest objecte en resposta a un event
• En rebre la resposta, executem el callback (assincronament)
• El callback rep la resposta en XML, HTML, JSON...
• Actualitzem la pàgina
Què no és AJAX?
• AJAX és un nom que ha funcionat tan bé que s’aplica a coses que no tenen res a veure.
• AJAX no es només Javascript– Si no hi ha interacció amb el servidor, no es AJAX
• AJAX no es només XMLHTTPRequest– Es poden simular recàrregues amb un frame ocult.– Idea de JSONP, que veurem tot seguit
• AJAX no es només XML– Hi ha altres formats per intercanviar informació
• Parlem amb propietat, que per algo som enginyers!
Restriccions de AJAX i JSONP
• No podem fer una petició AJAX a un servidor diferent que el que ens ha proporcionat la pàgina
• Forma de saltar-se aquesta restricció: JSONP– Carrega un fitxer JS d’una màquina remota que acaba fent
una crida a una funció Javascript de la nostra pàgina.– El nom ve de que es una estructura JSON amb un afegit
(padding), que seria la crida a la funció– Ideal per fer API de serveis i incrustar-los a les nostres
pàgines amb Javascript.– Exemple: API de twitter
JQuery
• Idea: afegir “comportament” als elements de la pàgina de la mateixa forma que s’afegeixen propietats de visualització amb CSS
• Es un javascript “no intrusiu”, que no es posa dintre del HTML– Exemple: fem que els links amb class “menu” quans els
clickem s’amaguin$("a.menu").click(function(event) { event.preventDefault(); $(this).hide("slow"); }
);
Més sobre JQuery
• Events– $(selector).click(funcio_a_executar)– $(selector).mouseover(funcio_a_executar)
• Animacions– $(selector).fadeIn(“slow”)– $(selector).animate({width:20,height:200}, "slow")
• CSS– $(selector).addClass(“coses”)– $(selector).css ({width:200})
• Manipulació del DOM– $(selector).append(“<p>Afegim HTML!</p>”)
AJAX amb JQuery
• Crida AJAX$.ajax({ url: 'document.xml', type: 'GET', dataType: 'xml', timeout: 1000, error: function(){ alert('Error loading XML document'); }, success: function(xml){ // do something with xml }});
• Carregar HTML via AJAX$(selector).load(“document.html”)
Extensions de JQuery
• Plugins (http://plugins.jquery.com/)– Son extensions diverses basades en la llibreria– Exemple: tablesorter, que converteix una taula “normal” amb
una taula que es pot ordenar picant sobre els titols
$(".ordenable").tablesorter();
• UI (http://jqueryui.com/)– Són únicament elements d’interficie d’usuari– Necessiten una part en javascript i una de CSS+imatges– Exemple: tabs, per crear pestanyes
$(“.pestanyes").tabs();
Conclusions
• Una pàgina web no es una pàgina immutable i estàtica• La seva extructura s'exposa via DOM• Es pot manipular i canviar la visualització• Pot respondre a events Javascript• Pot demanar informació a un servidor via AJAX• Tenim llibreries fantàstiques que ens ajuden: jQuery
• Una pàgina web pot arribar a tenir un nivell d’interactivitat similar a una aplicació d’escriptori
Responsive design
Què es responsive design?
• Adaptar el contingut perque es vegi de la millor forma en qualsevol dispositiu.– No fer dos versions, sino una adaptable a la mida de la
pantalla que tenim
• Idea inicial: Ethan Marcotte• http://www.alistapart.com/articles/responsive-web-design/
Mateix web, diferents navegadors
Layout fixe
• Treballem per una resolució concreta– Típica: 960px d’amplada (per pantalles de 1024px)
• Podem “quadrar” el disseny al pixel• Què passa si la pantalla es mes gran?
– Centrem contingut i omplim de blanc• Què passa si es més petita?
– Hem de fer scroll o es veure-ho reduit– Hem de fer una segona versió
Layout líquid
• No utilitza mides en pixels, sino en %• S’adapta a la mida de la pantalla• Un disseny pensat per una pantalla gran, adaptat a mòbil
no hi cap– Exemple: multiples columnes, imatges grans
• Un disseny pensat per pantalla petita es incomode en pantalla gran– Columna molt estreta / massa ampla
Idea del responsive design
• Consultem la resolució• Fem CSS adaptats a la resolució
– Líquid, fixe o una barreja depenent de la mida• Aixo ens permet
– Canviar mides segons la resolució– Amagar elements– Recolocar elements
• Volem una única versió del web!
Media queries
<link href="phone.css” rel="stylesheet" type="text/css" media=“screen and (max-width: 400px)" >
@media screen and (max-width: 400px) {…. /* estils propis de pantalla petita */}
@import url(phone.css) screen and (max-width: 400px)
Control del viewport
• iPhone suposa que la pantalla fa 980px– Tot el que posem es veu petit
• Si fem un CSS adaptat, volem evitar aquest comportament– No volem fer zoom ni scroll
<meta name="viewport" content="width=device-width, initial-scale=1, maximum-scale=1">
Problema: les imatges
• Problema típic dels layouts líquids• El text flueix en linies, les imatges no• Imatges massa petites o que sobresurten• Solucions
– Tallar les imatges (propietat de css overflow)– Imatges de fons amb CSS, que podem canviar depenent de la
resolució– Reescalar amb max-width: 100%
Consells
• Començar amb una versió que es vegi bé al mòbil – Base que es vegi bé en mòbil– @media amb min-width
• Provar amb diferents mides i navegadors• Intentar no partir de zero
– Skeleton, Amazium…. – El que s’ha convertit en stardard: Bootstrap
Una ajuda: bootstrap
• Framework de CSS desenvolupat per twitter– Garantia de confiança
• Permet que els nostres webs tinguin una presentació professional simplement afegint certes classes als nostres elements
• Permet personalització• Incorpora elements de responsive design
– Podem tenir-los o no!
Components
• Botons• Menus• Etiquetes• Missatges d’error• Barra de progrés• Formularis• Taules• …
La graella
• Permet colocar els elements de forma ordenada a la pàgina
• Un bon disseny té una graella– Mireu qualsevol diari
• Bootstrap te una graella de 12 columnes– 960px (fixa)– Líquida– Reponsive (tant liquida com fixa)
Conclusions sobre Responsive Design
• Reponsive design és ja una necessitat• Bootstrap aconsegueix fer-ho fàcil
• Bootstrap permet que un web tingui un disseny bastant acceptable sense necessitar un dissenyador ni confiar en que els informàtics triaran uns colors que no facin mal als ulls
Disseny per mòbils
Altres aproximacions
• Disseny per mòbils en HTML imitant una aplicació nativa.• Quan fer-ho servir?
– Què estem programant? – Una aplicació o un web?
• Concepte de webapp– “Carcassa” nativa amb una vista web dintre… amb aspecte
d’aplicació nativa
Idees de jQuery Mobile
• Atribut “data-role” als elements• Pàgines d’una aplicació en un sol HTML
– <div data-role=“page”></div>– Links entre pàgines amb anchors
• Elements típics– <div data-role=“header”> (content o footer)– <ul data-role=“listview”>– <a href=“” data-transition=“slide”>
Exemple de jQuery Mobile
• Llista d’elements• Passem a una segona pàgina amb
transició de desplaçament• Botó de tornar• Es veu com una pàgina normal i corrent si
desactivem els CSS + JS
Conclusions
• jQuery Mobile permet desenvolupar aplicacions mòbils amb aspecte natiu utilitzant únicament tecnologies web
• Últim quan realment no necessitem cap tecnologia pròpia del mòbil– No serveix per fer Angry Birds– Sí serveix per fer una banca on line
Accessibilitat
Accessibilitat
• És fer que tothom pugui fer servir el nostre web, incloent persones amb discapacitats (visuals, auditives i d’altres)
• Projecte amb l’empresa Technosite– Experts en accessibilitat– Colaboració amb la fundació ONCE
• Auditories a diferents webs de la UPC– Web institucional– Ateneas
• Versió 2.0 de les WAI
WAI 2.0
• Les pautes insisteixen en aquests temes– Alternatives textuals– Alternatives per continguts temporals– Adaptabilitat del contigut (a diferents dispositius)– Que es pugui distingir el text del fons– Que tot es pugui fer desde teclat– Donar suficient temps– Evitar continguts que puguin provocar atacs epilèptics– Fer continguts amb navegació– Fer els textos llegibles i entenibles– Predictibilitat. Que les coses funcionin com s’esperen– Ajuda als errors– Compatibilitat
Què ens han trobat?
• Els formularis han d’estar correctament marcats – Label per descriure els camps– Fieldsets per agrupar
• Els botons han de ser botons– Si es vol posar disseny ha de ser amb CSS
• S’han de fer servir colors amb suficient contrast• Les taules només s’han de fer servir per taules• S’ha d’especificar l’idioma de les pàgines• Els links han d’explicar on van. No posar mai “aqui” o “més
informació”– A l’obtenir una llista de links, no tenim informació
Què hem après?
• Una persona que no hi veu es basa molt en agrupacions lògiques de contingut– Llistes de continguts relacionats – Jerarquia de títols
• El javascript no està prohibit, tot i que ho pot semblar• El flash també pot ser accessible• Un web s’ha de poder “entendre” sense CSS i sense
imatges• Les imatges han de tenir descripció quan cal
– Si té un text al costat o es decorativa, no cal• Es MOLT difícil fer canvis quan no s’ha tingut en compte des
d’un principi
Conceptes bàsics d'aplicacions web.
De què parlarem?
• La interacció bàsica amb aplicacions web• Pas de paràmetres• Sessions• Cookies• Connexions a BD
Interacció bàsica
• Com pot comunicar-se una pàgina web amb el servidor? Utilitzant el protocol HTTP
• Seguint un link– Demana al servidor una certa URL, que pot ser una pàgina
generada pel servidor i el navegador la carrega.• Enviant un formulari
– Li enviem les dades que acabem d'omplir• Amb una petició tipus AJAX
– El navegador fa una petició "en background" i sense recarregar la pàgina
Pas de paràmetres
• GET– S'afegeixen els paràmetres a la URL
• POST– S'envien com una segona part de la petició
• Aquesta informació es posa al formulari que envia els paràmetres.
• Els parametres son strings. Qualsevol tipus complex requereix un tractament dels que s'encarrega la plataforma escollida
Sessions
• Cada petició HTTP és independent de les altres. Problema quan volem desenvolupar aplicacions.
• El protocol no proporciona cap mètode per saber des del servidor quines peticions ens arriben del mateix client, no incorpora el concepte de sessió.
• Tècniques per aconseguir tenir estat:– Cookies amb un identificador de sessió– Paràmetre ID_SESSIO
• Altres possibles tècniques– Adreça IP. No sempre funciona.
Cookies
• Un servidor ens pot enviar una cookie quan demanem qualsevol fitxer, afegint una capçalera de l’estil...
Set-Cookie: foo=bar; path=/; expires Mon, 21-Jan-2030
• Quan fem una altra petició al mateix servidor, enviem aquesta informació en una capçalera extra
Cookie: foo=bar
Les cookies no les demana el servidor: les envia automàticament el navegador com si fos un paràmetre
Cookies de sessio
• Les cookies que no tenen data de caducitat duren fins que es tanca el navegador. Son cookies de sessió
• Les plataformes de desenvolupament web més conegudes (JSP, ASP, PHP…) utilitzen cookies per mantenir la sessió
• La primera vegada que ens connectem al web, ens donen un identificador aleatori, que anirem enviant mentre no tanquem el navegador
• El servidor es guardarà valors associats a aquest identificador (una mena de taula de hash)
Paràmetre ID_SESSIO
• És un substitut de les cookies, amb exactament la mateixa idea de la cookie de sessió, però passat explícitament com un paràmetre o una part de la URL
• És més difícil d'implementar, perquè les nostres aplicacions l'han de passar explícitament a qualsevol petició que es faci al servidor, reescrivint les URL a les pàgines.
• Podem perdre la sessió si fem una petició al servidor sense l’identificador (per exemple, una pàgina estàtica)
• No es guarda cap informació: el id_sessió només serà vàlid fins que tanquem el navegador
Quan acaben les sessions?
• En sistemes orientats a connexió, la sessió acaba quan tallem la connexió. En web no existeix aixo
• 3 possibilitats– Tanquem el navegador. S’esborra la cookie pero no la
informació que teníem al servidor– Caduca. Els servidors es configuren perque la informació de la
sessió caduqui passats uns minuts d’inactivitat– Invalidem la sessio. Anem a una pàgina que esborra la
informació de la sessió• Una sessió no invalidada ni caducada és perfectament
vàlida al servidor. Si tenim el seu identificador, la podem “robar”
Accés a bases de dades
• Generar pàgines dinàmiques normalment implica treballar amb alguna bases de dades
• En una aplicació no web, podem connectar una vegada al principi de l'aplicació i desconnectar al final.
• En una aplicació web, no tenim clar quan ens desconnectem, així que no podem mantenir una connexió oberta "per sempre"
• Obrir i tancar connexions continuament cada vegada que hem d'accedir a la BD té un cost
Pools de connexions
• Solució: treballar amb connexions compartides• El servidor té oberta una connexió i nosaltres la
“demanem”, la utilitzem i la “tornem”• Normalment, no n’hi ha una, sino que tenim vàries
connexions obertes: pool de connexions• Normalment es configuren uns paràmetres
– Número mínim de connexions obertes– Número màxim (per no saturar la màquina)– Temps màxim d’utilització
• Si la nostra aplicació no torna les connexions, podem tenir problemes i es pot penjar el sistema!
Conclusions
• Programem amb el que programem, hem de tenir molt clars una sèrie de conceptes– Els diferents tipus de pas de paràmetres– Els problemes que ens poden portar les sessions– El fet de no tenir estat i els problemes que implica– Els problemes que poden representar els accessos a les
bases de dades
• La plataforma que escollim per programar probablement ja ens aillarà d'aquests conceptes, però és bo saber-los.
Les arquitectures d’aplicacions webbasades en Java
De què parlarem
• Java com a llenguatge per fer aplicacions web• Servlets• JSP• El concepte d'aplicació web• L'especificació JEE
Especificació de Servlets
• Són una sèrie de tecnologies per fer aplicacions web desde Java
• Compren diversos elements– Servlets pròpiament– JSP– Taglibs– Expression language– Concepte d’aplicació web (WAR)
• El servidor més conegut que suporta treballar amb servlets és Tomcat
• Veurem una a una totes aquestes tecnologies
Servlets
• Són unes classes java que permeten generar pàgines web quan s’executen en un servidor
• Tenim accés a la petició, la resposta, la sessió i a paràmetres d’aplicació
• Anem escrivint la pàgina des del programa, generant el codi HTML per programa. (Sí, es molt lleig!)
• Com funciona?– El servidor executa el mètode doGet() o doPost() del
servlet, que reben com a parametres la resposta i la petició
– Obtenim els paràmetres de la petició i construim el HTML utilitzant l’objecte resposta
Exemple de Servlet
import java.io.*;import javax.servlet.*;import javax.servlet.http.*;
public class ServletHola extends HttpServlet {public void doGet ( HttpServletRequest request, HttpServletResponse response) throws IOException, ServletException {
response.setContentType("text/html"); PrintWriter out = response.getWriter(); out.println(“Hola, ”+request.getParameter(“nom”); }}
JSP
• JSP permet tenir pàgines HTML amb codi Java que s'executa abans de tornar-la cap al client.
• No s’interpreta el codi cada vegada. La primera invocació fa que es compili la pàgina i es converteixi en un servlet.
• Qualsevol servidor on podem executar Servlets permet executar JSP, es la mateixa tecnologia
• Permet cridar altres classes Java, on hi haurà el gruix del codi. No hem de barrejar!
• La nostra aplicació estarà formada per– JSP per la presentació– Classes Java per la capa de negoci
La idea de Tag Libs
• JSP permet declarar nous tags per posar a les notres pàgines i associar-los a codi java
• Podem aconseguir una molt més gran separació entre presentació i codi: idea de JSP sense codi Java
• Per una llista de Tag Libs ja programats...– http://jakarta.apache.org/taglibs/
• Hi ha una llibreria estàndar (JSTL), que permet no haver de recorrer a Java dintre de JSP per moltes coses.
– Iteradors, condicionals...– Nou llenguatge per expressions: expression language– Ben utilitzada, converteix un JSP en una plantilla
Exemple de pàgina amb Tag Libs
<%@ page language='java’ %><%@ taglib prefix="c" uri="http://java.sun.com/jsp/jstl/core" %> <table><c:forEach var="row" items="${authors.rows}"> <tr> <td>${row.Au_ID}</td> <td>${row.Author}</td> <td>${row.YearBorn}</td> <td> </c:forEach></table>
68
Comunicació Servlet/JSP
• Un servlet pot passar variables cap a la JSP publicant-les en un entorn amb un nom– Sessió– Request
• JSP pot pintar-les utilitzant JSTL
• request.setAttribute(“authors”,authors);• request.getSession().setAttribute(“user”,user);
• Servlet = controlador (executa, prepara les vistes)• JSP = vista (només pinta, no executa res)
Java Web applicacions
• Concepte d’aplicació, no només pàgines independents.• Separarem en una estructura de directoris...
– Pàgines estàtiques i JSP– Classes Java que s’executen com a servlets– Classes Java d’utilitats (JavaBeans) o Taglibs
• Configurarem l’aplicació al fitxer web.xml…– Paràmetres d’inicialització– Mapejos de URL a servlets– Usuaris, grups i autoritzacions– Recursos externs que necessitem (p.e. DataSources)
• Empaquetarem tot aixo en un fitxer .WAR (Web Application Archive)
Exemple de Java Web Application
aplicacio/html/ – pàgines estàtiquesjsp/ - pàgines JSPcss/ – fulls d’estilimg/– imatgesjs/ - javascriptWEB-INF/ – directori no visible directament
web.xml – descriptor de l’aplicacióclasses/ – classes de l’aplicació i servletslib/ – llibreries (JAR) utilitzades per l’aplicació
Seguretat al web.xml
• En una aplicació web tenim seguretat declarativa utilitzant unes directives al fitxer web.xml
<security-constraint> <web-resource-collection> <web-resource-name>Zona protegida</web-resource-name> <url-pattern>/protegit</url-pattern> </web-resource-collection> <auth-constraint> <role-name>admin</role-name> </auth-constraint></security-constraint><login-config> <auth-method>FORM</auth-method> <form-login-config> <form-login-page>/jsp/login.jsp</form-login-page> <form-error-page>/html/fail_login.html</form-error-page> </form-login-config> </login-config>
La peça que falta
• Fem una seguretat basada en rols pero... d’on surten els usuaris i els rols que tenen?– La informació està configurada al Tomcat– No es l’aplicació que es preocupa d’on estan definits els seus
usuaris i passwords: aixi es més fàcil lligar-la amb sistemes externs
• Tenim diferents opcions de guardar-nos els usuaris i rols al servidor– Basat en base de dades– Basat en LDAP– En un fitxer de text– Qualsevol sistema que ens poguem programar nosaltres
Conclusions sobre Servlets/JSP
• Paquet amb l’aplicació– JSP, Servlets, classes, taglibs...– Fitxers de configuració
• Servidor que proporciona serveis de– Autenticació i autorització– Connexió a bases de dades
• S’ha convertit en un estàndard amb molta acceptació, especialment al mon empresarial
• Suport per fer aplicacions estructurades• Llibreries de qualsevol cosa: busqueu abans de desenvolupar!
Arquitectura JEE
• Arquitectura completa d’aplicacions de n-capes basat en la plataforma Java– És una ampliació de l’especificació de servlets.
• Idea principal: aplicacions a la capa intermitja, accessibles a través navegadors web o altres tipus de client
– Components per la lògica de negoci (Enterprise Java Beans)– Capa de presentació
• JEE és un Model de programació– Com hem de desenvolupar les aplicacions?
• JEE és una Plataforma: – Què necessitem per executar-les?
Servidors JEE
• Per poder executar una aplicació que utilitzi EJB, necessitem un servidor que sigui "JEE compliant"
• Hi ha una gran quantitat d'aquests servidors que basen el seu negoci en els serveis d'assessorament i consultoria
• A l'estar dirigits bàsicament a empreses es centren en temes d'alta disponibilitat.
– Jboss, líder dintre dels Open Source– Glassfish, ara en Open Source– Weblogic– IBM Websphere– ...
Google App Engine
• Es la plataforma d’execució d’aplicacions web de Google.• No es un servidor JEE ni un Tomcat, pero permet executar
aplicacions web Java (i python)• Us permet instalar i gestionar les vostres aplicacions,
desenvolupades desde Eclipse• Serveis que integra
– Autenticació (amb el username de google)– Persistència (en una tecnologia propia: BigTable)
• Bona idea si voleu fer pública la vostra aplicació
Conclusions d'arquitectures Java
• Java ha trobat un lloc com a plataforma pel desenvolupament d'aplicacions empresarials
• Podem utilitzar Java al servidor d’una forma simple (Servlets / JSP) o bé l’arquitectura completa JEE
• Una aplicació JEE es pot executar en qualsevol servidors que compleixi les especificacions teòricament "sense canvis"
• És necessaria tota aquesta complexitat de JEE? Normalment, no– Per exemple, el Racó: són Servlets i un Tomcat
Frameworks i altres llibreries d’aplicacions web
Frameworks
• Que és exactament un framework?• Struts• Spring i com lligar-lo amb Struts• Hibernate• L'arquitectura completa
• Mantra d’aquesta lliçó:– Tothom es troba els mateixos problemes– Hi ha gent que sap mes que nosaltres que els ha resolt– No reinventem la roda
Framework / plataforma / llibreria
• Una plataforma normalment implica una decisió de – Hardware– Servidors– Llenguatge de programació
• Una llibreria normalment s’utilitza per solucionar un problema concret
• En canvi un framework... Un framework, es un conjunt de llibreries per una determinada
plataforma que condicionen totalment la forma en que ens plantegem, organitzem i desenvolupem una aplicació
Perquè un framework?
• En un primer moment– Són excessivament restrictius– Les coses passen i no sabem perque
• Amb el temps– No hem de pensar desde zero. Programar es converteix en
“omplir forats”– Facilitem el manteniment. Qualsevol persona que conegui el
framework triat podrà modificar fàcilment la nostra aplicació• En general es bo utilitzar un framework quan veiem que la
nostra aplicació pot ser complexa o altres persones l’hauran de mantenir
• El problema es: quin framework triar?
Frameworks per JEE
• Struts– Capa de presentació– Permet estructurar les aplicacions segons el patró MVC
• Spring– Ens permet estructurar la capa de domini– Es basa en el patró Dependency injection
• Hibernate– No es pot considerar propiament un framework, sino un mapejador
d'objectes a bases de dades relacionals
• Els veurem un a un per veure que ens poden oferir i entendre com fer una aplicació amb tots ells
L'aplicació d'exemple
• Farem un petit gestor de tasques• Una tasca tindrà un nom i una prioritat• Hi ha haurà una pantalla de llistar les tasques• Podrem editar-les, esborrar-les i crear-ne de noves
• Una paraula d'advertència. És necessari utilitzar 3 frameworks per una aplicació tan tonta?
• La resposta es NO. – No hem de fer aplicacions "overengineered". – El codi que menys falla es aquell que no existeix.
Forçant MVC: Struts
• Struts és un framework que ens permet forçar les nostres aplicacions a utilitzar MVC
– Proporciona un servlet controlador configurable amb un fitxer XML amb les accions a executar per cada una de les URL de l'aplicació (les classes Actions)
– Tenim uns objectes (els ActionForms) que permeten accedir desde les Actions als valors entrats als formularis de les nostres pàgines.
– Les Actions actuen sobre les classes Java que formen el model, que son les que realment fan la feina
– A les vistes, ens proporciona tags que ens ajuden a visualitzar les dades dels formularis o obtingudes per les Actions
Exemple: form nova tasca
<html:form action="/guardarTasca"> <html:hidden property="id" /> Nom: <html:text property="nom"/> <br> Prioritat: <html:text property="prioritat"/> <html:submit value="Guardar"/></html:form>
• Taglibs pels elements del form (nom, propietat, id) que es mapegen amb les propietats de l'ActionForm
• Fem referència a URL declarades al struts-config.xml
El ActionForm associat al formulari
<form-bean name="tascaForm" type="org.apache.struts.action.DynaActionForm"><form-property name="id"
type="java.lang.Integer" initial="-1" /><form-property name="nom"
type="java.lang.String" /><form-property name="prioritat"
type="java.lang.Integer" initial="1" /> </form-bean>
• Descrivim les propietats del form• Pot set també una bean
Una Action al struts-config.xml
<action path="/guardarTasca" type="presentacio.GuardarTascaAction" name="tascaForm" scope="request"> <forward name="success" path="/llistaTasques.do" redirect="true"/> <forward name="error" path="/errorTasca.jsp"/> </action>
• Per cada acció de la nostra aplicació tenim– què s'executa (en aquest cas el GuardarTascaAction)– quins paràmetres li arriben (estaran al tascaForm)– vistes on podem anar després de executar-la
La Action GuardarTascaAction
public class GuardarTascaAction extends Action { public ActionForward execute( ActionMapping mapping, ActionForm form, HttpServletRequest request, HttpServletResponse response) throws Exception { DynaActionForm f=(DynaActionForm)form; try {
// Crear una tasca i guardar-la obtenint les dades de // f.get("nom") i f.get("prioritat") return mapping.findForward("success"); } Catch (Exception e) { return mapping.findForward("error"); } }}
Exemple de Action i Vista lligades
• La Action obté una llista de tasques... Tasca[] tasques= gt.llistar();request.setAttribute("tasques",tasques);return mapping.findForward("success");
• La vista visualitza les dades colocades per la Action...<c:forEach var="tasca" items="${tasques}"><tr><td>${tasca.id}</td><td>${tasca.nom}</td><td>${tasca.prioritat}</td></tr></c:forEach>
• La Action “fa coses” i la vista “visualitza”
Flux d'una aplicació struts
• Demanem una URL struts (normalment acaba en .do)• Struts empaqueta els paràmetres (si n'hi ha) en la classe de tipus
ActionForm especificada.• Mirem al fitxer XML quina classe hem d'executar per la URL que
ens han demant• Executem el mètode execute() de la ActionClass que toqui
passant-li el ActionForm amb els paràmetres• La Action retorna quina vista ha de mostrar i posa les dades
necessaries a l'entorn.• La vista es construeix consultant les dades que la Action li
proporciona
Flux d'una aplicació struts
Més sobre struts
• D'entrada sembla complicat• En una aplicació gran, ajuda molt a la organització.• No ens obliga a utilitzar tecnologies concretes
– domini o persistència com volguem– Les vistes, no necessàriament JSP
• Que mes permet?– Sistematitzar les validacions. Podem fer que el ActionForm validi els
valors entrats, per programa o per configuració– Plugin Tiles. Idea de jsp:include– Internacionalització dels missatges (fitxer properties)
Conclusions sobre Struts
• Struts es un dels primers frameworks MVC que va sortir per Java
• Permet automatitzar processos que poden donar lloc a errors com per exemple les validacions
• Ordena el nostre codi– Les Actions no tenen res de codi de presentació– El pas de paràmetres cap a les accions queda especificat a
través de les propietats dels objectes Form– Les vistes no "executen" res, només mostren– El nostre struts-config.xml mostra el flux de l'aplicació (el
podriem dibuixar com un diagrama d'estats)
Spring
• Es un framework de frameworks, pero en aquest cas ens centrarem en el contenidor lleuger
• Serveix per organizar millor la nostra capa de domini– Programació basada en interfaces– Èmfasi en el baix acoblament de les classes
• Exemple: l'aplicació de les tasques– Tindrem la classe "Tasca"– Necessitarem un GestorTasques, que serà una façana de tot
el nostre sistema– El GestorTasques utilitzarà un TascaDAO per guardar les
tasques. Per ara, en tindrem un de prova
Capa de domini
GestorTasques
TascaDAO
<<interface>>
ProvesTascaDAO JDBCTascaDAO
DataSource
Tasca
Si no utilitzem Spring...
• Qui crea el gestorTasques? Es crea en cada petició?– Podem utilitzar el patró Singleton
• Si el gestorTasques utilitza un objecte de tipus DAO, li especifiquem quin es per programa?– Si, es clar. Com a molt podriem tenir un fitxer de propietats si
volem que es pugui canviar
• Com li diem la base de dades al DAO?– Utilitzarà JNDI per anar-la a buscar o bé la configurarem en un
fitxer de propietats també
97
Spring = Ikea
• Tenim una sèrie de peces• Les peces tenen uns “forats” que
permeten encaixar-les entre elles• Tenim un llibre d’instruccions• Seguint el llibre d’instruccions podem
muntar el moble
• El muntador no ve dintre del paquet.• Podem arribar a muntar les peces d’una
forma diferent que també ens serveixi
Si utilitzem Spring...
• Spring ens permetrà– Llegir un fitxer de configuració on li diem els objectes que formen el
nostre sistema– Si una classe depèn de una altra, farem aquesta dependència explícita
al fitxer. A nivell de programació, tindrem un “setter” d’aquesta propietat.– Spring fa de “muntador” de l’aplicació
• Es basa en Inversion of Control o principi de Hollywood,– "No ens truquis, dona'ns el número i et truquem nosaltres"– No creis els objectes. Deixa un "set" i te l'assignarà Spring– Flux de l’aplicació menys evident
Què hauríem d’afegir al codi?
• El nostre DAO necessita un Datasource?
DataSource setDataSource (Datasource ds) { this.ds=ds;}
• El nostre GestorTasques necessita un TascaDAO?
TascaDAO setTascaDAO (TascaDAO dao) { this.dao=dao;}
Fitxer de configuració per proves
<beans><bean id="gestorTasques" class="exemple.GestorTasques"> <property name="tascaDAO"> <ref bean="provesTascaDAO"/> </property></bean><bean id="provesTascaDAO" class="exemple.ProvesTascaDAO"> <property name="tasques"> <list> <bean class="exemple.Tasca">
<property name="id" value="1"/> <property name="nom" value="Acabar transparencies"/> <property name="prioritat" value="1"/></bean> ...
</list> </property></bean></beans>
Fitxer de configuració real
<beans><bean id="mysqlDataSource" destroy-method="close">
<property name="driverClassName" value="com.mysql.jdbc.Driver" /><property name="url" value="jdbc:mysql://localhost:3306/aules" /><property name="username" value="aules" />
</bean><bean id="gestorTasques" class="exemple.GestorTasques"> <property name="tascaDAO"> <ref bean="JDBCTascaDAO"/> </property></bean><bean id="JDBCTascaDAO" class="exemple.JDBCTascaDAO"> <property name="dataSource"> <ref bean="mysqlDataSource"/> </property></bean></beans>
Què fa Spring amb aixo?
• El contenidor (ApplicationContext) només es crearà una vegada, quan s’inicialitzi l’aplicació, que pot ser web o no
ApplicationContext ctx = newClassPathXmlApplicationContext("applicationContext.xml");
• En el moment en que inicialitzem el contenidor...– Spring parsejarà el fitxer i crearà les instàncies– Cridarà els “setters” de les propietats per passar-li els paràmetres
especificats• A través del contenidor, podrem accedir des de la nostra aplicació a
les instàncies creades
ctx.getBean("gestorTasques"));
Què mes ens permet Spring?
• Permet fer referències per tipus – exemple: crear un DataSource i passar-lo a totes les classes
que en necessitin un• Spring JDBC
– Exepcions “amb sentit”– Ens podem oblidar d’obrir i tancar connexions
• Spring MVC– Similar a struts, però integrat al contenidor.
• AOP (Aspect Oriented Programming)– Permet configurar codi a executar quan cridem un mètode
d’un bean obtingut de Spring. Interceptors.– Serveix per marcar transaccions
Conclusions sobre Spring
• Es un framework poc habitual: no ens condiciona massa la forma de programar, només ens estructura
• Un cop entès el concepte de Inversion of Control i utilitzat de forma bàsica, no es gens complicat
• Les nostres classes no son conscients de que l’estem utilitzant. Fins i tot podriem arribar a canviar-lo o prescindir d’un framework de la capa de domini
• Únic punt negatiu: els fitxers de configuració son horribles.
Hibernate
• Intenta solucionar l’etern problema de la persistència– Per un costat tenim la nostra aplicació amb objectes– Per l’altre, una BD relacional (mysql, Oracle…)– Com les casem? hibernate
• Hibernate es un mapejador Objecte-Relacional. No és un framework tal i com l’hem definit.
• Fitxer XML amb – els mapejos propietats <-> columnes– relacions entre elles
• Ofereix una capa de persistència pels objectes• A la vegada, ofereix una forma de consultar-los
– Igual que SQL, pero amb els objectes
Hibernate: exemple de guardar un objecte
// ...Configuration cfg = new Configuration() .addClass(Product.class) .addClass(Order.class) .addClass(OrderItem.class);
// ...Order order = new Order();order.addProduct(milk, 3);order.addProduct(coffee, 5);
// ...sess = sf.openSession();Transaction t = sess.beginTransaction();sess.save(order);t.commit();sess.close();
Hibernate: exemple de consulta
// ...String query = "select o from o " + "in class test.hibernate.Order " + "where o.priceTotal > :priceTotalLower " + "and o.priceTotal < :priceTotalUpper";
// ... Query q = sess.createQuery(query);q.setDouble("priceTotalLower", Double.parseDouble(args[0]));q.setDouble("priceTotalUpper", Double.parseDouble(args[1]));
List list = q.list();// ...sess.close();// ...
Relacions
• Implementa relacions entre classes• Exemple: equips i jugadors
<hibernate-mapping> <class name="example.Team" table="teams"> <id name="id" column="team_id" type="long" unsaved-value="null"> <generator class="hilo"/> </id> <property name="name" column="team_name" type="string" length="15" not-null="true"/> <property name="city" column="city" type="string" length="15" not-null="true"/> <set name="players" cascade="all" inverse="true" lazy="true"> <key column="team_id"/> <one-to-many class="example.Player"/> </set> </class></hibernate-mapping>
Com soluciona les relacions?
• A partir d’aquest fitxer, genera l’esquelet de la classe• Bidireccional:
– Des del jugador, podem accedir a l’equip (getTeam)– Des de l’equip podem accedir al jugadors (getPlayers)– Ens torna un Set (conjunt) de resultats
• Lazy: – Quan carreguem un jugador, no carrega els jugadors– Quan volem els jugadors, s’accedeix a BD– No podem tancar la sessió
• Cascade– Mateix sentit que a bases de dades
Hibernate a l'exemple de les tasques
• Farem un DAO utilitzant Hibernate• Li passarem la configuració amb Spring• Mapejarem la taula "tasques"
<hibernate-mapping> <class name="exemple.Tasca" table="TASQUES"> <id name="id" column="ID"> <generator class="increment"/> </id> <property name="nom" column="NOM"/> <property name="prioritat" column="PRIORITAT"/> </class></hibernate-mapping>
Conclusions sobre Hibernate
• Hibernate posa una capa respecte a executar SQL contra una base de dades– Pot tenir mètodes de cache que acceleren les nostres
consultes i optimitzar la velocitat– Pot generar un SQL molt més costós que el que podriem
generar nosaltres mateixos directament• En general, Hibernate requereix uns coneixements
importants de la plataforma per treure el màxim rendiment• Consell particular: Si no us espanta el SQL, utilitzeu
JDBCTemplate. No es tan sofisticat, pero dona més sensació de control.
Resumint l'exemple
• Amb Struts hem fet la capa de presentació– pantalles amb JSP– Controlador amb les "Action"
• Amb Spring hem organitzat la capa de domini– Creació i configuració dels gestors– Configuració general de l'aplicació
• Amb Hibernate hem accedit a la BD– Hem accedit a una base de dades relacional sense abandonar
la orientació a objectes• Hem utilitzat les 3 tecnologies conjuntament sense
interferències entre elles
Relació entre Struts i Spring
• Plugin de struts al fitxer struts-config.xml
<plug-in className="org.springframework.web.struts.ContextLoaderPlugIn"> <set-property property="contextConfigLocation" value="/WEB-INF/applicationContext.xml"/></plug-in>
• Canviem les ActionClass per ActionSupport
public class EditarTascaAction extends ActionSupport { public ActionForward execute(...) throws Exception {
ApplicationContext ctx = getWebApplicationContext(); GestorTasques gt= (GestorTasques)(ctx.getBean("gestorTasques"));
Cap on anem?
• Struts 2– Evolució de Struts, amb alguns canvis importants– Ha agafat idees de Spring (dependency injection)
• Anotacions– Disponibles des de Java 1.5– Permet fer comentaris que després es puguin llegir, es a dir, afegir
informació a les classes, mètodes i propietats– Permet estalviar-nos alguns fitxers de configuració– Exemples: columnes de BD a que equivalen propietats
Conclusions de frameworks
• Utilitzar Spring, Struts i Hibernate es complex• La corba d'aprenentatge es important• Costa dominar-los al 100%• Canviem programació per configuració de fitxers XML• Tenim més codi del que voldríem, tot i que tenim eines que ens
ajuden a generar-lo• Tot es dolent? No
– Ens obliguen a fer la nostra aplicació més ordenada– Importants per la mantenibilitat
Programar pensant en la seguretat
Programar pensant en la seguretat
• Les aplicacions web mal programades programades poden ser un problema se seguretat
• Permeten recuperar informació de la màquina• Un error pot fer que poguem executar codi amb els
privilegis de l’usuari que executa el web• Manipulant l’aplicació, podem fer coses que no hauriem de
poder fer• … i tot aixo via web, sense arribat a entrar a la màquina!
Fiar-se dels paràmetres
• Qualsevol paràmetre que arribi a les nostres pàgines de mans del client ha de ser validat– L’usuari pot canviar els valors que apareixen a qualsevol URL
nomes editant la línia i provant.• Exemple de vulnerabilitat
– Seleccionem un producte en un catàleg– Enviem a la pàgina que afegeix al carro el identificador del
producte i el preu• Solució:
– Validar sempre els paràmetres
Autorització d’usuaris incorrecta
• Quins rols poden accedir a quins serveis? • Què passa si accedim a la URL d’una pàgina que només
esta visible per un usuari privilegiat amb un usuari normal?• Exemple:
– Web protegit. Sempre demana password– Formulari que comprova que siguem “admin”– El “action” d’aquest formulari no esta protegit
• Solució: – Seguretat declarativa sempre que es pugui– Revisar qui pot accedir a cada pàgina
Session hijacking
• Si aconseguim el ID de sessió d’un altre usuari, ens podem fer passar per ell temporalment.– Podem “esnifar” el ID d’un altre usuari amb la xarxa– Podem mirar la cookie al seu navegador– Si esta a la URL, ens la podem copiar (difícil si es llarga)
• Solució: – ID llargs– Sessions millor per cookies– Nomes HTTPS– Caducitat curta
Atacs de força bruta
• Hi ha diccionaris de passwords habituals• Aprofitar les preguntes per recordar el password (solen ser
més facils que un password i no sempre son personals)– Com es diu el meu gos? Segurament molta gent ho sap
• Solució: – Bona política de passwords– Deshabilitar els comptes després de X accessos
Cross Site Javascript (XSS)
• Es que un altre usuari del web miri una pàgina on hi ha codi JavaScript escrit per l’atacant
• Exemple: – un forum, un sistema de missatges on podem enviar algo que
veurà un usuari privilegiat.– El codi, que s’afegeix a la pàgina, podria enviar la cookie de
sessio per http a un servidor extern– Manipular el DOM per canviar el contigut
• Solució:– Filtrar els tags en qualsevol paràmetre que s’envii cap a la
nostra aplicació
Cross Site Request Forgery (CSRF)
• Consisteix construir un link que faci una operació en un web en el que l’atacant ja ha entrat
• Exemple (una mica irreal):– Tenim obert el nostre banc i el webmail al mateix temps– Ens arriba al webmail amb un link de l’estil
http://www.meubanc.com/transfererir?origen=xxx&desti=yyy&euros=1000
• Massa evident?– Els links es poden dissimular: frames ocults, imatges…
• Solució:– Com usuari, no tenir finestres obertes d’entorns delicats quan
mirem altres webs– Tokens per fer peticions úniques, operacions només via
POST…
Injecció de codi
• Modificar alguns dels paràmeters per fer que l’aplicació executi codi que “injectem” a l’aplicació
• SQL (en l’autentificació d’usuaris)– Select * from users where user=‘$u’ and pass=‘$p’– Fem que $p valgui “x’ or ‘1’=‘1”
• Comandes de sistema operatiu– System (“sendmail $mail”)– Fem que $mail valgui “[email protected];rm –rf /”
• Directori “../”– fopen ($fitxer)– Li passem “../../../etc/password”
• Solució:– Validar paràmetres
Exemple de SQL Injection
Tractament dels errors incorrecte
• Els errors poden desvetllar informació sobre el sistema– Versions concretes de servidors– Pantalles d’error on mostra el codi que falla– Errors SQL que ens permeten coneixer les taules– Errors de connexió que mostren on ens intenten connectar– Errors relacionats amb fitxers– Ens mostra el path del fitxer que no troba– Ens diu que no tenim accés (no que no existeix)
• Solució– Configurar els servidors de producció perque els errors no es
mostrin mai en pantalla, sino en fitxers de log
Emmagatzemament insegur
• Guardar informació sensible de forma insegura al servidor.• Passwords per les connexions
– I si estan en un fitxer .inc i aquest fitxer es visible?• Números de compte corrent
– I si podem fer SQL injection i veure aquest camp?• Fitxers de configuració
– Pot ser que estiguin en un directori mapejat al web?– Pot ser que hi poguem accedir amb ../
• Solució– Llista de les informacions crítiques– Veure que podem fer per que no estiguin facilment disponibles
Configuració incorrecta del sistema
• Deixar els exemples• Comptes per defecte (amb passwords coneguts)• Deixar la possibilitat del llistat de fitxers en un directori on hi
ha informació privilegiada• Solució:
– Mirar amb lupa les configuracions. – Vigilar els valors per defecte – Treure tot el que específicament no necessitem
Una ajuda: firewalls d’aplicació
• Element que es coloca entre el navegador i l’aplicació i que analitza les peticions HTTP
• Talla la petició si detecta un patró maliciós– Regles genèriques (ex:<script> als paràmetres)– Regles adaptades a les nostres aplicacions
• Mateixos problemes que els antivirus– Falsa sensació de seguretat– Les regles han d’estar al dia– Poden donar falsos positius
• Exemple: modsecurity (modul de Apache)
Uns amics: OWASP
• Organització no lucrativa que vetlla per la seguretat a les aplicacions web
• Bones pràctiques• Llistes d’errors més comuns (OWASP Top 10)• Llibreries per fer validacions i altres eines• Conferències (també a Espanya)• Llibres• WebGoat: curs pràctic de seguretat web
– Reptes de hacking en una aplicació “mal feta”
Conclusions
• Validar, validar i validar.• Assegurar-nos que coneixem be els nostres servidors i
tenir les configuracions controlades.• Evitar fer coses que algú ja ha fet i ha comprovat que no té
problemes de seguretat– No tornar a implementar sistemes d’autentificació
• Si volem un nivell més de seguretat, posar un firewall d’aplicacions
• Algú pot utilitzar les nostres pàgines de forma diferent a com fem que les utilitzin.
S’ha acabat
Per consultes sobre el seminari o temes web en [email protected]
Per suggerències o problemes amb el web de la [email protected]
Per suggerències o problemes amb quasevol tema dels servidors o aules informàtiques de la FIB
