faille dans ssl 3.0 (CVE-2014-3566)
Permet un MITM (man in the middle) si utilisé.
Vérifier grace à des outils en ligne : https://www.poodlescan.com/ ou https://www.ssllabs.com/ssltest/index.html
-> sur vos serveurs : désactiver ssl v3
    ex : sur NGINX, dans /etc/nginx/nginx.conf :
         ssl_protocols  TLSv1 TLSv1.1 TLSv1.2;  # don’t use SSLv3 ref: POODLE
         (cf. http://nginx.com/blog/nginx-poodle-ssl/)
         et puis reload nginx : sudo service nginx restart
-> vos clients (navigateur) -> ne pas utiliser ssl v3
   https://zmap.io/sslv3/browsers.html

NB : bonnes pratiques pour l'utilisation de ssl côté serveur https://www.ssllabs.com/downloads/SSL_Server_Rating_Guide.pdf

En résumé :

   yield permet de faire des générateurs
   On peut demander la prochaine valeur du générateur avec next(). Dans ce cas, le code s’exécute jusqu’au prochain yield.
   On peut envoyer une valeur au générateur avec send(). Dans ce cas, on DOIT partir d’un yield existant duquel on récupère la valeur envoyée via une assignation. Donc il faut au moins un next() avant d’utiliser un send() et un signe égal sur le yield.
   send() va aussi aller au prochain yield et retourner sa valeur.
   Une coroutine n’est qu’une formalisation de la manière d’éffectuer une tâche avec un init, une exécution et une finalisation optionelle en utilisant un générateur. C’est une solution générique à un problème courant, mais plus léger qu’une classe.
   Généralement on décore les générateurs coroutines avec un décorateur @coroutine pour s’éviter d’appeler next() à la main et notifier l’usage qu’il est fait de ce générateur.
   On peut chaîner des coroutines comme on chaîne des générateurs, mais au lieu de lire les données une à une (PULL), on les envoie une par une (PUSH). Cela est pratique quand on ne sait pas à l’avance quand une nouvelle donnée va arriver.

GoooooD !
$(function() {

   $("#source li").draggable({
       connectToSortable: '#destination',
       helper: 'clone'
   })

   $("#destination").sortable();

 });