LCFIB Jordi Girona 1-3, Mòdul B6 E-08034 Barcelona, Spain [email protected] Tecnologies web Aules...

LCFIBJordi Girona 1-3, Mòdul B6E-08034 Barcelona, Spain

[email protected]://www.fib.upc.es/LCFIB/

Tecnologies webAules d'empresa 2004 - LCFIB

Una visió global de les tecnologies i arquitectures de les aplicacions web

Aules d'empresa 2004 - LCFIB

Índex

LCFIB. Qui som? Les bases de les tecnologies web Conceptes de seguretat aplicada al web Arquitectures per aplicacions web Arquitectures complexes: J2EE vs. .NET Servidors d’aplicacions Un cas pràctic. El web i la intranet de la FIB



LCFIB. Qui som?


Qui som? Què fem?

Laboratori de Càlcul de la FIB Uns 100 treballadors, entre becaris, col·laboradors i plantilla Oferir suport informàtic a professors, alumnes i PAS de la FIB

– Aules informàtiques

– Servidors i gestió del software

– Desenvolupament i manteniment de les aplicacions de matrícula i gestió acadèmica

– Manteniment de la Xarxa

– Web i Racó Projectes a partir de convenis amb entitats externes

(Ajuntament, Generalitat, Fundacions…)


On estem?

Soterrani 1 i 2 de l’edifici B6 Finestretes d’operació del mòdul A5 i C6 Sala a l'edifici C5 (només projectes externs)

A5

C6

B6

C5


Sistemes Gestió

Ofimàtica

Operadorsd’aula

Web

Lotus Notes

Gestió acadèmica

Manteniment

Xarxa

Sistemes

Simulació

Web

i2cat

PRISMA...

Estructura

Projectes


Projectes realitzats al LCFIB

Aplicació "Barcelona a l’escola", per l'IMEB Intranet de Camins, Campus de Terrassa i Manresa, l’Àrea de

Relacions Internacionals i de Intercampus El web de l’Univers de la UPC i del Cercle Fiber Prototipus "Oficina mòbil inteligent" i quioscos d’informació

amb la Fundación Airtel Jocs via web per les eleccions catalanes Col·laboració amb Nortel per fer aplicacions de telefonia mòbil

de nova generació Col·laboració amb la Fura dels Baus a l'espectacle ØBS Gestió acadèmica i matrícula de la EUETIB i ESAB ...


Projectes actuals

Aplicació de Convenis de cooperació educativa de la UPC Web i intranet del Cercle Fiber Col·laboració en el projecte i2cat. Projecte Dexvio Simulació de la nova terminal de l’aeroport Projecte PRISMA: Nova gestió acadèmica de la UPC Gestió d’escoles de primària i instituts pel departament

d’ensenyament de la Generalitat Auditoria del portal cat365 Gestió acadèmica via web de l’Escola de d’Expressió ...


Autopropaganda

Vols venir a treballar amb nosaltres?

– Surten places de becari sovint

– Bon ambient de treball

– Facilitat per combinar-ho amb els estudis

– Utilització de noves tecnologies

– Possibilitat d’aprendre coses noves

Com assabentar-se que necessitem algú?

– Borsa de treball del web de la FIB

– Cartells als aularis



Les bases de les tecnologies web


Les bases del web

De què parlarem?

– Arquitectura del web

– Protocol HTTP

– HTML

– Servidors web

– CGI

– Pas de paràmetres

– Cookies


Una mica d’història

Tim Berners-Lee, pare del web

El web va néixer al CERN l’any 1991 Compartir informació de recerca Basat en un format (HTML) i un protocol (HTTP) Desenvolupat en un NeXT Primer servidor web: Cern Primer navegador “conegut”: Mosaic


Arquitectura del web

Client / Servidor

El servidor web publica una part del seu disc amb informació pública

Els navegadors es connecten utilitzant el protocol HTTP al servidor i demanen les pàgines

A les pàgines hi ha links amb URL que poden apuntar a altres màquines. Idea de hypertext

Servidor Web

URL

pàgina

Pàgines


El format HTML

Format de les pàgines web Fitxer de text amb informació + marques (tags) Estàndard i independent de plataforma Idea inicial: representar l’estructura lògica del document

– Sense tags de format

– No ens importava la seva representació Evolució actual

– Tags de format

– Tags no estàndard

– Problemes per aconseguir que funcioni a tots els navegadors


Quan HTML es queda curt

Javascript / VBScript

– Útil per validacions i poca cosa més. HTML Dinàmic

– Problemes d’incompatibilitat ActiveX

– Només Windows Java (Applets)

– Lent, però pot ser útil en segons quin context Flash

– Hem passat de les “pijades” a una utilitat real PDF

– Quan volem un document amb un format concret


Servidors web

Escolta pel port 80 peticions HTTP Torna al servidor fitxers HTML o qualsevol format que el

navegador pugui reconèixer 2 formes de respondre a les peticions

– Tornant una pàgina estàtica de disc

– Executant una aplicació que genera la pàgina

– Passant la petició a un altre servidor Altres característiques d’un servidor

– Permet configurar les pàgines a publicar, pàgines d’error, redireccions...

– Deixa logs dels accessos per poder fer estadístiques

– Permet restringir l’accés als continguts


El protocol HTTP

Protocol de comunicació entre els navegadors i servidors web

Funciona sobre TCP/IP com tots els d’Internet

El navegador fa peticions de URL (pàgines HTML o altres fitxers) i el servidor torna aquest fitxer juntament amb altres informacions complementàries

No té estat. Cada petició que fem des d’un navegador és independent de les altres.

Es molt senzill d’implementar. D’aquí el seu èxit


Exemple de petició (1)

URL: http://www.servidor.com/pagina.html Pàgina HTML amb una imatge

El navegador obre una connexió al servidor www.servidor.com, port 80

Fem la petició de la pagina /pagina.html i esperem a que arribi Tanquem la connexió Analitzem la pàgina i veiem que falta la imatge Obrim una nova connexió Fem la petició de la imatge i esperem a que arribi Tanquem la petició


Exemple de petició (2)

GET /pagina.html HTTP/1.0

Content-type: text/html

Contingut de la pàgina

GET /imatge1.gif HTTP/1.0

Content-type: image/gif

Contingut de la imatge

Navegador Servidor Web


Més sobre les peticions

La versió més bàsica de petició, simplement demana la pàgina, tal com hem vist.

Podem enviar més informació quan fem la petició

– Versió del navegador

– Formats acceptats

– Idiomes acceptats

– Pàgina d’on venim (referer)

– Cookies i paràmetres (més sobre això tot seguit)

– Usuari i password La majoria d’aquests paràmetres es poden guardar als fitxers

de logs per treure estadístiques.


Més sobre les respostes

Abans d’enviar-nos el contingut que hem demanat, ens arriben unes capçaleres informatives amb

– El codi d’error retornat (OK, no trobat, redirecció…)

– El tipus mime del document que se’ns envia

– Altres capçaleres opcionals

Amb el codi d’error, el navegador pot ensenyar-nos una pàgina informativa, redireccionar-nos a una altra pàgina…

Amb el tipus mime, el navegador sap si es tracta d’un tipus que pot ensenyar o ha d’obrir una aplicació externa (no es guia per les extensions, com windows)


Problemes del HTTP

La versió més bàsica del protocol, sempre obre i tanca les connexions

– No existeix el concepte de “connectar-nos” a un servidor web igual que ens connectem a un FTP o fem un telnet a una màquina.

– Els servidors són més senzill d’implementar, ja que no guarden gens d’informació del client

Millora: utilitzant la capçalera “keep-alive”, podem fer que en una mateixa connexió ens carregui totes les imatges d’una pàgina

Versió 1.1: més millores per optimitzar les connexions i suport per cachés.


CGI. Primer pas cap als continguts dinàmics

Common Gateway Interface És una forma d’executar programes (CGI) al servidor com a

resposta a les nostres peticions de pàgines Totalment estàndard: tots els servidors web tenen la

possibilitat d'executar CGI Com funciona?

– El CGI ha d’escriure la pàgina igual que si estigués escrivint per la sortida estàndard.

Com sap el servidor si una pàgina és un fitxer que pot servir directament o bé l’ha d’executar per tornar el contingut?

– Per URL, per permisos, pel directori on esta, per exensió...


CGI. Pas de paràmetres

Quan omplim un formulari i enviem la informació, hem de fer arribar aquests paràmetres al servidor web

Dos formes: GET o POST

– GET: Els paràmetres surten a la URL

– POST: Els paràmetres s’envien com una segona part i no es poden guardar ni es veuen.

<FORM METHOD=“POST” ACTION=/cgi-bin/search.pl>

Consells

– GET: per consultes o coses que pot interessar tenir la URL

– POST: per fer transaccions o quan no interessa veure els parametres (per exemple, al fer un login)


Petició GET real

GET /cgi-bin/search.pl/cgi-bin/search.pl?lang=0&section=0&s ch_spec=segon+cicle HTTP/1.1

Accept: image/gif, image/x-xbitmap, image/jpeg, image/pjpeg, application/vnd.ms-excel, application/msword , application/vnd.ms-powerpoint, */*

Accept-Language: es

Accept-Encoding: gzip, deflate

User-Agent: Mozilla/4.0 (compatible; MSIE 6.0; Windows NT 5.1; Q312461; COM+ 1.0.2204)

Host: www.fib.upc.es

Connection: Keep-Alive


Petició POST real

POST /cgi-bin/search.pl/cgi-bin/search.pl HTTP/1.1

Accept: ….

Accept-Language: es

Content-Type: application/x-www-form-urlencoded

Accept-Encoding: gzip, deflate

User-Agent: Mozilla/4.0 (compatible; MSIE 6.0; Windows NT 5.1; Q312461; COM+ 1.0.2204)

Host: www.fib.upc.es.org

Content-Length: 37

Connection: Keep-Alive

Cache-Control: no-cache

lang=0&section=0&s ch_spec=segon+cicle


CGI. Execució

El servidor detecta que ha d'executar un CGI S'executa el CGI en un nou procés, passant-li els paràmetres El CGI construeix la pàgina de resposta i la retorna al servidor

Navegador

Servidor Web

CGI

BD

URL+ param.

param.

pàginapàgina


Més coses sobre els CGI

Històricament, els CGI es posen en un directori “/cgi-bin” En el món UNIX, els llenguatges més habituals per fer CGI

són

– Shell script (coses molt senzilles)

– PERL Com arriben els paràmetres a un CGI?

– GET: variable d’entorn (mida limitada)

– POST: entrada estàndard (sense limitacions) A part dels paràmetres, arriben altres valors importants com a

variables d’entorn: versió navegador, IP, cookies, usuari connectat...


Entorn d’un CGI

SERVER_SOFTWARE Apache/1.3.20

SCRIPT_URI http://www.fib.upc.es/cgi-bin/env.pl

REMOTE_ADDR 193.153.175.117

SCRIPT_URL /cgi-bin/env.pl

SERVER_PROTOCOL HTTP/1.1

REQUEST_METHOD GET

QUERY_STRING parametre=prova

HTTP_USER_AGENT Mozilla/4.0 (compatible; MSIE 6.0; Windows NT 5.1; Q312461; COM+ 1.0.2204)

HTTP_ACCEPT image/gif, image/x-xbitmap, image/jpeg, image/pjpeg, application/vnd.ms-excel, application/msword, application/vnd.ms-powerpoint, */*


Entorn d’un CGI (2)

HTTP_CONNECTION Keep-Alive

REMOTE_PORT 2117

SERVER_ADDR 147.83.41.11

HTTP_ACCEPT_LANGUAGE es

SCRIPT_NAME /cgi-bin/env.pl

HTTP_ACCEPT_ENCODING gzip, deflate

SCRIPT_FILENAME /home/soft/apache/cgi-bin/env.pl

SERVER_NAME www.fib.upc.es

REQUEST_URI /cgi-bin/env.pl

SERVER_PORT 80

HTTP_HOST www.fib.upc.es


Exemple de CGI en PERL (1)

#!/usr/local/bin/perl -w

$sendmail = '/usr/sbin/sendmail'; # where is sendmail?

$recipient = '[email protected]'; # who gets the form data?

use CGI;

$query = new CGI;

$mail_body = '';

foreach $field (sort ($query->param)) {

foreach $value ($query->param($field)) {

$mail_body .= "$field: $value\n";

}

}


Exemple de CGI en PERL (2)

open(MAIL, "|$sendmail -oi -t") or die "Can't open pipe to $sendmail: $!\n";

print MAIL "To: $recipient\n";

print MAIL "Subject: Enquesta web\n\n";

print MAIL "$mail_body";

close(MAIL) or die "Can't close pipe to $sendmail: $!\n";

print "Content-type: text/html\n\n";

print <<"EOF";

<HTML>

<BODY>

<P>Gracies per participar a l'enquesta</P>

</BODY>

</HTML>

EOF


CGI. Pros i contres

A favor...

– Permet fer els programes en qualsevol llenguatge

– Estàndard disponible a qualsevol plataforma

– Molt fàcil de programar

En contra...

– Rendiment pobre (crear un procés és costós)

– Qualsevol execució del CGI comença des de zero

– Inviable amb moltes peticions: no escalable

– No separem el codi de la presentació


La falta d'estat

Cada petició HTTP és independent de les altres. Problema quan volem desenvolupar aplicacions

No es proporciona cap mètode per saber des del servidor quines peticions ens arriben del mateix client

Tècniques per aconseguir tenir estat:

– Cookies

– Paràmetre ID_SESSIO

– Treballar amb usuaris autentificats Altres possibles tècniques

– Adreça IP. No sempre funciona.


Mites sobre la falta d’estat

“Jo treballo amb IIS i el servidor ja suporta

sessions, sense necessitar cookies”

“Per què hem de passar un identificador de sessió?

Encara que desactivem les cookies el PHP

ja té una variable amb la sessió.”

Aquestes frases ens mostren que no s’ha entès el significat de “sense estat”. Espero no sentir-les de vosaltres…

Si volem sessions, el navegador sempre ha d’enviar alguna dada en les seves peticions per identificar-se. El servidor no fa miracles


Perquè no podem utilitzar la IP?

Si necessitem un identificador per identificar el client… perquè no utilitzem l’adreça IP origen?

– Cas 1: tenim una màquina multiusuari amb diferents usuaris accedint a la vegada a internet. Tots ells serien tractats com la mateixa persona. Exemple: moonrey

– Cas 2: Hi ha una màquina intermitja que fa de proxy. Automàticament, totes les peticions que fem tenen com a origen la IP del proxy


Cookies

Les cookies permeten guardar al client petites quantitats d’informació i després tornar-les a enviar cap al servidor.

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, 09-Dec-2002 13:46:00 GMT

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 enviem nosaltres com qui envia un paràmetre més.


Exemple de cookies per sessions.

1.- Ens connectem a un web d'una botiga de discos i aquest ens envia una cookie ID_USUARI, en cas que no la tinguem.

2.- Mentre naveguem per les pàgines, anem enviant la cookie al servidor automàticament i el servidor ens la retorna amb la data de caducitat actualitzada.

3.- Afegim 2 discos a la cistella de la compra: el servidor associarà els discos a l'ID_USUARI que li hem enviat amb la cookie.

4.- Formalitzem o no la compra.

5.- Passades un temps, aquest identificador deixarà de ser vàlid i s'esborraran totes les dades relacionades amb la sessió al servidor.


Comentaris sobre l’exemple

Si hi ha diferents clients connectant-se al web al mateix temps, cadascun d’ells rebrà una cookie amb un numero aleatori, per així distingir-los.

Què passaria si la cookie no caduqués?

– El servidor sabria que ja hem accedit alguna vegada al seu web des del nostre navegador

– Podria saber les pàgines per on hem passat i oferir-nos informació més personalitzada.

– Convertiria una cookie creada per mantenir una sessió en una cookie utilizada per marketing.


Més sobre cookies

Una cookie es pot robar fàcilment. Si podem monitoritzar la xarxa, podem veure quin es l’identificador de sessió i utilizarlo en un altre navegador

Solució: Cookies només en connexions segures

Si una cookie només es pot enviar al servidor que l’ha originat, que podem fer si tenim l’aplicació repartida entre vàries màquines?

Solució: Cookie de domini. Aquesta cookie s’envia a totes les màquines del domini especificat.


Exemple de cookies per marketing. Primer accés

1.- Ens connectem a un web sobre economia que conté un banner d'un portal d'inversió. El banner es descarrega de ad.doubleclick.net

2.- Quan ens arriba el banner, també se'ns envia una cookie. Doubleclick es guarda quin banner ha enviat a aquesta cookie

3.- Veiem el producte que anuncia el banner i fem click a sobre. Aquest click arriba a Doubleclick, que s'apunta aquest fet a la seva base de dades i ens redirecciona a la URL que anuncia el banner


Exemple de cookies per marketing (2)

1.- Ens connectem a un altre web totalment diferent però que té un banner que també ens arribar de ad.doubleclick.net

2.- Quan fem la petició per carregar el banner, estem enviant sense saber-ho la cookie que ens han donat abans, ja que es tracta del mateix servidor.

3.- El servidor sap que en un altre moment vàrem clickar sobre un banner d'un portal d'inversió i ens envia un altre sobre un altre de similar. Estem davant d'un cas de marketing dirigit.


Què podem fer per evitar-ho

Bloquegem les cookies!

– Massa radical, perque hi ha webs que les necessiten com a indentificador de sessió i no ens permetran entrar si estan desactivades

Acceptar cookies amb certes restriccions

– Que no tinguin data de caducitat (de sessió)

– Que provinguin de servidors coneguts

– Si encara volem més, seguretat, només les que es trasmetin de forma segura


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

No es guarda cap informació: el id_sessió només serà vàlid fins que tanquem el navegador

Funciona sempre, ja que no depenem d'una funcionalitat que pot estar desactivada.


Autentificació dels usuaris

Moltes vegades els identificadors de sessió es donen una vegada hem autentificat l'usuari amb username i password.

Podem necessitar autentificació dels usuaris per:

– Autoritzacions: controlar els serveis als quals tenim accés depenent de qui som

– Personalització: mostrar només les coses que ens interessen

Altres formes d’autentificar els usuaris

– Autentificació HTTP bàsica (la de la pantalleta)

– Autentificació per certificat (més al capítol següent)


Autentificació bàsica

Part del protocol HTTP Es pot configurar a nivell de servidor web El servidor envia un codi d'error quan accedim a una zona que

requereix autentificació que fa saltar la pantalla del navegador per demanar password

Un cop hem entrat username i password, aquesta informació viatja cap al servidor juntament amb la petició de la pàgina, codificada en base64. No s'encripta el password.

La informació username/password s'envia sempre que fem peticions al servidor que ens l'ha demanat, fins que tanquem el navegador


Exemple de petició a una pàgina protegida

GET /intranet/pagina.html

401 Not Authorized

GET /intranet/pagina.html

username:password

200 OK

Contingut de la pàgina

Navegador Servidor Web


Realment el password viatja en clar?

Exemple real de capçalera que s’està enviant al demanar una pàgina segura

GET /intranet/ HTTP/1.1

...

Authorization: Basic YWRtaW46bm90ZWRlam8=

Busco per internet un descodificador de Base64 i ...

> base64.exe -d YWRtaW46bm90ZWRlam8=

> admin:notedejo


Autentificació bàsica. Pros i contres

Pros

– Està suportada pel protocol

– Es pot utilitzar amb pàgines estàtiques

– Ens proporciona "de gratis" un identificador de sessió, que no hem de passar ni es guarda com a cookie

Contres

– No tenim control sobre la pantalla d'accés

– És molt fàcil que ens agafin el password

– Una vegada hem entrar un usuari i un password, la única manera de fer “logout” és tancant el navegador o entrant amb un altre usuari



Conceptes de seguretat aplicats al web


Seguretat

De què parlarem?

– Conceptes bàsics de criptografia

– Comunicació segura amb clau pública i privada

– Autoritats de certificació

– El protocol HTTPS

– Autentificació d’usuaris per certificat

– Firewalls

– Possibles atacs a un web


Conceptes bàsics

Autenticitat

– B ha de tenir la seguretat que les dades provenen de A Confidencialitat

– Ningú ha de poder veure les dades que A envia a B Integritat

– Ningú ha de poder interceptar el missatge i canviar-lo

A B


Conceptes bàsics

La ciència que intenta aconseguir els 3 objectius anteriors és la criptografia.

La criptografia basa la seva eficiència en mètodes matemàtics de difícil resolució.

Les eines bàsiques de la criptografia són 2:

– Funcions de Hash: codifiquen un missatge de forma que no es pot tornar a l'original perquè s'ha perdut informació

– Algorismes d'encriptació: codifiquen un missatge de forma que sí podem tornar a l'original, a través d'algun tipus de clau.


Funcions de hash

Generen un resum d’una llargada fixa a partir d’un missatge original. És per tant una funció irreversible

Un petit canvi al missatge original ens dóna un hash completament diferent

És quasi impossible trobar dos missatges diferents que generin el mateix hash

Algorismes

– MD5, SHA

Exemple: un sistema pot emmagatzemar el hash dels password i fer les comparacions sempre amb els hash.


Algorismes de clau simètrica

Funcionen amb una clau La clau per encriptar i desencriptar és la mateixa i l’han de conèixer

emissor i receptor El nivell de seguretat de l'algorisme depèn de la llargada d'aquesta clau Algorismes:

– DES, IDEA, 3DES, RC4...


Algorismes de clau pública

Tenim una clau pública i una privada personal i intransferible. Clau privada: Ens permet xifrar missatges que només es poden

desxifrar amb la clau pública Clau pública: Ens permet xifrar missatges que només es poden

desxifrar amb la clau privada Algorismes:

– RSA


Clau privada vs. Clau pública

Per poder comunicar-nos amb encriptació de clau pública, la clau l'han de conèixer emissor i receptor

– Com passem la clau de forma segura?

– Necessitem tantes claus com persones amb les quals ens volem comunicar.

Els algorismes de clau pública són computacionalment molt costosos

– Què fem quan hem de transmetre molta informació?

La solució és una combinació dels 3 mètodes que hem vist fins ara.


Comunicació segura

Pas 1: Fem un hash de l'original per assegurar l'integritat

Pas 2: Signem aquest hash amb la nostra clau privada per assegurar l'autenticitat. Això es una signatura digital.


Comunicació segura

Pas 3: Generar una clau de sessió

Pas 4: Utilitzar un algorisme de clau simètrica per encriptar missatge+signatura amb aquesta clau de sessió. Així utilitzem un algorisme no tan costós pel gruix de la informació

Pas 5: Encriptar la clau de sessió amb la clau pública del receptor. D'aquesta forma assegurem confidencialitat, ja que només el receptor podrà desencriptar la clau.

Pas 6: Enviar tot el paquet al receptor


Esquema general de la comunicació segura


Conclusions a la comunicació segura

Només el receptor pot desencriptar la clau de sessió i amb ella desencriptar el missatge

Ningú pot tocar el missatge, ja que si s'aplica la funció de hash al missatge desencriptat, s'ha d'obtenir el hash que ha enviat l'emissor

El missatge ve segur del seu emissor, ja que s'ha encriptat el hash amb la clau privada de l'emissor i l'hem desencriptat amb la pública.

Moltes vegades només es fa part d'aquest procés, ja sigui la part de signatura digital o la d'encriptació. El web és un d’aquests casos


HTTP

IP

TCP

SSL

IP

TCP

HTTPS

El protocol HTTPS

HTTPS és la versió encriptada de HTTP Es basa en afegir una nova capa (SSL - Secure Socket Layer)

sobre TCP/IP que permet connexions encriptades, utilitzant algorismes de clau pública i privada.

SSL és aplicable a altres protocols també


Comunicació segura en web

Què ens interessa quan ens connectem a un web segur?

– Comunicació encriptada

– Assegurar-nos que ens comuniquem amb el web real

– NO és necessari que nosaltres tinguem una clau

L’establiment de la connexió: Handshaking

– Es negocia un protocol d’escriptació amb clau simètrica

– El servidor ens passa la seva clau pública

– Es passa encriptada una clau de sessió

– Encriptem les comunicacions amb aquesta clau


L'autenticitat de les claus

Qualsevol persona pot generar una clau pública i una privada i passar la seva clau pública dient que és la d'una altra persona

Pringadillo.com

Clau pública (real) de Amazon

Clau pública (falsa) de Amazon

Com sabem quina és la bona?


Les autoritats de certificació

Solució: les autoritats de certificació (CA) Fan de notaris: expedeixen certificats en els quals associen

una clau pública i una identitat, amb una data de caducitat Quan volem enviar la nostra clau pública a algú, el que

realment enviem és un certificat. El receptor pot comprovar a la CA si el certificat és correcte i

així assegurar-se que la clau pública correspon realment a la persona que l’ha enviat.

El client només hauria d'acceptar com a bons certificats signats per autoritats de certificació en les quals confia.


Què vol dir aquesta pantalla?

El navegador no té registrada l’autoritat de certificació. Pot tractar-se d’un certificat de proves

El nom que hi ha al certificat no coincideix amb el del web, o sigui que potser no és el seu

Hauríem de desconfiar i no donar al SI sense mirar que passa


Exemple de certificat en HTTPS

Així ens ensenya Internet Explorer un certificat...


Un pas més: Autentificació per certificat

Els clients també poden tenir un certificat propi per assegurar la seva identitat

Un servidor segur, podem obligar a exigir certificat al client per accedir a certes parts.

El servidor ha de tenir el certificat de l’autoritat certificadora del client per poder validar

Esquema complet de la comunicació segura.

El certificat es guarda encriptat al disc dur del navegador i per utilitzar-lo ens demanarà un password (PIN) per desencriptar

El password no viatja per la xarxa: únicament el certificat


Les grans preguntes sobre Certificats i HTTPS

Què vol dir que no es confia en l’autoritat de certificació que ha emès el certificat?

– Per exemple, el certificat de raco.fib.upc.es està generat per esCERT (escert.upc.es), una autoritat no reconeguda per cap navegador d’entrada

– S’ha d’instalar el certificat de l’autoritat a la nostra màquina. En aquest cas, esta a http://escert.upc.es/_certs/escert_raiz.crt

Compte! Un error d’aquest tipus també pot indicar que es tracta d’un certificat “autosignat”, es a dir, de proves. Cap web “oficial” hauria de tenir un certificat d’aquest estil.



Vull fer proves amb un servidor segur a casa. Què he de fer?

– Per fer proves, podem utilitzar les utilitats OpenSSL (www.openssl.org) per generar certificats autosignats.

– Aquestes utilitats també permeten generar peticions de certificat que s’envien a una CA amb la idea que ens retornin un certificat vàlid signat

– Si utilitzem Apache, hem d’assegurar-nos de tenir el modul mod_ssl i dir-li on està el nostre certificat



Com obtinc un certificat personal?

– Si el volem per fer proves, qualsevol de les grans CA, ens ofereixen certificats per 30 o 60 dies. Aquest certificat ens pot servir per encriptar mails o signar codi.

– Podem obtenir un certificat “real” de la FNMT a

http://www.cert.fnmt.es/clase2/main.htm

Per obtenir aquest certificat, serà obligatori anar “físicament” a una oficina de l’Agència Tributària.



Què són els Applets / ActiveX signats?

– Podem utilitzar un certificat per fer la signatura d’una aplicació, per assegurar que no està manipulada i qui la proporciona


HTTPS és suficient?

HTTPS es basa en els algorismes de clau pública i privada. És a dir, que hem de guardar molt bé la clau privada.

Si una persona entra al sistema on es guarda la clau privada, i l'aconsegueix, pot fer-se passar per aquest sistema

Si volem tenir un grau de seguretat pràcticament total, hem de tenir una política de seguretat per evitar accessos no controlats a la nostra xarxa. Una eina important és el firewall

Hem d’estar segurs de tenir les últimes versions dels servidors i del sistema operatiu per assegurar-nos que no puguin accedir al nostre sistema a partir d’una vulnerabilitat coneguda

– Aprofitada per hackers

– Aprofitada per cucs o virus


Com ens poden atacar?

CGI o altres continguts dinàmics mal escrits, que no validen prou les entrades.

– Exemple: Paràmetres amb ../ Servidors mal configurats que permeten accés a llocs o codi

que no haurien de poder veure.

– Exemple: Índex de directoris Cross-side Javascript, que aprofiten la capacitat de que algú

introdueixi codi HTML a les nostres pàgines SQL Injection: possibilitat d’introduir paràmetres que

modifiquin una sentència SQL que executem. “Robar” sessions d’altres usuaris. DOS: peticions massives fins col·lapsar el servidor


En resum

Utilizar SSL és una condició mínima quan volem un web segur.

La màxima seguretat la obtenim amb la utilització d’un certificat per part del client.

Hem de protegir la nostra màquina tant com sigui possible per tal que ningú hi pugui accedir excepte als serveis imprescindibles

Hem de tenir sempre últimes versions de tots els servidors que puguem fer servir

Hem de programar les aplicacions pensant en la seguretat: no confiar mai en que el que ens entra l’usuari és vàlid o inofensiu



Arquitectures per aplicacions web


Arquitectures per aplicacions web

De què parlarem?

– La resposta Open Source:

Apache + PHP + MySQL

– L'alternativa Microsoft:

Internet Information Server / ASP

– Java al servidor:

Tomcat + Servlets / JSP

– El que més es porta últimament

XML / XSL


Per què no n’hi ha prou amb els CGI?

El model del CGI aviat es va quedar petit:

– Poca escalabilitat

– Incomoditat per generar les pàgines Com a evolució a la idea dels CGI van sortir altres formes

d'executar codi al servidor més orientades a la generació de pàgines

Característiques comunes:

– Externament funcionen igual que un CGI

– Eliminen la necessitat de crear un nou procés

– Ens proporcionen API per simplificar el treball amb sessions, paràmetres, generació de HTML...


N’hi ha prou amb un servidor web?

Normalment el fet de generar pàgines dinàmiques, implica presentar informació que tenim al servidor de diferents formes, i això ens porta a treballar amb bases de dades

Totes les plataformes que comentem tenen una interfície simplificada per treballar amb BD

– JDBC

– ODBC

– accés directe a MySQL


Apache

Servidor web gratuït, Open Source i multiplataforma 60% dels servidors web utilitzen Apache Estructura modular, que ens permet tenir mòduls per

pràcticament qualsevol cosa

– HTTPS

– Autentificació LDAP, bases de dades…

– Llenguatge PHP, Perl

– Connexió amb contenidors de Servlets (Tomcat/Jserv)

– … Degut a la seva popularitat, fins i tot integració amb servidors

d’aplicacions comercials


Estadística dels servidors web

Resultats de NetCraft Web Survey sobre un total de 46,067,743 servidors web


PHP

PHP és un llenguatge de script que es pot incorporar a Apache a través del mòdul mod_php, de lliure distribució

Idea de tenir HTML amb codi barrejat a la mateixa pàgina, que s’executa abans d’enviar-la al navegador:

codi_html

<?php codi_php ?>

codi_html

Per fer canvis, simplement modifiquem les pàgines amb un editor. No s’han de compilar

Té una sintaxi molt semblant a PERL / C En les últimes versions, s’han introduït conceptes d’orientació

a objectes, per una millor estructuració


Característiques del llenguatge

En ser un llenguatge pensat exclusivament per web, ens facilita tasques molt usuals com per exemple:

– Suport per sessions amb cookies i sense

– Enviament de mails

– Creació d’imatges (no GIF, per problemes de copyright)

– Accés a bases de dades

– Accés a directoris LDAP

– Demanar pàgines a altres servidors

– Generació de PDF

– Tractament de XML


PHP + MySQL

Tota aplicació web seriosa necessita una base de dades per guardar informació. PHP es va dissenyar pensant en MySQL per aquestes tasques.

MySQL és una base de dades OpenSource i gratuïta Podem escollir entre velocitat o transaccions (InnoDB) Té interfície amb Java, C, però la més popular és amb PHP Disponible tant per Linux com per Windows. Limitacions: subconjunt de SQL per consultes.

PHP també pot treballar amb altres BD, com PostreSQL, Oracle, utilitzar ODBC de Windows...


Processament d’una pàgina PHP

Apache

mod_php

Petició

pagina.php

PàginaHTML

MySQL

Pàgines .php(HTML + codi PHP)

pagina .php


Exemple de PHP (1)

<HTML><BODY><TABLE><?php

// Conectem al servidor de BD amb un username i password

$link = mysql_connect( "mysql.fib.upc.es", ”aules", ”empresa");

// Seleccionem la BD

mysql_select_db(”proves");

$result = mysql_query("SELECT * FROM authors");


Exemple de PHP (2)

while ($line = mysql_fetch_array($result, MYSQL_ASSOC)) { print "<tr>\n"; foreach ($line as $col_value) { print "<td>$col_value</td>\n"; } print "</tr>\n"; }

mysql_close($link);

?></TABLE></BODY></HTML>


La nova versió: PHP 5

PHP es vol convertir en un llenguatge “seriós” orientat a objectes. (Vol convertir-se en una mena de Java)

– Classes abstractes

– Mètodes privats

– Herència

– Tractament d'excepcions

SQLite: possibilitat de tenir una base de dades sense haver de tenir un servidor a part. (Vol convertir-se en Access)

Tractament de XML basat en libxml2


PHP Nuke

Eina gratuïta per gestió de portals, que permet gestionar-los 100% des del web sense haver de tocar codi HTML

Utilitza PHP i MySQL Exemple de fins on podem arribar utilitzant només PHP Ens proporciona

– Gestor de contigut

– Fòrums

– Weblog

– Enquestes… Arquitectura oberta amb possibilitat d’afegir-hi plugins S’ha fet tan popular que li han sortit imitadors


Més al voltant de PHP

Llibries útils en PHP

– Smarty: sistema de plantilles, en que tenim un fitxer amb el codi HTML i etiquetes i un altre amb el codi PHP

– FPDF: llibreries per generar PDF 100% PHP, que no necessiten cap mòdul addicional instal·lat al servidor

– AMFPHP: comunicació de Flash al client amb un servidor web amb suport per PHP

– NuSOAP: programació de web services amb PHP. Veurem que son exactament més endavant

Eines de desenvolupament

– PHPEdit, un editor OpenSource fins i tot amb debugger


Conclusions Apache + PHP + MySQL

A favor...

– Aquesta arquitectura muntada en un sistema Linux ens permet tenir una plataforma per aplicacions web bastant potent a cost zero.

– En tractar-se de software lliure, no disposem d’un servei tècnic, però a canvi hi ha una gran quantitat de documentació al web.

– Senzill de desenvolupar En contra

– Una aplicació molt gran feta en PHP pot ser difícil de mantenir, ja que no tindrà una estructura molt clara

– Difícil separar codi de presentació


Microsoft Internet Information Server

Servidor web de la plataforma Windows NT/2000/XP Proporciona també FTP, SMTP (correu), NNTP, HTTPS Ens ve gratis amb el sistema operatiu Fàcilment configurable a través de la “management console” Suport natiu per ASP, que veurem tot seguit, però també es

pot afegir suport per altres llenguatges, com PHP, JSP… afegint les DLL corresponents

Gran integració amb el sistema:

– autentificació dels usuaris a partir dels de Windows

– accés a les connexions ODBC definides al sistema


ASP

Active Server Pages: es barreja codi HTML amb Visual Basic (o algun altre llenguatge), que s'executa en el moment d'enviar la pàgina al client.

Tecnologia veterana: va aparèixer amb la primera versió de Internet Information Server per NT

És la tecnologia més utilitzada en el món Microsoft, ja que NT no té la facilitat de UNIX per utilitzar diferents llenguatges de script.

Permet fer crides a objectes COM per separar les tasques més complexes de la presentació

Diferents eines de desenvolupament, tant de Microsoft com d’altres (Dreamweaver UltraDev, Visual Studio…)


El framework ASP

4 Objectes bàsics per les aplicacions

– Request conté informació sobre la petició que ens arriba des del navegador (paràmetres, cookies…)

– ResponseEns permet generar la resposta

– Session

Ens permet guardar variables associades a la sessió, que utilitza cookies de forma transparent

– Server

Ens permet crear nous objectes COM.


Exemple de ASP (1)

<%@ LANGUAGE = VBScript %>

<HTML>

<BODY>

<%

Dim oConn

Dim oRs

Dim Index

Set oConn = Server.CreateObject("ADODB.Connection")

oConn.Open "Provider=Microsoft.Jet.OLEDB.4.0;Data Source=" & Server.MapPath("authors.mdb")

Set oRs = oConn.Execute("SELECT * From authors")

%>


Exemple de ASP (2)

<TABLE border = 1>

<% Do while (Not oRs.eof) %>

<TR>

<% For Index=0 to (oRs.fields.count-1) %>

<TD> <% = oRs(Index)%> </TD>

<% Next %>

</TR>

<% oRs.MoveNext

Loop %>

</TABLE>

<% oRs.close

oConn.close %>

</BODY>

</HTML>


ASP.NET

Evolució de la plataforma .ASP No és 100% compatible amb el codi anterior Separa codi i presentació

– Pàgina HTML + Tags de WebForms

– Codi (en Visual Basic o altres) Permet configurar de forma declarativa

– mètode d’autentificació

– autoritzacions Concepte d’aplicació més que pàgines disperses i

configuració de les aplicacions amb fitxers XML


Més sobre ASP.NET

Permet programar una pàgina web com si fos una aplicació windows

– Dissenyem la pàgina HTML, però en lloc dels elements habituals als formularis, tenim els tags de WebForms, que s’executen al servidor i generen HTML estàndard.

– La part del codi s’estructura com a respostes als events generats pels elements de WebForms

La pròpia plataforma s’encarrega de passar els paràmetres necessaris per poder fer el tractament dels events al servidor i generar la pàgina de resposta.

No es barreja mai el codi amb l’HTML


HTML d’una pàgina ASP

<html>

<body>

<form runat="server">

<p>

<asp:Label id="Label1" runat="server">Qui ets?</asp:Label>

</p>

<p>

<asp:TextBox id="TextBox1" runat="server"></asp:TextBox>

</p>

<p>

<asp:Button id="Button1" runat="server" Text="OK”

onclick="Button1_Click">

</asp:Button>

</p>

</form>

</body>

</html>


Codi d’una pàgina ASP.NET

<%@ Page Language="VB" %>

<script runat="server">

Sub Button1_Click(sender As Object, e As EventArgs)

Label1.Text = "Hola, " & TextBox1.Text

End Sub

</script>

Voleu fer proves amb ASP.Net?

– WebMatrix. Un entorn de desenvolupament que només ocupa 1Mb (i es de Microsoft!)


Conclusions sobre ASP

ASP és un sistema madur, amb una gran base de desenvolupadors

Hi ha hagut extensions del framework de ASP a altres plataformes i llenguatges, però la plataforma completa segueix estant lligada a Windows.

Sistema més senzill de fer aplicacions web a plataforma Windows, sense necessitar més infrastructura que la que ja porta de sèrie.

L’evolució de ASP cap ASP.NET marca el futur d’aquesta plataforma.


Servlets

Framework per generar pàgines web des de classes Java Tenim accés a la petició, la resposta, la sessió i a paràmetres

d’aplicació (Similar a ASP) Anem escrivint la pàgina des del programa, generant el codi

HTML per programa (Similar a un CGI) Necessitem un contenidor de servlets, que executa una

màquina virtual Java i que pot executar-se:

– Al mateix procés que el servidor de web

– En un procés o màquina a part Accés a totes les llibreries de Java

– JDBC, mail, XML, PDF...


Exemple de Servlet (1)

import java.io.*;

import java.sql.*;

import javax.servlet.*;

import javax.servlet.http.*;

public class ServletConsulta extends HttpServlet {

public void doGet(HttpServletRequest request, HttpServletResponse response)

throws IOException, ServletException

{

response.setContentType("text/html");

PrintWriter out = response.getWriter();



out.println("<HTML>");

out.println("<BODY>");

out.println("<TABLE border=1>");

try {

Class.forName("sun.jdbc.odbc.JdbcOdbcDriver");

Connection conn=

DriverManager.getConnection("jdbc:odbc:authors");

Statement stmt=conn.createStatement();

ResultSet rset=

stmt.executeQuery("SELECT * FROM AUTHORS");

int cols=rset.getMetaData().getColumnCount();



while(rset.next()) {

out.println("<TR>");

for (int i=1;i<=cols;i++) {

out.println("<TD>"+rset.getString(i)+"</TD>");

}

out.println("</TR>");

}

out.println("</BODY>");

out.println("</HTML>");

rset.close();stmt.close();conn.close();

} catch (Exception e) {

out.println(e.toString());

}

}

}


JSP

JSP és l'equivalent a ASP en Java. Permet cridar altres classes Java, on hi haurà el gruix del codi.

Les JSP fan de vista, amb un mínim de codi. Per exemple...

<jsp:useBean id="cart" scope="session” class="session.Carts” />

</jsp:useBean>

No s’interpreta el codi cada vegada. La primera invocació fa que es compili la pàgina i es converteixi en un servlet.

Els contenidors de servlets també ens permeten executar JSP (sempre que tinguem el compilador de Java)


Servidor Web JVM

.class

URL+ param.

pàgina

Contenidors de servlets / JSP

Servidor Web

BD

.class

JVM

Servidor al mateix procés

Servidor en un procés a part

JDBC

JDBC


Exemple amb JSP (1)

<%@ page language="java" import="java.sql.*" %>

<HTML>

<BODY>

<%

Class.forName("sun.jdbc.odbc.JdbcOdbcDriver");

Connection conn=

DriverManager.getConnection("jdbc:odbc:authors");

Statement stmt=conn.createStatement();

ResultSet rset=

stmt.executeQuery("SELECT * From authors");

int cols=rset.getMetaData().getColumnCount();

%>


Exemple amb JSP (2)

<TABLE border = 1>

<% while(rset.next()) { %>

<TR>

<% for (int i=1;i<=cols;i++) { %>

<TD> <%= rset.getString(i) %> </TD>

<% } %>

</TR>

<% } %>

</TABLE>

<% rset.close();

stmt.close();

conn.close(); %>

</BODY>

</HTML>


La idea de Tag Libs

JSP permet declarar nous tags per posar a les nostres pàgines i associar-los a codi java, de forma més transparent que amb “useBean”

Podem aconseguir una molt més gran separació entre presentació i codi.

D’alguna forma ens permeten crear-nos el nostre propi llenguatge de script que barrejarem a les nostres pàgines

Per una llista de Tag Libs ja programats...

– http://jakarta.apache.org/taglibs/ Hi ha una llibreria estàndard (JSTL), però no inclosa a

l’especificació de JSP


Exemple de pàgina amb Tag Libs

<sql:driver var="dataSource"

driver="sun.jdbc.odbc.JdbcOdbcDriver” url="jdbc:odbc:authors">

<sql:query var="authors" dataSource="$dataSource">

SELECT * FROM Authors

</sql:query>

<table>

<jc:forEach var="row" items="$authors.rows">

<tr>

<td><jc:expr value="$row.Au_ID"/></td>

<td><jc:expr value="$row.Author"/></td>

<td><jc:expr value="$row.YearBorn"/></td>

<td>

</jc:forEach>

</table>


Aplicacions JSP/Servlet: Web applicacions

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ó

– Tipus mime

– Mapejos de URL a servlets

– Usuaris, grups i autoritzacions Empaquetarem tot aixo en un fitxer .WAR (Web Application

Archive)


Arquitectura MVC aplicada a Java

MVC es una forma de separar el codi de la presentació que es basa en tenir 3 components

– El model, que representa l’aplicació en sí

– Les vistes, que presenten aquestes dades

– El controlador, que s’encarrega d’instanciar les classes del model i presentar les vistes correctes

Tot i ser una estructura pensada per aplicacions amb interfícies gràfiques, és perfectament extensible a aplicacions web

ModelJavaBeans

VistaJSP

ControladorSerlvet


Del model “senzill” al model MVC


Forçant MVC: Struts

Struts és un framework que ens permeten 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 (les Action Classes)

– Totes les peticions van a aquest servlet

– Les Action classes 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 fer vistes multiidioma i també validar les entrades, a l’estil dels WebForms de ASP.NET


Més frameworks, llibreries i utilitats

Velocity. Sistema de plantilles en Java uPortal. Framework per construir portals. De per si ja

constitueix un sistema complet amb gestió d’usuaris i agregació de continguts.

Hibernate. Un dels molts motors de persistència existents, que ens permet guardar els nostres objectes en una base de dades relacional

iText. Generació de documents en PDF

Eclipse. IDE per Java molt complet, amb possibilitat de plugins per diverses tecnologies.


Tomcat

Contenidor de servlets, però també pot funcionar com a servidor web en entorns de desenvolupament

Projecte de la mateixa gent de Apache. També és gratis

Implementació de referència: és el primer en suportar les noves especificacions de Servlets i JSP

Pot funcionar conjuntament amb IIS, Apache o altres servidors web, com a un procés a part i fins i tot en una màquina diferent


Alternatives a Tomcat

JRUN

– Abans només servidor de servlets i ara servidor J2EE complet, ara distribuït per Macromedia

Resin

– Competència directa de Tomcat, segons sembla amb millor rendiment

Jetty

– Mini servidor de servlets pensat per incrustar-lo en altres aplicacions

Qualsevol servidor que suporti la plataforma J2EE, si estem disposats a assumir els recursos que necessiten


Conclusions sobre Servlets/JSP

JSP és una còpia descarada de ASP, però que no es restringeix a plataforma windows

S’ha convertit en un estàndard amb molta acceptació JSP i servlets són 100% equivalents. Es tracta de la mateixa

tecnologia amb diferents formes d’utilització Idea de taglibs per estendre el comportament molt bona Suport per fer aplicacions estructurades

– Frameworks per MVC, plantilles, portals

– Empaquetat d’aplicacions independents Llibreries de qualsevol cosa: busqueu abans de desenvolupar! Dintre de la plataforma J2EE, que veurem més endavant


XML / XSL

Aquesta arquitectura el que pretén és generar pàgines que es puguin veure en qualsevol tipus de navegador

La idea bàsica és separar les dades de la presentació.

– XML: guarda les dades a presentar

– XSL: guarda la forma de presentar-les, que serà diferent en funció del dispositiu de sortida.

Existeixen llibreries per tractar XML/XSL en PHP, Java, ASP i altres llenguatges i plataformes. No es tracta de cap substitut de les tecnologies anteriors.


Què és exactament XML?

És una forma de representar informació estructurada en un fitxer de text, amb etiquetes similars a les de HTML

XML no és cap substitut de HTML. Només representa informació

Disposem de parsers que analitzen aquest fitxer i ens permeten accedir a la informació de forma senzilla

Per què es pot utilitzar?

– Com a format per guardar informació estructurada

– Format d’intercanvi entre dos sistemes diferents

– Format intermig quan encara no sabem per quin dispositiu hem de formatejar les dades


Exemple de document XML

<?xml version="1.0" encoding="ISO8859-1" ?><CATALOG> <CD> <TITLE>BSO Amelie</TITLE> <ARTIST>Yann Tiersen</ARTIST> <PRICE>16.00</PRICE> <YEAR>2001</YEAR> </CD></CATALOG>

Tots els tags que s’obren es tanquen sense superposar-se És “case sensitive” Els tags van entre “<“ i “>” i els atributs entre cometes Tot el document ha d’estar dintre d’un tag


Grans preguntes de XML

Quines etiquetes estan permeses a XML? Les mateixes de HTML?

– NO. XML és només el format en el que s’han d’escriure les etiquetes, però les etiquetes poden ser qualsevols. De fet, XML és més un meta-llenguatge que un llenguatge

En el futur XML substituirà HTML?

– NO. XML no té forma de dir l’aspecte o forma de presentació, que es el que esperem d’una pàgina HTML. Només són dades

XML és el format perfecte per guardar les dades?

– NO. Normalment, el millor sistema segueixen sent les bases de dades


XML: un món de sigles

DTD: És l’estructura que ha de seguir un fitxer XML per ser correcte. Indica quines etiquetes són possibles, quins atributs pot tenir cada etiqueta, quina estructura han de tenir aquestes etiquetes… Són com regles gramaticals.

– Un document vàlid, compleix un DTD

– Un document ben format, simplement segueix les normes de XML

XSL / XSLT: Fulls d’estil i transformacions per XML. L’aplicació de XSLT sobre un document XML ens permet donar-li un aspecte, i convertir-lo per exemple, en una pàgina HTML o un document WML per mostrar-lo a través de mòbil.


Més conceptes relacionats

XHTML. HTML amb sintaxi de XML. No és cap nou llenguatge, és simplement que per considerar HTML com un subconjunt de XML, hem de ser molt més estrictes amb la sintaxi.

XPath. És la forma que tenim de referir-nos a parts del documents XML: branques completes, elements concrets… És imprescindible quan hem de fer tractaments de l’arbre, per especificar a quina part ens referim

namespace. Com que a XML ens podem inventar les etiquetes, és una forma d’indicar que certes etiquetes estan relacionades.


Exemple de XSLT / Xpath / namespaces

<?xml version='1.0'?><xsl:stylesheet xmlns:xsl="http://www.w3.org/TR/WD-xsl"><xsl:template match="/"> <html> <body> <table border="2" bgcolor="yellow"> <tr><th>Title</th><th>Artist</th></tr> <xsl:for-each select="CATALOG/CD"> <tr> <td><xsl:value-of select="TITLE"/></td> <td><xsl:value-of select="ARTIST"/></td> </tr> </xsl:for-each> </table> </body> </html></xsl:template></xsl:stylesheet>


SAX / DOM

Els documents XML es poden processar de dos formes:

– Llegint el fitxer i creant un arbre en memòria (DOM)

– Generant uns events cada vegada que el parser troba un determinat element al document (SAX)

Treballar amb DOM ens permet manipular de forma molt senzilla el document, accedir a la part que vulguem i transformar-lo

Treballar amb SAX és molt més eficient i per exemple és el sistema ideal si tenim un servidor que ha de transformar molts documents.


Com funciona una aplicació XML/XSL?

S’obté el document XML

– fitxer XML

– informació d’una BD obtinguda com a document XML

– ... S’obté el full d’estil XSL (normalment un fitxer)

– A partir de la informació continguda al XML

– Segons el tipus de client S’apliquen les transformacions corresponents i s’obté la

pàgina resultat, sigui aquesta WML, XHTML o una altra variant de XML.

També podem transformar el fitxer XML en el que volguem per programa, sense fulls d’estil.


Què necessitem per treballar amb XML?

Java / C++

– Xerces / Xalan (http://xml.apache.org) ASP

– Microsoft XML Parser que ve amb Explorer a partir de la versió 5.0

PHP

– Actualment, s’ha de compilar PHP amb el parser expat (http://www.jclark.com/xml)

També tenim suport per PERL, Phyton, PL/SQL...


Conclusions sobre XML

El fenomen XML sembla de vegades més una qüestió de marketing que de necessitats reals.

No hem d’oblidar que en el fons no és més que un format que ens permet una manipulació i transformació fàcil

Hem d’utilitzar XML per web?

– Tenim dades que no podem obtenir com XML?

– Podem generar XML fàcilment?

– HTML no és XML. Si el que volem transformar són pàgines web que ja tenim amb tècniques pròpies de XML, tindrem problemes

És una bona solució per intercanvi de dades


Altres arquitectures alternatives

ColdFusion

– Va ser un dels productes pioners

– Servidor propi i un llenguatge propi: CFML

– Potent, però totalment integrat amb la presentació Apache mod_perl / mod_python

– Moduls d’apache que ens permeten integrar els llenguatges PERL i Python al servidor, a l’estil del Visual Basic a IIS

– Pas intermig entre els CGI i PHP, ideal pels que ja dominaven algun d’aquests llenguatges

...


Conclusions

Solucionen el problema de rendiment dels CGI i ens proporcionen unes API o ens faciliten el procés de creació de les pàgines

Hi ha solucions més estàndard i altres més basades en plataformes concretes. Hem de triar amb compte.

Són una bona solució per la gran majoria de les aplicacions web a les que ens puguem enfrontar. No hem d’oblidar-ho.

Encara són un model excessivament limitat per plantejar-nos grans aplicacions que poden ser crítiques.



Arquitectures complexes


Un canvi de filosofia

Fins ara ens hem plantejat el desenvolupament de contingut dinàmic des del punt de vista web

Quan ens estem plantejant una aplicació més gran, per exemple, un sistema de banca on-line, hem de pensar d’una altra forma

Pàgines webPàgines

dinàmiques

AplicacióAplicació ambinterfície web


Arquitectura de 2 capes

Les aplicacions tradicionals client servidor són de 2 capes: per una banda, el client amb el codi de l’aplicació i el servidor amb les dades

El codi s’executa al client Qualsevol canvi s’ha de distribuir i instal·lar a tots els clients

BDPrograma

client


Arquitectura de 3 capes

Dividim l’aplicació en 2 parts.

– Lògica de l’aplicació

– Client Idea de thin client. Els usuaris tenen un client universal o

molt reduït: el gruix de l’aplicació està a la capa intermitja Molt més fàcil d’actualitzar versions. Menys cost de gestió Les aplicacions web són sempre de 3 capes.

Servidor Web BD


Model general d’aplicacions de 3 capes

BD

Lògicade negoci

Clients no web

Presentació

Altressistemes


Més sobre les arquitectures de 3 capes

Una aplicació complexa pot necessitar clients web i clients no web, com per exemple clients Windows, Java, WAP…

Volem també que els components de l’aplicació es puguin distribuir de forma flexible, que puguin estar en diferents màquines per si una falla o per distribuir la càrrega.

Un servidor web es queda curt per executar aquest tipus d’aplicacions. Necessitem un servidor d’aplicacions

Igual que tenim estàndards per aplicacions web (ASP, JSP, CGI) també tenim estàndards per l’arquitectura completa.

– Arquitectura Java: J2EE

– Arquitectura Microsoft: .NET


Arquitectura J2EE

Arquitectura completa d’aplicacions de n-capes basat en la plataforma Java

Idea principal: aplicacions a la capa intermitja, accessibles a través de thin clients (normalment, navegadors web)

– Components per la lògica de negoci

– Capa de presentació

J2EE és un Model de programació

– Com hem de desenvolupar les aplicacions? J2EE és una Plataforma:

– Què necessitem per executar-les?


Elements del Model d’Aplicació

Model de components

– EJB (Enterprise Java Beans) Capa de presentació

– Servlets /JSP Protocol per comunicar components remots

– RMI / IIOP Accés a bases de dades o altres fonts d’informació

– JDBC (Bases de dades relacionals)

– JNDI (Serveis de directori)

– JavaMail (Correu electrònic)

– JTA (Transaccions)


Esquema de l’arquitectura


Què és un EJB?

Són components de l’aplicació que s’executen a la capa intermitja i que executen la lògica de negoci

Han d’executar-se en un servidor de EJB, que els hi proporcionarà serveis transaccionals, d’accés a dades, de missatges…

Des del client ens relacionem amb el servidor EJB, no directament amb les classes que conté.

Un contenidor de EJB es comporta de manera similar a una base de dades: contactem amb ell per accedir als components que conté, deixant a les seves mans la forma en que els administra.


3 classes de EJB

Session beansSón operacions que invoca el client, no tenen estat.

Entity beansRepresenten informació. Un canvi al seu estat es reflexa a base de dades

– BMP (Bean Managed Persistence): Nosaltres mateixos fem l’accés a la Base de Dades.

– CMP (Content Managed Persistence): Deixem que el contenidor s’encarregui de la persistència

Message-driven beansEns serveixen per comunicació assíncrona


Característiques del Model d’Aplicació

J2EE intenta que gran part del que fins ara s’havia de programar explícitament s’especifiqui de forma declarativa en fitxers descriptors XML i ho controli el servidor

– Seguretat: quins usuaris poden accedir a cada EJB i que poden executar

– Transaccions: quins components poden utilitzar transaccions i com les implementen

– Persistència: si un component ha de ser persistent, com es mapeja en una base de dades

Aquestes característiques es podran variar en el moment d'instal·lar l’aplicació al servidor d’aplicacions


EJB i Usuaris

Com sabem quin usuari ens executa els EJB? Què significa exactament que un EJB suporti transaccions?

Quan executem un EJB li passem un context d’execució en el que consta l’usuari que l’esta executant

Ens hem d’imaginar el servidor EJB com una base de dades. Sabem qui es connecta i quan fa vàries modificacions, podem agrupar-les en transaccions

Normalment, l’usuari ens arribarà via web. La capa de presentació el passarà via context a les EJB


Exemple. Botiga de llibres


Pros i contres de J2EE

En contra...

– Arquitectura complicada

– No gaire rendiment, especialment si confiem en la persistència basada en el contenidor

– Moltes restriccions A favor

– Estàndard. Una aplicació feta utilitzant J2EE segueix una sèrie de normatives que fan que sigui “fàcil” de modificar per un altre desenvolupador

– Molts servidors on es poden instalar aquestes aplicacions “sense” (amb moltes cometes) modificacions


Arquitectura Windows .NET

Arquitectura de n-capes de Microsoft

Es basa en:

– Un model de components: .NET Components

– Un nou llenguatge: C# (però no exclusivament)

– Un protocol per invocació de serveis: SOAP

– Tecnologia per generar pàgines: ASP.NET

Anteriorment, Microsoft havia intentat crear una arquitectura anomenada DNA, basada en DCOM com a protocol, però aquest sembla un intent més seriós


Components .NET

El model d’objectes de la plataforma .NET es basa CLR, una llibreria comuna de tipus per tots els llenguatges suportats per la plataforma.

Els objectes es generen en un codi intermig anomenat MSIL, similar al bytecode de Java.

La CLR (common language) executa els programes que estan en MSIL passant-los a llenguatge natiu abans d’executar-los (no exactament el mateix que un JIT)

Els components .NET són els substituts dels .COM, tot i que hi ha wrappers que ens permeten enllaçar ambdues tecnologies

Porten incorporat un sistema de versió, per evitar problemes de DLL


Components .NET i C#

C# és una evolució de C++ molt similar a l’evolució de C++ que representa Java.

És el primer llenguatge pensat específicament per la plataforma .NET.

El resultat de compilar un programa fet en C# és codi MSIL, exactament igual que la resta de llenguatges .NET

Gràcies a que tots els programes s’executen a traves de CLR, hi pot haver un alt grau d’integració entre llenguatges

– Java: un sol llenguatge, múltiples plataformes

– .NET: una sola plataforma, molts llenguatges


.NET multiplataforma?

Per què un llenguatge intermig si només donem suport a plataforma windows?

– Aconseguim un entorn d’execució controlada

– Obtenim una gran interacció entre diferents llenguatges, per exemple, herència entre VBasic i C#

Podem fer que .NET sigui multiplataforma?

– http://www.go-mono.com. Algú s’anima?

– Projecte liderat per Miguel de Icaza, creador del gnome


SOAP

SOAP és un protocol per invocació remota d’objectes basada en XML

La idea principal és que és independent del transport, tot i que ara mateix s’utilitza sobre HTTP

– Petició normal HTTP passant com a paràmetre a una estructura XML amb la invocació

– Retorna un document XML amb el resultat

– No necessita cap servidor especial

– Pot travessar firewalls Ha tingut acceptació, fins i tot fora de la plataforma .NET, ja

que és independent de la plataforma.


Web Services. La paraula de moda

Què són el Web Services?

– Són components remots pensats per ser invocats via SOAP.

A la plataforma .NET, qualsevol component pot convertir-se fàcilment en un Web Service, utilitzant ASP.NET

– Es crea un fitxer .asmx servit per IIS

J2EE no està preparat d’entrada. S’hi ha afegit APIs per fer crides SOAP a través de JAX-RPC


Web Services i la infrastructura necessària

Només amb el que hem dit fins ara, la idea de Web Services queda una mica coixa. Ens faltaria...

– WSDL Ens permet descriure els mètodes que té el servei.

– UDDI directoris en els que podem registrar els serveis.

– ebXMLdefineix formats de documents que s’haurien de fer servir en les transaccions electròniques


Conclusions

Llenguatge

Intèrpret

Pàgines dinàmiques

Components

Web services

Accés a BD

J2EE

Java

JRE

JSP

EJB

SOAP

JDBC

.NET

C#, VB...

CLR

ASP.NET

.NET Components

ADO

Web services


Conclusions

Tant J2EE com .NET ofereixen una gran complexitat. És important primer de tot plantejar-se si val la pena o si podem quedar-nos només amb una part (JSP/ASP.NET únicament)

Si les comparem detingudament, totes dues propostes són en el fons bastant semblants.

Les arquitectures de 3 capes completes ens ofereixen un escenari molt més complex que les pàgines dinàmiques

És molt important tenir una arquitectura estàndard per no haver de llençar l’aplicació desenvolupada si canviem de plataforma i per interactuar amb d’altres.



Servidors d’aplicacions


Servidors d’aplicacions

De què parlarem?

– Servidors d’aplicacions i servidors web

– Característiques que haurien de tenir

– Arquitectures per alta disponibilitat

– Alguns productes disponibles al mercat i les seves característiques


Què és un servidor d'aplicacions?

Definició àmplia:

Un servidor d'aplicacions és el servidor que hi ha a la capa intermitja, és a dir, entre el client i les fonts de dades

Definció restrictiva:

És aquell servidor que dóna suport als "thin clients", controlant les sessions dels usuaris, executant la lògica de negoci i connectant amb el recursos back-end, ja siguin dades, transaccions o contingut, donant a més suport per alta disponibilitat.


Servidor web vs. Servidor d'aplicacions

La diferència bàsica entre un servidor web i un d'aplicacions és que el servidor d'aplicacions no només ha de donar suport a clients web

Els servidors web com a tals poden executar CGI i algun llenguatge de script, però no suportar una arquitectura gaire més complexa.

Als servidors d’aplicacions, una de les capes és sempre el servidor web.

Servidor d’aplicacions

Servidor web


Quins components hi podem trobar?

Autorització/seguretat

Clients no web

ServidorWeb

Conectorsaltres sistemes

Conectorsamb BDCachés

Portals

BD

Altres sistemes

Gestors contingut

Balacejadors/alta disponibilitat

...

Administració


La carta als reis dels servidors d’aplicacions

Serveis de seguretat

– Declaració descriptiva (no per programa)

– Utilització de certificats de client

Control de les sessions i l'estat

– Transparència en cookies i altres sistemes

– Persistència dels objectes

Balanceig de càrrega i tolerància a fallades

– Funcionament en cluster

– Escalabilitat posant més servidors



Suport per diferents clients

– Presentació adaptada a HTML, mòbils, PDA…

– Possibilitat de connexió directa als objectes de la capa de domini amb aplicacions remotes

Accés a diferents tipus de dades

– Conectivitat amb els sistemes de la organització

Transaccions

– Possibilitat de controlar transaccions que utilitzen diferents sistemes



Adherència a estàndards

– J2EE

– XML, LDAP, CORBA, SOAP...

Aplicacions i mòduls ja construïts sobre el propi servidor

– Portals

– Gestors de contingut

– Aplicacions de comerç electrònic

– Connectors amb altres sistemes

– ...



Facilitat per desenvolupar

– Mòduls per poder treballar amb Entorns de desenvolupaments (IDE)

Facilitat per administrar

– Administració remota via web

– Monitorització de l’execució de l’aplicació en temps real

– Possibilitat de deixar logs de l’execució

– Hot deploy: posada en marxa de noves aplicacions o versions sense haver de parar el sistema.


Arquitectures per alta disponibilitat

– Balancejadors web hardware

– Màquines que fan de servidors web

– Màquines que fan de servidor d’aplicacions, en cluster

Balancejadorweb

Balancejadorweb

Servidoraplicacions

Balancejadorweb

Servidoraplicacions

...


Factors a tenir en compte

Balanceig web

– Sticky sessions: una vegada començada una sessió, no la pot servir una altra màquina.

– Si un dels servidors web cau, com ho detecta el balancejador?

– Com repartim la carrega?

Cluster de servidors d’aplicacions

– Cada servidor web només es comunica amb el seu servidor d’aplicacions?

– S’ha de replicar la informació de les sessions perquè qualsevol servidor d’aplicacions pugui continuar una sessió si cau el que la gestionava originalment?


Conclusions sobre alta disponibilitat

El fet de posar un servidor d’aplicacions no garantitza alta disponibilitat, hi ha una feina de configuració important

Quan més senzilla sigui una aplicació, més fàcil serà fer-la tolerant a fallades:

– Si no tenim sessions, no cal replicar res Hem d’anar en compte de no crear punts de fallada:

– Què passa si cau el balancejador hard?

– Què passa si cau la base de dades?

– Podem detectar el fet que un servei “es quedi tonto”?

– Pot ser que el servidor aguanti però que se’ns col·lapsi l’ample de banda?


Oracle 9i Application Server

Una mica d’història

– Oracle Web Server (versió 2.0)

– Oracle Web Application Server (versió 3.0)

– Internet Application Server Primeres versions

– Arquitectura basada en “cartridges” per diferents tipus d’aplicacions

– El més important era el de PL/SQL, que executava aplicacions que estaven… a la base de dades!

– Cartridge Java, però no per Servlets


Oracle 9i Application Server

Actualment

– Primera capa basada en Apache / mod_jserv / mod_plsql

– Segona capa, amb el servidor d’aplicacions pròpiament

Integració en un de tots els servidors de Oracle

– Servidor de forms (aplicacions clàssiques Oracle)

– Oracle Portal (abans WebDB)

– Application Server (PL/SQL, Java, JSP, EJB...)

Gran importància del caché, tant de pàgines com de la base de dades, per evitar peticions innecessàries. Implementa ESI


ESI (Edge Side Include) a Oracle 9i

Les pàgines de portals, aglutinen informació de diferents llocs, però gran part de la pàgina és fixa. Si la guardem en un caché, la pàgina no estarà actualitzada.

Amb ESI, el que fem és separar les nostres pàgines en fragments, indicant

– origen de la informació

– tipus d’informació (fixa,variable)

– quant de temps es pot mantenir en caché La idea sota és que les pàgines es “munten” en un lloc proper

al client i només es demanen al servidor quan es estrictament necessari


JBoss

Servidor Open Source (es guanyen la vida fent classes i consultories)

Servidor J2EE complet, com la majoria dels que veurem Microkernel amb mòduls,

basats en tecnologia JMX (Java Management Extension)

Novetat: suport per AOP(Aspect Oriented Programming)

– Permet afegir funcionalitats comuns a una sèrie de classes, per exemple persistència, logging...


Lotus Notes

No és un servidor d’aplicacions, sinó una plataforma de treball en grup i base de dades de documents

El servidor (domino) ha passat de ser servidor de Lotus Notes a poder fer també de

– servidor web (amb les bases de dades de documents)

– servidor LDAP (amb els usuaris del sistema) Es poden programar aplicacions en un llenguatge propi

(LotusScript), en Java o simplement permetre accés a les bases de dades

Sistema ideal per publicar documents de forma que impliqui a tota la organització


Vignette Story Server

Eina per crear grans portals CMS: Content Management System

– Edició via web

– Entorn de desenvolupament i producció

– Workflows de la informació CDS: Content Delivery System

– “Ensambla” les pàgines

– Personalització Treballa conjuntament amb el servidor d’aplicacions Sistema basat en plantilles i, inicialment TCL com a

llenguatge Actualment, plataforma V7


Més servidors

Weblogic

– Weblogic és un dels servidors més veterans

– Té suport per pràcticament tot i suporta les últimes versions dels estàndards

Sun ONE Application Server

– Integració amb la resta de productes de la plataforma Sun ONE: servidor web, servidor de directori, entorn de desenvolupament (Sun ONE Studio)...

– Té una versió que es distribueix gratuïtament.


BEA Weblogic


Més servidors

WebSphere

– Solució completa, fins i tot amb base de dades (DB2)

– Excessivament complex

– Difícil de posar en marxa

Zope

– Servidor d’aplicacions basat en Python

– Open Source i gratuït

– Fa de gestor de contingut i permet desenvolupar noves aplicacions en Python


Conclusions

És realment difícil definir el que fa exactament un servidor d'aplicacions, sobretot ara que cada vegada intenten fer més coses

És difícil avaluar-los. Totes les grans marques tenen algun joc de proves que l’afavoreix enormement i no ens en podem refiar

No ens hem de deixar enganyar pel nom i hem de veure realment quines característiques té un producte

Un servidor d'aplicacions necessita una gran quantitat de recursos. Potser un servidor web amb una sèrie d’extensions ens servirà si només hem de servir les nostres aplicacions a clients HTML.



El web de la FIB


Primera etapa

Servidor CERN Desenvolupament de la consulta d'expedients, totalment feta

a partir de pàgines estàtiques Primer sistema d'autentificació d'usuaris, totalment estàtic

Navegador Web de la FIB

Cern


Segona etapa.

Desenvolupament de l'aplicació de modificació de la guia docent basada en CGI i fitxers de dades. Primer racó del professor

Canvi del servidor a Netscape Enterprise Server Aplicació d'avisos i notes, també basada en CGI i fitxers de

dades


NESFitxer de dades


Tercera etapa

Introducció de Oracle i Oracle Application Server, lligats amb el servidor de Netscape. Es van migrant les aplicacions disponibles a PL/SQL

L'autentificació d'usuaris es fa per base de dades: finalment els usuaris es poden canviar el password


NES OASBD

Oracle


Quarta etapa

Introducció de la tecnologia servlets a l'aplicació de votacions electròniques

Utilització del servidor JRUN lligat amb Netscape Enterprise Server, que a la versió 3.0 tenia un suport molt pobre de servlets


NES

NES JRUN

OAS

BDOracle


Cinquena etapa

Utilització d'un servidor LDAP per guardar els passwords d'usuari, de cara a implementar un sistema de password únic amb la resta de sistemes

Utilització del LDAP de la UPC pels passwords dels professors

Canvi als servidors Apache (web) i Jserv (servlets), que ens donen la flexibilitat necessària per treballar amb 2 servidors LDAP

Eliminació de Oracle Application Server i substitució per un mòdul de Apache que permet executar PL/SQL

Servidor segur pels racons: els password sempre viatgen encriptats


Cinquena etapa. Esquema


Apache

Apache JServ

BDOracle

https

iPlanetLDAP

LotusNotes


LDAP i integració amb la resta de sistemes

Gràcies al fet d'autentificar els usuaris amb LDAP, s'ha pogut crear un sistema de password únic

Aquest password afecta a mail, autentificació a diferents màquines i ens ha permet també posar en marxa el webmail des del racó sense tornar a demanar password

Consulta del webmail

Apache

https

iPlanetLDAP

webmail.fib.upc.es

IMAP

alabi/alaba

ada

fusio/fissio


Sisena etapa

Una màquina farà de racó i l'altre de web, però seran totalment intercanviables, ja que comparteixen disc

Actualització de JServ a Tomcat com a servidor de servlets Balanceig de càrrega entre els servidors de servlets Eliminació del modul mod_owa per executar el codi llegat

PL/SQL substuint-lo per DBPrism, basat en servlets



Apache

Apache Tomcat

BDOracle

https

iPlanetLDAP

LotusNotes

Sisena etapa. Esquema

Tomcat


Millores previstes

A nivell d’arquitectura, aconseguir un entorn d’alta disponibilitat, de forma que qualsevol dels dos servidors pugui assumir les funcions de l’altre de forma automàtica en cas de problemes

Intentar potenciar més la part de docència no presencial, per que cada assignatura pugui tenir un espai propi dintre del racó (i aixi evitar que els professors facin pàgines externes)

Estudiar altres formes més flexibles d’integrar tota la informació actual, a l’estil de uPortal.


Conclusions

El web de la FIB s'ha anat adaptant a les noves tecnologies per satisfer les necessitats que s'han anat creant

El web i sobretot els racons s'han convertit en una eina imprescindible a la FIB

Cada cop s'han anat creant més serveis, ja sigui per iniciativa pròpia o per peticions explícites de professors o estudiants


Per consultes sobre el seminari o temes web en general

[email protected]

Per suggerències o problemes amb el web de la FIB

[email protected]

Per suggerències o problemes amb quasevol tema

dels servidors o aules informàtiques de la FIB

[email protected]

LCFIB Jordi Girona 1-3, Mòdul B6 E-08034 Barcelona, Spain [email protected] Tecnologies web Aules...

Documents

Transcript of LCFIB Jordi Girona 1-3, Mòdul B6 E-08034 Barcelona, Spain [email protected] Tecnologies web Aules...