Voici donc cette classe :

<?php

/**
 * sfValidatorSchemaDependency allows to define dependency between fields
 */
class sfValidatorSchemaDependency extends sfValidatorSchema
{

  /**
   * Constructor.
   *
   * Available options:
   *
   *  * affected_field:  The field that is required or not
   *  * expected_values: A key/value array that represents the fields and their value
   *                     that must be matched to set the affected_field as required
   *
   * @param string $affected_field   The field that is required or not
   * @param array  $expected_values  A key/value array that represents the fields and their value
   *                                 that must be matched to set the affected_field as required
   * @param array  $options          An array of options
   * @param array  $messages         An array of error messages
   *
   * @see sfValidatorBase
   */
  public function __construct($affected_field, $expected_values, $options = array(), $messages = array())
  {
    $this->addOption('affected_field', $affected_field);
    $this->addOption('expected_values', $expected_values);

    parent::__construct(null, $options, $messages);
  }

  /**
   * @see sfValidatorBase
   */
  protected function doClean($values)
  {
    if (null === $values)
    {
      $values = array();
    }

    if (!is_array($values))
    {
      throw new InvalidArgumentException('You must pass an array parameter to the clean() method');
    }

    $affected_field = isset($values[$this->getOption('affected_field')]) ? $values[$this->getOption('affected_field')] : null;

    $bAllValuesMatched = true;
    foreach ($this->getOption('expected_values') as $field => $value)
    {
      // if a field has not the expected value
      if (!isset($values[$field]) || $values[$field] != $value)
      {
        $bAllValuesMatched = false;
        break;
      }
    }

    // if every field has the expected value, and affected_field not defined
    if ($bAllValuesMatched && !$affected_field)
    {
      // "affected_field is required" error
      throw new sfValidatorErrorSchema($this, array(
        $this->getOption('affected_field') => new sfValidatorError($this, 'required')
      ));
    }

    return $values;
  }
}

Et voici comment l'utiliser dans le cas de l'exemple de notre introduction :

  /**
   * @see sfForm::configure()
   */
  public function configure()
  {
    // ...
    $this->mergePostValidator(new sfValidatorSchemaDependency('postal_code', array('country' => 'FR')));
  }

Ainsi, lors de la validation du formulaire, si le champ country vaut FR et si le champ postal_code est vide, une sfValidatorError de type required va être liée au champ postal_code.

Notez qu'il est possible de définir plusieurs dépendances, en passant plusieurs éléments dans le tableau en second paramètre du constructeur de sfValidatorSchemaDependency.

Pour la création du squelette du panel sfWebDebugPanelSoapClient, je vous laisse suivre le tutoriel officiel, qui est très bien fait. Une fois que c'est fait, on va remplir ce panel en utilisant l'Event Dispatcher. Pour cela, on va commencer par générer les événements ; ça se passe donc dans mon cas dans la class MySoapClient, la classe qui gère les choses que je veux logger.

Je commence par y créer la méthode qui crée et dispatche l'événement :

  /**
   * Dispatch a 'soapclient.log' event (used by web debug panel)
   *
   * @param SoapCommand $oCommand  The executed command
   * @param int         $iDuration The duration of the soap call
   */
  protected function dispatchEvent($oCommand, $iDuration)
  {
    $this->context->getEventDispatcher()->notify(new sfEvent($this, 'soapclient.log', array(
      'command'  => $oCommand,
      'duration' => $iDuration,
    )));
  }

Comme vous le voyez, je crée un événement de type "soapclient.log" portant sur l'objet courant ($this), et je fournis au passage des paramètres informatifs que j'afficherai dans mon panel un peu plus tard... Puis j'utilise l'Event Dispatcher pour notifier les objets qui écoutent les événements "soapclient.log" qu'il y en a un nouveau !

Il faut ensuite appeler cette méthode au moment opportun, dans mon cas, immédiatement après l'appel au WebService.

    $iTime = microtime(true);
    // do your stuff...
    $this->dispatchEvent($oCommand, microtime(true) - $iTime);

Retournons maintenant dans la classe panel sfWebDebugPanelSoapClient, afin justement de lui dire d'écouter ce type d'événements. Pour cela, on va surcharger son constructeur afin de connecter une méthode à cet événement.

  protected $aEvents = array();

  public function __construct(sfWebDebug $webDebug)
  {
    parent::__construct($webDebug);
    $this->webDebug->getEventDispatcher()->connect('soapclient.log', array($this, 'listenForSoapClientLogs'));
  }

  /**
   * Listens to soapclient.log event and record them
   *
   * @param sfEvent $event
   */
  public function listenForSoapClientLogs(sfEvent $event)
  {
    $this->aEvents[] = $event;
  }

Dans le constructeur, on demande à l'Event Dispatcher d'appeler la méthode "listenForSoapClientLogs" de notre classe dès qu'il reçoit un événement de type "soapclient.log". Dans cette méthode, on stocke juste chaque événement reçu dans un tableau, propriété de notre classe.

On a désormais toutes les billes. Il n'y a plus qu'à afficher le tout dans notre panel.

  /**
   * Get the html content of the panel
   *
   * @return string $html
   */
  public function getPanelContent()
  {
    return '
    <div id="sfWebDebugSoapClientLogs">
      <ol>'.implode("\n", $this->getSoapClientLogs()).'</ol>
    </div>
    ';
  }

  /**
   * Retrieves events as html
   *
   * @return string
   */
  protected function getSoapClientLogs()
  {
    $aRet = array();
    $i = 1;
    foreach ($this->aEvents as $oEvent)
    {
      $aParams = $oEvent->getParameters();

      $oClient = $oEvent->getSubject();
      $oCommand = $aParams['command'];

      $sHtml = '
        <li>
          ' . get_class($oCommand) . ' (' . round(($aParams['duration'] * 1000), 2) . ' ms)
          ...
        </li>
      ';

      $aRet[] = $sHtml;
      $i++;
    }
    return $aRet;
  }

Et voilà ! Le tour est joué ! On a un joli panel pour débugger dans mon cas un client SOAP, mais je suis sûr que vous en ferez plein de trucs utiles !

Ça me fait penser qu'on pourrait améliorer ça en passant le validateur (ici "new sfValidatorEmail()") en option de ValidatorEmailList pour pouvoir valider des listes de ce qu'on veut en fait... Enfin je vous laisse le faire !

La plupart des informations intéressantes que j'ai récoltées proviennent de ce tutoriel : un anti brute-force léger et rapide.

Le principe : empêcher un utilisateur et surtout un robot de tenter une infinité de couples login / mot de passe sur une page d'authentification donnée. Pour cela, on doit compter les tentatives erronées des utilisateurs, et les empêcher à partir d'un certain seuil de tentatives par unité de temps. Voici les questions qui en découlent.

Sur quoi se baser pour compter les tentatives ?

Sur l'IP du client ? Mauvaise idée, cette donnée n'est pas fiable, la plupart des hackers sauront la modifier et pourront donc faire une infinité de tentatives.

Sur les sessions ? Non plus, il suffit d'effacer le cookie et c'est reparti pour d'autres tentatives...

Sur le login utilisé pour l'authentification ? Ce n'est pas une solution parfaite, mais c'est la meilleure que j'ai trouvé à ce jour. L'inconvénient principal est que n'importe qui peut bloquer le compte de quelqu'un s'il connait son login...

Si vous avez d'autres idées, je suis preneur !

Comment stocker le nombre de tentatives effectuées ?

En base de données ? Ca semble être la solution la plus logique. Néanmoins, certains projets ne fonctionnent pas avec une base de données (et c'est mon cas ici !). Ce serait un peu intrusif de devoir créer une base pour ça, de charger un ORM etc.

Dans des fichiers ? C'est la solution qu'a choisi l'article ci-dessus. Niveau rapidité, charge etc., il faudrait faire un comparatif avec l'utilisation d'un ORM pour savoir qui est le meilleur. Cette solution est moins envahissante dans la mesure où elle fonctionnerait sur tous les projets symfony (à ma connaissance).

Si vous avez d'autres idées...

Où intervenir au niveau du code symfony ?

A la base, j'avais pensé qu'il faudrait faire un filtre pour contrôler les accès en amont dans l'application. Le problème est que, si je pars sur la solution d'utiliser le login pour compter les tentatives, j'ai besoin de ce login pour incrémenter son compteur de tentatives en cas d'échec. J'ai donc également besoin de savoir si la tentative d'autentification est un échec ou non. Pour cela, j'ai donc besoin d'internvenir au niveau du contrôleur, dans l'action qui gère l'authentification. J'imagine que le développeur devra ajouter un appel de ce genre lorsqu'une tentative d'authentification échouera :

Cette méthode aura pour but d'incrémenter le compteur d'échec pour cet utilisateur.

Il faudrait également, avant la tentative d'authentification, vérifier que l'utilisateur qui s'apprête à s'authentifier a le droit de le faire :

Faut-il s'intégrer au plugin sfGuard ?

Dans un second temps peut-être, on va pas mettre la charrue avant les bœufs ! Mais bon, à creuser.

Voilà pour les premières pistes pour la réalisation de ce petit plugin qui me semblerait très utile pour tout développeur sensible à la sécurité de son application (aka tout bon développeur !). J'attends vos remarques / suggestions / idées avec impatience !

PS : suivez les évolutions sur la page officielle de sfAntiBruteForcePlugin.

En ça :

Mais imaginons que le tableau que vous lui passez est construit dynamiquement, et que parfois il est vide... Que se passe-t-il dans ce cas ? Avec MySQL, l'instruction "IN ()" retourne une erreur. Que fait Doctrine ? Eh bien... Rien. Il ignore le critère et effectue la requête, donnant des résultats souvent trompeurs... Une exception est censée être levée, mais une coquille dans le code fait qu'elle ne l'est pas. Un ticket est ouvert chez Doctrine... Attention donc !

Ce plugin permet en effet de mesurer la qualité et la volumétrie d'un projet. Il peut compter le nombre d'applications, de modules, d'actions d'un projet, vérifier la longueur des fonctions et des templates, lève des alertes dès qu'il repère des choses anormales, et bien d'autres choses encore.

Ce n'est pas juste un jouet pour sortir quelques statistiques sur son travail. Tout son intérêt réside dans son utilisation en tant qu'outil d'intégration continue. Imaginez que vous commenciez un tout nouveau projet Symfony : si chaque matin, après votre nesquik, vous lancez l'analyse de votre projet et si vous suivez les précieux conseils donnés dans la page de résultat, vous aurez au final un code beau, propre et facile à maintenir ! Vous serez alors le roi du pétrole et vous pourrez faire un énorme don aux gentils développeurs de ce plugin, sans qui vous ne seriez rien !

Et si vous ne le trouvez pas assez strict (ou trop strict, honte sur vous :)), pas de problème ! Il est entièrement paramétrable via son fichier YAML.

L'analyse se lance en une simple commande Symfony :

symfony project:analyse --application="frontend" --env="dev" > analysis.html

Elle génère un rapport sous la forme d'un simple fichier HTML que vous pouvez bien sûr visualiser dans votre navigateur favori :

Pour davantage d'informations, rendez-vous sur la page du plugin sfProjectAnalyserPlugin.

PS : vous l'aurez peut-être deviné, je fais partie des développeurs de ce magnifique plugin ! Même si ma contribution n'a été que très modeste pour le moment... (je vais me rattraper Loïc !)

A la base, mon projet se connectait à une seule base, la configuration classique, la routine. Un beau jour, j'ai eu besoin d'aller mettre à jour la valeur d'un champ dans une autre base de données. Deux possibilités se présentaient :

• utiliser les infâmes fonctions mysql_*() comme dans les années 80 (bon, c'est peut-être pas si vieux, mais presque)
• découvrir le monde merveilleux des connexions Doctrine multiples

Ne m'étant jamais penché sur ce point, j'avais peur que la seconde option soit trop lourde. Mais conseillé par mes collaborateurs d'SQL Technologies, la tâche s'est avérée finalement très simple.

Premièrement, il a fallu modifier le fichier config/databases.yml afin qu'il prenne en compte la seconde connexion :

J'ai ensuite introspecté cette seconde base pour que Symfony génère son schéma (vous pouvez le faire à la main si vous êtes courageux !) :

Et là, magie : dans le fichier config/doctrine/schema.yml, on voit désormais que chaque table est liée à une des deux connexions grâce au paramètre... "connection" !

Et lorsque l'on reconstruit le modèle, la magie opère ! Dans les fichiers Base*.class.php du modèle, une nouvelle ligne est apparue, permettant "d'attacher" chaque classe du modèle à sa connexion :

Et c'est tout ! On peut alors utiliser nos objets presque sans se soucier d'où proviennent et où vont les données.

Vive Doctrine, et vive Symfony !