Articles de l'utilisateur

Onglets principaux

Paul Playe

Déploiement de site Drupal sur la plateforme Openshift

La plateforme Openshift, présentée par ailleurs, permet de déployer en quelques clics une instance de Drupal, en version 7 ou en version 8.

Le but de cet article n'est pas de montrer comment choisir «Drupal» dans une liste d'applications, mais de montrer les différences dans la gestion d'un site Drupal dans le cloud de Red Hat.

Le Drupal étant packagé et prêt à l'emploi, on ne passe pas par les étapes classiques d'installation (Choix et configuration de la base de données, nom et mot de passe du compte d'administration…). Tout est généré à l'instanciation du Drupal et les informations d'authentification vous seront fournies à l'issue de la création du site. De même, vous n'avez pas à vous soucier de l'installation et de la configuration d'un SGBD (Ce sera par défaut du Mysql).

On peut se dire qu'il est à ce moment plus simple de n'installer qu'un environnement PHP le SGBD de notre choix et de faire une installation classique, mais la configuration de la base de données lors de l'installation de Drupal n'est pas simple, puisque les informations de connexion à la base de données se font par des variables d'environnement ($OPENSHIFT_MYSQL_DB_HOST, $OPENSHIFT_MYSQL_DB_PORT…etc…).

Un des avantages du cloud, c'est la scalabilité, mais dans le cas de Drupal l'application n'est pas scalable par défaut (comme pour les autres CMS disponibles en cartridges sur Openshift). Si vous voulez en savoir plus là dessus, le fichier README.md dv dépot utilisé par Openshift pour gérer sa version de Drupal présente quelques conseils pour rendre le site scalable.

Pour l'installation en elle même, il faut bien évidemment un compte Openshift actif (de plus les outils d'administration développés par Red Hat seront également nécessaires par la suite) et de se rendre dans l'interface de gestion des applications.

Les ressources disponibles et utilisées sont calculées en gears. Vous avez droit dans une utilisation gratuite, à trois small gears sachant que Drupal, PHP et mySql tiennent sur un seul gear. Si vous avez un gear de disponible, vous pouvez aller sur la liste des applications disponibles en appuyant sur le bouton dédié «Add Application…».

Dans la liste des applications disponibles, dans la section «Instant App» vous trouverez Drupal 7 (car il est maintenu par Openshift), et pour Drupal 8, il vous faudra chercher dans la section «PHP».

Il faut garder à l'esprit que le dépot utilisé par Openshift pour déployer le Drupal ne permet pas de bénéficier des alertes de mises à jour de sécurité et qu'il faut donc suivre soit même les sorties de correctifs pour les déployer par soi même.

En sélectionnant «Drupal 7» ou «Drupal 8», nous allons pouvoir configurer notre application, notamment son nom, puis les versions des dépendances de Drupal (versions de mySql et de PHP). Je recommande de ne pas toucher au choix du dépot d'origine duquel proviendra le code source de l'application.

Plus qu'à appuyer sur le «Create Application» et attendre (le déploiement peu prendre quelques minutes) la mise en place et la configuration du Drupal.

La page suivante nous offre les identifiants générés pour l'administration du site ainsi que les identifiants d'accès à la base de données.

Une des grosses différences entre le déploiement d'un Drupal de cette façon et une installation une installation d'un espace de travail sur Openshift, c'est la gestion via git qui est différente. Si nous n'avions déployé qu'un environnement de travail, nous aurions eu un dépôt à la racine de notre application sur lequel travailler. Dans le cas d'une installation de Drupal, nous avons notre application qui se trouve en dehors du dépôt.

Mais un autre outil de travail va nous permettre de mettre en place des modules contribués sans avoir à passer par l'interface d'administration, Drush.

Openshift nous authorise en effet une connexion SSH avec notre application, et tout passe par les outils développés par Red Hat.

[paul@localhost ~]$ rhc setup
OpenShift Client Tools (RHC) Setup Wizard

This wizard will help you upload your SSH keys, set your application namespace,
and check that other programs like Git are properly installed.

If you have your own OpenShift server, you can specify it now. Just hit enter to
use the server for OpenShift Online: openshift.redhat.com.
Enter the server hostname: |openshift.redhat.com|

You can add more servers later using 'rhc server'.

Using an existing token for drupal@paulplaye.fr to login to
openshift.redhat.com

Saving configuration to /home/paul/.openshift/express.conf ... done

Checking for git ... found git version 1.9.3

Checking common problems .. done

Checking for a domain ... osaurus

Checking for applications ... found 1

drupal http://drupal-osaurus.rhcloud.com/

You are using 1 of 3 total gears
The following gear sizes are available to you: small

Your client tools are now configured.
[paul@localhost ~]$ rhc ssh drupal
Connecting to caf02300020a548a0d635973@drupal-osaurus.rhcloud.com ...

*********************************************************************

You are accessing a service that is for use only by authorized users.
If you do not have authorization, discontinue use at once.
Any use of the services is subject to the applicable terms of the
agreement which can be found at:
https://www.openshift.com/legal

*********************************************************************

Welcome to OpenShift shell

This shell will assist you in managing OpenShift applications.

!!! IMPORTANT !!! IMPORTANT !!! IMPORTANT !!!
Shell access is quite powerful and it is possible for you to
accidentally damage your application. Proceed with care!
If worse comes to worst, destroy your application with "rhc app delete"
and recreate it
!!! IMPORTANT !!! IMPORTANT !!! IMPORTANT !!!

Type "help" for more info.

[enlightened-oise.rhcloud.com caf02300020a548a0d635973]\> drush cc all
'all' cache was cleared. [success]
[enlightened-oise.rhcloud.com caf02300020a548a0d635973]\>

Nous avons donc un Drupal fonctionnel, mais qui n'est pas — pour le moment — très pratique pour développer thèmes et modules, et je ne désespère pas de pouvoir revenir là dessus plus en avant prochainement, certaines bidouilles pouvant nous permettre de tout de même y arriver…

Tags:

cloud

openshift

drupal

Dimanche 14 Décembre 2014

Par pwetosaurus

Paul Playe

Développer une nouvelle fonctionnalité pour Honeypot

Honeypot c'est bien, ça permet de pièger des spam-bots.

Bon, c'est un bon constat de départ.

Ce module ajoute une bonne protection aux formulaires présents sur votre site, tout en évitant les CAPTCHAs qui bloquent tout autant certains humains (et leur font de la peine) que certains spam-bots.

Ce module va offrir une bonne protection, et va permettre de récupérer les IP de ces spam-bots pour pouvoir les bannir ensuite par le blocage d'IPs fourni par Drupal.

Mais les informaticiens sont fainéants. C'est bien connu. Certaines sont même tellement fainéantes, que quand elles croient au père noël, elles lui demandent un module custom...

Petit papa Noël, j'ai été sage, je voudrais un module custom Drupal pour Noël #Merci #Bisous

— Tris Acatrinei (@Tris_Acatrinei) 30 Novembre 2013

Bon. J'avais envie de préserver la magie, et je me suis fait passer pour le Père Noël sur ce coup là, bien que ne connaissant pas le module Honeypot (mais avec un nom pareil, je me doutais bien de ce qu'il faisait).

Après l'avoir installé, on peut remarquer qu'il y a une api, magnifique ! Et surtout, Honeypot fournit un hook appelé lorsqu'il lève un cyber-lièvre.

/**
 * React to the rejection of a form submission.
 *
 * When honeypot rejects a form submission, it calls this hook with the form ID,
 * the user ID (0 if anonymous) of the user that was disallowed from submitting
 * the form, and the reason (type) for the rejection of the form submission.
 *
 * @param (string) $form_id
 *   Form ID of the form the user was disallowed from submitting.
 * @param (int) $uid
 *   0 for anonymous users, otherwise the user ID of the user.
 * @param (string) $type
 *   String indicating the reason the submission was blocked. Allowed values:
 *     - honeypot: If honeypot field was filled in.
 *     - honeypot_time: If form was completed before the configured time limit.
 */
function hook_honeypot_reject($form_id, $uid, $type) {
  if ($form_id == 'mymodule_form') {
    // Do something...
  }
}

Nous avons donc le hook qui se déclenche au bon moment et dans le bon contexte. Il faut donc maintenant bannir l'IP du spam-bot. Tout comme Drupal l'aurait fait lorsqu'une IP lui est passée dans la gestion du module Blocked IP.

Et en effet on trouve la fonction recherchée dans modules/system/system.module :

function system_block_ip_action() {<br />  $ip = ip_address();<br />  db_insert('blocked_ips')-&gt;fields(array('ip' =&gt; $ip))-&gt;execute();<br />  watchdog('action', 'Banned IP address %ip', array('%ip' =&gt; $ip));<br />}<br />

Rien de bien méchant, la fonction system_block_ip_action récupère l'ip du visiteur, l'ajoute dans la table blocked_ips qui liste les adresses ip à bloquer, puis ajoute une entrée dans le livre de bord de Drupal.

Nous avons le hook déclencheur, puis nous avons la fonction à appeler. Il suffit donc de créer un module qui implémentera le hook_honeypot_reject() pour appeler system_block_ip_action. Je passe sur le fichier .info qui est très classique et ne sert qu'à définir le nom, ranger ce module dans la catégorie spam prevention et à appeler le code du module, que voici :

/**
* Implements hook_honeypot_reject($form_id, $uid, $type)
*
* @param (string) $form_id
* Form ID of the form the user was disallowed from submitting.
* @param (int) $uid
* 0 for anonymous users, otherwise the user ID of the user.
* @param (string) $type
* String indicating the reason the submission was blocked. Allowed values:
* - honeypot: If honeypot field was filled in.
* - honeypot_time: If form was completed before the configured time limit.
*/
function hive_honeypot_reject($form_id, $uid, $type) {
  // if a spambot is detected by the Honeypot module, we call the system_block_ip_action() to automatically ban the spambot IP.
  system_block_ip_action();
}

Le module a été déployé aujourd'hui et a banni ses premiers spams bots. Dans l'idéal, il faudrait également pouvoir gérer un banissement des adresses IP par listing dans le .htaccess pour permettre l'utilisation du module dans le cas de gros sites sans perdre en performances.

De la même façon, une ligne dans l'interface d'administration Drupal permettant d'automatiser ou non le banissement de l'IP serait un plus appréciable... Mais ça sera pour plus tard !

Tags:

Pièces jointes:

Mercredi 4 Décembre 2013