MàJ après les cours du jeudi 18 décembre 2008
olivier
parent
2b6b6b2adf
commit
c308787454
|
|
@ -0,0 +1 @@
|
|||
MALADE
|
||||
|
|
@ -0,0 +1 @@
|
|||
MALADE
|
||||
|
|
@ -0,0 +1,73 @@
|
|||
Jeudi 18 décembre 2008
|
||||
G54
|
||||
|
||||
====== Correction jeu d'échecs ======
|
||||
|
||||
===== DUC =====
|
||||
|
||||
3 acteurs :
|
||||
* utilisateur
|
||||
* opérateur
|
||||
* expert
|
||||
|
||||
Opérateur et expert sont des utilisateurs.
|
||||
|
||||
Tout les utilisateurs peuvent :
|
||||
* rechercher une partie
|
||||
* visualiser un échiquier
|
||||
* naviguer dans une partie
|
||||
|
||||
L'opérateur peut, en plus des utilisateurs :
|
||||
* saisir une partie
|
||||
* saisir un coup
|
||||
|
||||
L'expert peut, en plus des utilisateurs :
|
||||
* commenter une partie
|
||||
|
||||
===== DCA/DPO =====
|
||||
|
||||
2 packages :
|
||||
* Partie
|
||||
* Échiquier
|
||||
|
||||
Partie - - -> Échiquier
|
||||
|
||||
==== Partie ====
|
||||
|
||||
Classes :
|
||||
* Partie
|
||||
* Coup
|
||||
* Joueur
|
||||
|
||||
==== Échiquier ====
|
||||
|
||||
Classes :
|
||||
* Pièces
|
||||
* TypePièces
|
||||
* Case
|
||||
* Échiquier
|
||||
|
||||
====== Cours ======
|
||||
|
||||
Explication des techniques pour introduire les Design Patterns :
|
||||
* Le papillon
|
||||
* Le rectangle
|
||||
|
||||
===== Design Pattern =====
|
||||
|
||||
3 types :
|
||||
* Singleton
|
||||
* Observateur
|
||||
* Fabrique
|
||||
|
||||
==== Singleton ====
|
||||
|
||||
Exemple : le pape
|
||||
|
||||
==== Observateur ====
|
||||
|
||||
Sous StarUML : observer | observable
|
||||
|
||||
Le pattern ressemble comme deux gouttes d'eau au rectangle.
|
||||
|
||||
|
||||
|
|
@ -0,0 +1,63 @@
|
|||
Jeudi 18 décembre 2008
|
||||
G54
|
||||
|
||||
====== Correction jeu d'échecs ======
|
||||
|
||||
===== DUC =====
|
||||
|
||||
3 acteurs :
|
||||
* utilisateur
|
||||
* opérateur
|
||||
* expert
|
||||
|
||||
Opérateur et expert sont des utilisateurs.
|
||||
|
||||
Tout les utilisateurs peuvent :
|
||||
* rechercher une partie
|
||||
* visualiser un échiquier
|
||||
* naviguer dans une partie
|
||||
|
||||
L'opérateur peut, en plus des utilisateurs :
|
||||
* saisir une partie
|
||||
* saisir un coup
|
||||
|
||||
L'expert peut, en plus des utilisateurs :
|
||||
* commenter une partie
|
||||
|
||||
===== DCA/DPO =====
|
||||
|
||||
2 packages :
|
||||
* Partie
|
||||
* Échiquier
|
||||
|
||||
Partie - - -> Échiquier
|
||||
|
||||
==== Partie ====
|
||||
|
||||
Classes :
|
||||
* Partie
|
||||
* Coup
|
||||
* Joueur
|
||||
|
||||
==== Échiquier ====
|
||||
|
||||
Classes :
|
||||
* Pièces
|
||||
* TypePièces
|
||||
* Case
|
||||
* Échiquier
|
||||
|
||||
====== Cours ======
|
||||
|
||||
Explication des techniques pour introduire les Design Patterns :
|
||||
* Le papillon
|
||||
* Le rectangle
|
||||
|
||||
===== Design Pattern =====
|
||||
|
||||
3 types :
|
||||
* Singleton
|
||||
* Observateur
|
||||
* Fabrique
|
||||
|
||||
|
||||
|
|
@ -0,0 +1,89 @@
|
|||
05 décembre 2008
|
||||
Séance 3
|
||||
|
||||
Cf. https://tetras.u-strasbg.fr/prive/pedagogie/LP/P51/index.php?menu=301
|
||||
|
||||
====== Cours ======
|
||||
|
||||
===== Les applets, quoi ça ? =====
|
||||
|
||||
Une applet est une application lancée sur la machine d'un client à partir d'un navigateur Web en appel à un serveur.
|
||||
|
||||
Mais il y a certaines limitations pour des raisons de sécurité.
|
||||
|
||||
===== Quelles sont les propriétés des applets ? =====
|
||||
|
||||
Donner un nom à une applet sert pour faire communiquer les applets entres elles.
|
||||
|
||||
Même avec l'archive il faut dire quelle classe exécuter, donc la propriété CODE est obligatoire.
|
||||
|
||||
===== Appels de méthodes =====
|
||||
|
||||
init : une fois au chargement de la page
|
||||
|
||||
start : plusieurs fois après le démarrage de la page
|
||||
|
||||
===== Activité principale d'une applet =====
|
||||
|
||||
Dans le cas d'une applet, en général c'est pour un but graphique, pour cela on utilise la méthode paint() qui permet de redessiner l'applet.
|
||||
|
||||
À cet effet on peut considérer la méthode paint() comme la méthode principale de notre applet.
|
||||
|
||||
===== Gestion des images =====
|
||||
|
||||
==== Récupération des images ====
|
||||
|
||||
Les images sont récupérées sur le serveur, via une URL relative donnée.
|
||||
|
||||
getCodeBase : donne le répertoire de base de notre application sur le serveur.
|
||||
|
||||
On rappelle qu'une applet ne peut charger des fichiers ou des choses QUE du serveur sur laquelle elle a été lancée.
|
||||
|
||||
==== Affichage des images ====
|
||||
|
||||
On utilise la méthode DrawImage()
|
||||
|
||||
==== MediaTracker ====
|
||||
|
||||
Chargement asynchrone des ressources (média)
|
||||
|
||||
waitForAll() : patient que toutes les images soient chargées.
|
||||
|
||||
===== Le contexte d'une applet =====
|
||||
|
||||
Permet d'accéder au navigateur ou aux autres applets de la page HTML.
|
||||
|
||||
===== Déploiement d'une applet =====
|
||||
|
||||
Pour vérifier qu'une applet fonctionne, on peut tester sans navigateur web, à l'aide d'**appletviewer**
|
||||
|
||||
Fichiers d'aide HTML : pas des fichiers auquels on veut accéder directement par notre serveur Web. Le navigateur ne peut pas accéder directement à l'archive. C'est l'applet qui accède aux fichiers contenus dans notre archive.
|
||||
|
||||
===== Conclusion =====
|
||||
|
||||
Les applets c'est quand même le PHP et l'AJAX ne suffisent pas de faire ce qu'on veut, et les clients veulent pas une application lourde, mais possèdent JRE.
|
||||
|
||||
Avantage des applets : rien n'est exécuté sur le serveur.
|
||||
|
||||
Inconvénient : demande une certaine puissance.
|
||||
|
||||
====== Démonstration ======
|
||||
|
||||
Démonstration de UNIV-R sur les serveurs de l'université.
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
|
@ -0,0 +1 @@
|
|||
MALADE
|
||||
|
|
@ -0,0 +1 @@
|
|||
MALADE
|
||||
|
|
@ -0,0 +1,135 @@
|
|||
Jeudi 18 décembre 2008
|
||||
S5B
|
||||
M.Grad
|
||||
|
||||
Sécurisation des communications
|
||||
|
||||
===== Couches OSI =====
|
||||
|
||||
On a sécurisé pas mal de choses.
|
||||
|
||||
==== Brique physique ====
|
||||
|
||||
L2TP et PPTP permettent de sécuriser la liaison physique.
|
||||
Si on sait chiffrer une liaison donnée, tout est protégé et donc pas besoin de s'occuper du reste.
|
||||
|
||||
==== Brique IP ====
|
||||
|
||||
IPSEC et GRE sur la couche IP.
|
||||
On fait du *tunneling*.
|
||||
|
||||
Tout le trafic local d'un réseau à un autre est sécurisé.
|
||||
|
||||
==== Brique Réseau ====
|
||||
|
||||
SSL / TLS et Socks V5 est appliqué à l'UDP et TCP
|
||||
Apporte les 'S' aux services FTP, HTTP, etc.
|
||||
|
||||
==== Brique Transport ====
|
||||
|
||||
S/MIME pour le courriel
|
||||
|
||||
===== Services et ports =====
|
||||
|
||||
On a du réecrire les services pour ajouter des modules de sécurité. Et donc on a du ouvrir de nouveaux ports.
|
||||
|
||||
===== SSL Historique =====
|
||||
|
||||
TLS = Transport Layer Security
|
||||
TLS = copie de SSL (IETF pas arrangé avec Netscape, d'où des incompatibilités notoires.
|
||||
|
||||
Cependant tout ce qui fait foi, c'est TLS grâce à l'IETF qui est encore active.
|
||||
|
||||
===== Sécurité SSL =====
|
||||
|
||||
* Ajouter une authentification avec les certificats auf ormat X.509
|
||||
* Faire un condensé pour obtenir l'intégrité (MAC: Message Authentification Code)
|
||||
* Apporter la confidentialité en chiffrer toutes les communications à l'aide d'une clé de session
|
||||
|
||||
===== SSL : Les protocoles =====
|
||||
|
||||
4 briques :
|
||||
* SSL Handshake (poignée de main)
|
||||
* Négociation des paramètres et algorithmes
|
||||
* Authentification du serveur (opt du client)
|
||||
* Échange des clés
|
||||
* SSL Record
|
||||
* SSL Change Cypher Spec
|
||||
* SSL Alert
|
||||
|
||||
Cf. Diapositives.
|
||||
|
||||
==== SSL Handshake ====
|
||||
|
||||
* Session SSL établie entre client et serveur
|
||||
* Session peut maintenir les informations d'était de plusieurs connexions SLL??
|
||||
|
||||
==== Modèle d'interaction ====
|
||||
|
||||
* Services en mode client/serveur peuvent êtres sécurisés par le protocole SSL
|
||||
* Modèle d'interaction de base permet authentification
|
||||
* Serveur obtient un certificat et l'installle (clé privée sécurisée sur le serveur)
|
||||
|
||||
===== SSL et services =====
|
||||
|
||||
* FTPS : 990
|
||||
* HTTPS : 443
|
||||
* SSMTP : 465
|
||||
* SNNTP : 563
|
||||
* POP3S : 995
|
||||
* IMAPS : 993
|
||||
|
||||
===== SSH =====
|
||||
|
||||
==== telnet : shell distant ====
|
||||
|
||||
Cf. Schéma diapositives
|
||||
|
||||
==== SSH (Secure Shell) ====
|
||||
|
||||
* Terminal distant sécurisé, équivalent à rlogin, rsh, telnet sécurisé
|
||||
* Modèle d'interaction standard ssl
|
||||
* Inclut le transfert de fichiers
|
||||
* Effectue une compression des données
|
||||
* Permet la redirection de ports
|
||||
* Combinaison de chiffrement symétrique ET asymétrique
|
||||
* Standardisé à l'IETF
|
||||
|
||||
==== SSH et redirection de ports ====
|
||||
|
||||
Cf. Diapositives.
|
||||
|
||||
On peut rediriger n'importe quel port de notre machine vers un serveur ayant SSH.
|
||||
Du coup on peut, en 3 sauts, à obtenir un service distant qui était indisponible à la base.
|
||||
|
||||
Exemple : accéder à canette via sterne + ssh.
|
||||
|
||||
===== Kerberos v5 =====
|
||||
|
||||
* Protocole d'authentification réseau destiné aux applications client/serveur (MIT)
|
||||
* Serveur Kerberos
|
||||
* Service Réseau en mode connecté (sur TCP)
|
||||
* Client du service Réseau
|
||||
* 3 niveaux d'authentification
|
||||
* À l'établissement de la connexion
|
||||
* À chaque ...compléter !!!!
|
||||
|
||||
Tickets Kerberos actifs sous notre pc : taper la commande **klist**.
|
||||
krbtray => sous windows (à vérifier)
|
||||
|
||||
===== Authentification des utilisateurs du département =====
|
||||
|
||||
* LDAP : Lightweight Directory Access,
|
||||
* Protocol : procotle d'accès aux annuaires X500 (RFC 3377)
|
||||
* Active Directory : annuaire des ressources partagées (Win2K Server), inclus un annuaire de type LDAP.
|
||||
* Kerberos : protocole d'authentification à base de tickets
|
||||
* SSO : Signle Sign On, mécanismes permettant de ne s'authentifier qu'une seule fois
|
||||
|
||||
===== Inscription d'un étudiant =====
|
||||
|
||||
Cf. Diapositive
|
||||
|
||||
On a actuellement 4 annuaires.
|
||||
|
||||
|
||||
|
||||
|
|
@ -0,0 +1,134 @@
|
|||
Jeudi 18 décembre 2008
|
||||
S5B
|
||||
M.Grad
|
||||
|
||||
Sécurisation des communications
|
||||
|
||||
===== Couches OSI =====
|
||||
|
||||
On a sécurisé pas mal de choses.
|
||||
|
||||
==== Brique physique ====
|
||||
|
||||
L2TP et PPTP permettent de sécuriser la liaison physique.
|
||||
Si on sait chiffrer une liaison donnée, tout est protégé et donc pas besoin de s'occuper du reste.
|
||||
|
||||
==== Brique IP ====
|
||||
|
||||
IPSEC et GRE sur la couche IP.
|
||||
On fait du *tunneling*.
|
||||
|
||||
Tout le trafic local d'un réseau à un autre est sécurisé.
|
||||
|
||||
==== Brique Réseau ====
|
||||
|
||||
SSL / TLS et Socks V5 est appliqué à l'UDP et TCP
|
||||
Apporte les 'S' aux services FTP, HTTP, etc.
|
||||
|
||||
==== Brique Transport ====
|
||||
|
||||
S/MIME pour le courriel
|
||||
|
||||
===== Services et ports =====
|
||||
|
||||
On a du réecrire les services pour ajouter des modules de sécurité. Et donc on a du ouvrir de nouveaux ports.
|
||||
|
||||
===== SSL Historique =====
|
||||
|
||||
TLS = Transport Layer Security
|
||||
TLS = copie de SSL (IETF pas arrangé avec Netscape, d'où des incompatibilités notoires.
|
||||
|
||||
Cependant tout ce qui fait foi, c'est TLS grâce à l'IETF qui est encore active.
|
||||
|
||||
===== Sécurité SSL =====
|
||||
|
||||
* Ajouter une authentification avec les certificats auf ormat X.509
|
||||
* Faire un condensé pour obtenir l'intégrité (MAC: Message Authentification Code)
|
||||
* Apporter la confidentialité en chiffrer toutes les communications à l'aide d'une clé de session
|
||||
|
||||
===== SSL : Les protocoles =====
|
||||
|
||||
4 briques :
|
||||
* SSL Handshake (poignée de main)
|
||||
* Négociation des paramètres et algorithmes
|
||||
* Authentification du serveur (opt du client)
|
||||
* Échange des clés
|
||||
* SSL Record
|
||||
* SSL Change Cypher Spec
|
||||
* SSL Alert
|
||||
|
||||
Cf. Diapositives.
|
||||
|
||||
==== SSL Handshake ====
|
||||
|
||||
* Session SSL établie entre client et serveur
|
||||
* Session peut maintenir les informations d'était de plusieurs connexions SLL??
|
||||
|
||||
==== Modèle d'interaction ====
|
||||
|
||||
* Services en mode client/serveur peuvent êtres sécurisés par le protocole SSL
|
||||
* Modèle d'interaction de base permet authentification
|
||||
* Serveur obtient un certificat et l'installle (clé privée sécurisée sur le serveur)
|
||||
|
||||
===== SSL et services =====
|
||||
|
||||
* FTPS : 990
|
||||
* HTTPS : 443
|
||||
* SSMTP : 465
|
||||
* SNNTP : 563
|
||||
* POP3S : 995
|
||||
* IMAPS : 993
|
||||
|
||||
===== SSH =====
|
||||
|
||||
==== telnet : shell distant ====
|
||||
|
||||
Cf. Schéma diapositives
|
||||
|
||||
==== SSH (Secure Shell) ====
|
||||
|
||||
* Terminal distant sécurisé, équivalent à rlogin, rsh, telnet sécurisé
|
||||
* Modèle d'interaction standard ssl
|
||||
* Inclut le transfert de fichiers
|
||||
* Effectue une compression des données
|
||||
* Permet la redirection de ports
|
||||
* Combinaison de chiffrement symétrique ET asymétrique
|
||||
* Standardisé à l'IETF
|
||||
|
||||
==== SSH et redirection de ports ====
|
||||
|
||||
Cf. Diapositives.
|
||||
|
||||
On peut rediriger n'importe quel port de notre machine vers un serveur ayant SSH.
|
||||
Du coup on peut, en 3 sauts, à obtenir un service distant qui était indisponible à la base.
|
||||
|
||||
Exemple : accéder à canette via sterne + ssh.
|
||||
|
||||
===== Kerberos v5 =====
|
||||
|
||||
* Protocole d'authentification réseau destiné aux applications client/serveur (MIT)
|
||||
* Serveur Kerberos
|
||||
* Service Réseau en mode connecté (sur TCP)
|
||||
* Client du service Réseau
|
||||
* 3 niveaux d'authentification
|
||||
* À l'établissement de la connexion
|
||||
* À chaque ...compléter !!!!
|
||||
|
||||
Tickets Kerberos actifs sous notre pc : taper la commande **klist**.
|
||||
krbtray => sous windows (à vérifier)
|
||||
|
||||
===== Authentification des utilisateurs du département =====
|
||||
|
||||
* LDAP : Lightweight Directory Access,
|
||||
* Protocol : procotle d'accès aux annuaires X500 (RFC 3377)
|
||||
* Active Directory : annuaire des ressources partagées (Win2K Server), inclus un annuaire de type LDAP.
|
||||
* Kerberos : protocole d'authentification à base de tickets
|
||||
* SSO : Signle Sign On, mécanismes permettant de ne s'authentifier qu'une seule fois
|
||||
|
||||
===== Inscription d'un étudiant =====
|
||||
|
||||
Cf. Diapositive
|
||||
|
||||
|
||||
|
||||
|
||||
Binary file not shown.
Binary file not shown.
Binary file not shown.
Loading…
Reference in New Issue