SSL et Cookies dans WordPress 2.6

Cet article est la traduction d’un post original en anglais de Ryan : lire ici

WordPress 2.6 est fourni avec un meilleur support pour accéder à l’interface d’administration de votre blog grâce à une connexion sécurisée par SSL. Ceci est rendu possible en délivrant les cookies d’autorisation uniquement au travers de sessions HTTPS encryptés par SSL. Pour y parvenir tout en permettant toujours une connexion par http classique la version 2.6 passe de l’installation d’un seul cookie à l’installation de 3 cookies.

Dans les distributions précédentes WP n’installait qu’un seul cookie. Ce cookie était distribué pour toutes les zones de votre site, à la fois au travers de connexions sécurisées par SSL ou au travers de connexions classiques, non sécurisées. Il était distribué pour les pages publiques et celles d’administration. En installant un cookie pour les pages publiques WP pouvait proposer l’édition d’articles directement sur la page ou l’affichage d’un lien de déconnexion aux utilisateurs dont la session était active.

Pour supporter correctement le SSL WordPress doit pouvoir restreindre la distribution du cookie d’authentification aux seules sessions sécurisées par SSL. Si WordPress ne délivrait qu’un seul cookie sur une connexion sécurisée alors ce dernier ne serait pas délivré pour les parties publiques du site auxquelles les lecteurs accèdent par des voies non sécurisées. Ainsi WordPress ne pourrait délivrer des informations relatives aux utilisateurs connectés visitant les pages publiques.

Pour remédier à ça WP installe 2 cookies différents : Un pour le statut de connexion et un autre pour l’authentification.

Le cookie servant au statut de connexion est délivré pour toutes les pages de votre blog à la fois par des connexions SSL ou non-SSL. Ce cookie qui indique le statut de votre connexion ne peut être utilisé pour accéder à l’administration du blog. Il indique simplement si tel utilisateur est connecté ou non. Ce cookie ne peut être utilisé pour faire des changements sur le blog.

Le cookie d’authentification, d’un autre côté, est délivré seulement pour la partie administration du blog et peut être utilisé pour faire des changements sur le blog. Si vous vous connectez via HTTPS votre cookie d’authentification sera délivré seulement par connexion sécurisée par SSL. Si vous vous connectez par HTTPS et qu’ensuite vous visitez vos pages d’administration via HTTP vous devrez vous reconnecter pour obtenir un cookie d’authentification non sécurisé par SSL. Par défaut vous avez le choix de visiter vos pages d’administration soit par HTTP ou HTTPS. Si vous voulez que toutes les connexions aux pages d’administration le soient par HTTPS ajoutez cette ligne à votre fichier wp-config :

define(’FORCE_SSL_ADMIN’, true);

Ceci interdira les connexions non SSL à votre blog. Ce qui signifie qu’aucun cookie d’authentification ne sera délivré non encrypté. Si vous voulez rendre obligatoire les connexions par SSL pour éviter que les noms d’utilisateurs et mots de passe circulent en clair tout en laissant le choix à vos utilisateurs d’utiliser HTTP ou HTTPS pour visiter les pages admin ajoutez ceci au fichier wp-config :

define(’FORCE_SSL_LOGIN’, true);

Ceci ne force pas tous les cookies à être délivré par SSL. L’utilisateur a le choix entre une plus grande sécurité par HTTPS ou une plus grande vitesse par HTTP. Si vous ne voulez pas avoir à choisir et obliger les connexions à se faire par HTTPS alors FORCE_SSL_ADMIN est ce dont vous avez besoin.

Avec ces nouveaux cookies arrivent de nouvelles clés secrètes pour les créer. Souvenez vous que WordPress 2.5 proposait de nouvelles clés secrètes pour permettre une sécurité renforcée pour la création des cookies. Si vous prévoyez d’utiliser le support SSL dans WP 2.6 vous voudrez probablement définir la clé secrète pour le cookie sécurisé. Si vous ne prévoyez pas d’utiliser SSL vous pouvez conservez votre SECRET_KEY existante.

Voici un exemple de définition de la nouvelle clé secrète :

define(’AUTH_KEY’, ‘mettez votre expression unique ici’);
define(’SECURE_AUTH_KEY’, ‘mettez votre expression unique ici’);
define(’LOGGED_IN_KEY’, ‘mettez votre expression unique ici’);

Vous devriez changer ces expressions pour quelque chose d’unique et de préférence des expressions aléatoires. Chaque clé devrait avoir son expression. Visitez http://api.wordpress.org/secret-key/1.1 pour obtenir un ensemble de clés aléatoires que vous pourrez copier-coller dans votre fichier wp-config.php. Encore une fois, si vous ne pensez pas utiliser SSL vous pouvez conserver les SECRET_KEY que vous possédez déjà.

Ceci ne doit pas avoir d’impact sur la majorité des plugins et thèmes. Je dis la « majorité » parce qu’il y a quelques thèmes qui envoient des requêtes POST et AJAX vers les fichiers dans le répertoire des thèmes. Les cookies d’authentification sont délivrés seulement pour les répertoires wp-admin et wp-content/plugins, alors les fichiers téléchargés directement depuis wp-content/themes ne verront pas les cookies. Les thèmes devraient envoyer leur requêtes POST et AJAX aux fichiers admin-post.php ou admin-ajax.php. J’ai ajouté un court article au codex sur la façon dont les thèmes et les plugins devraient gérer leurs requêtes POST et AJAX.

Les plugins pourraient aussi créer des liens qui ne seraient pas correctement préfixés avec HTTPS. N’importe quel contenu téléchargé au sein d’une page sécurisée doit être transmis avec un lien en HTTPS pour éviter les messages d’alerte du navigateur à propos du contenu délivré partiellement encrypté.
Wordpress 2.6 introduit cinq nouvelles fonctions qui prennent en charge l’utilisation du protocole correct lors des téléchargements des CSS, JS et autres fichiers au sein d’une page d’administration encryptée par SSL. Ce sont site_url(), admin_url(), includes_ur(), plugins_url(), and content_url(). Chaque fonction accepte en option un chemin relatif respectivement vers les url du site, de l’admin, de include, de plugins et content. Par exemple pour faire un lien vers wp-content/plugins/foo/foo.php utilisez plugins_url(’foo/foo.php’). Les plugins qui chargent du CSS et JS par des liens relatifs n’ont pas besoin d’utiliser ces fonctions. Les liens relatifs vont utiliser automatiquement le protocole correct. Si votre hébergeur supporte le SSL, wordpress 2.6 vous permettra d’utiliser cette méthode d’une manière sécurisée. Profitez en et aidez nous à améliorez le support SSL en nous signalant tous les bugs que vous rencontrerez.

L'auteur :

Co-fondateur de WordPress Francophone.

Directeur associé de Be API, agence spécialisé dans le développement de solutions complexes.

Freelance spécialisé dans l'expertise WordPress et BuddyPress

Retrouvez mon blog : www.herewithme.fr

Et mon site professionnel : beapi.fr

Informations annexes à l'article

Cet article a été publié le Mercredi 23 juillet 2008 à 13:08 et est classé dans WordPress.

Vous pouvez en suivre les commentaires par le biais du flux RSS 2.0.

Les commentaires et pings sont fermés.

Article lu 7 287 fois.

Méta

1 étoile2 étoiles3 étoiles4 étoiles5 étoiles (No Ratings Yet)
Loading...Loading...
Imprimer cette article Envoyer cet article à un ami

7 commentaires

  1. Génial pour la sécurité, mais très bordelisant pour ceux qui utilisent bbpress couplé avec wordpress en utilisant un seule et même cookie. Bref, cela va demander une petite adaptation !

  2. Bonjour,

    il n’y a pas de fonction horodateur ? j’ai pas trouvé…car c’est toujours sympa de pouvoir créer des articles en avance.

  3. seb: il suffit de changer l’heure du billet à laquelle tu souhaites qu’il soit publié! :)

  4. Ca à l’air vachement bien mais c’est vachement technique cette affaire là :D
    Je suppose que j’ai du faire quelque chose qui fallait pas car je suis déconnecté de l’admin à chaque fois que je reviens sur mon blog…

  5. J’essaie d’installer la nouvelle version 2.6 de WP sur mon site AuroresBoréales.com, pour créer une nouvelle partir « blogue » du site, mais malheureusement, c’est impossible de créer le blogue à cause de ça. au lancement de l’install.php, ça affiche :

    Fatal error: Call to undefined function: force_ssl_admin() in / »nom du serveur »/html/blogue/wp-settings.php on line 390

  6. euh, oui, alors ma question est : comment résoudre ça ?
    (désolé pour la répétition).
    Merci ! ;-)

  7. Le seul plugin à jour qui permet de convertir toutes les adresses et liens de votre site wordpress (front office ou/et Backoffice)en HTTPS://
    se nomme: wordpress-https

    http://wordpress.org/extend/pl.....ess-https/

    et il marche à merveille avec un certificat ssl comme ceux fournis par startssl.com (gratuit).

Les commentaires sont fermés.

écrire un commentaire