PHP : un langage web

Comme je l’ai dit, PHP est un langage web. Il propose donc de base un ensemble de choses utiles pour interagir avec un environnement HTTP (entre autres). Vous n’avez pas pu passer à côté de nos chers amis $_GET et $_POST par exemple (sauf si vous avez appris PHP avec symfony mais bon, pas sur que ce soit le meilleur moyen). Ensuite PHP est un langage de template à lui tout seul. Vous mélangez du PHP au sein d’un fichier HTML et vous obtenez ce que vous souhaitez, sans effort particulier. Prenons le fichier index.php suivant :

<h1>Hello world</h1>
<p>
  Hello <?php echo $_GET['name']; ?>
</p>

Vous utilisez ensuite Apache et mod_php pour l’afficher (avec MAMP, WAMP, ou ce que vous voulez) en appelant index.php?name=Karamazof et vous êtes les rois du monde. Admettons. Attaquons les choses sérieuses.

Ruby : un langage tout court

C’est là que ça se gâte. Tout d’abord je tiens à dire que je n’ai pas beaucoup d’expérience en Ruby, il y a de ça un mois je n’en avais encore jamais fait, soyez indulgents ;-). Mais j’ai tout de suite été confronté à l’évidence : Ruby (comme Python d’ailleurs) n’est pas un langage web. Pas qu’on ne peut pas faire de web avec (ça se saurait), mais il n’a pas été initialement prévu pour cela. Qu’est-ce que cela implique ? Vous n’avez pas de raccourcis/fonctions pour accéder à l’environnement HTTP comme vous pouvez avoir avec PHP et ses $_GET et $_POST.

Il faut donc en Ruby utiliser une couche standardisée (ou presque) entre votre code et le serveur web, couche qui vous donnera la possibilité d’accéder aux éléments d’une requête HTTP et de renvoyer une réponse à afficher. En Ruby le « standard de facto » est maintenant Rack (rien à voir avec Rake). Rack est une couche d’abstraction entre le serveur web (peu importe lequel) et votre code. Vous devrez bien sûr adapter votre code pour qu’il soit compatible Rack et puisse être exécuté sur n’importe quel serveur web qui propose une interface Rack (à peu prêt tous maintenant). C’est ce que je vous montre ci-dessous.

À noter que le problème est le même pour Pyhon et que Rack a d’ailleurs été inspiré de la solution trouvée pour Python qui s’appelle WSGI.

Une application Rack

Une application Rack qu’est-ce que c’est ? C’est une application qui a comme point d’entrée une méthode call qui prend un tableau en paramètre (souvent nommé env) et qui renvoie un tableau contenant le statut HTTP, les headers HTTP, et le contenu. Vous pouvez aller consulter le post de blog d’origine ou l’article Wikipedia.

class HelloWorld
  def call(env)
    [200, {"Content-Type" => "text/plain"}, ["Hello world!"]]
  end
end

Heureusement vous pouvez inclure des modules rack pour vous faciliter la vie, et notamment pour construire un object Request à partir de cet environnement et un objet Response pour faciliter la création de la réponse à envoyer au navigateur. À noter que vous pouvez très bien utiliser env et retourner un tableau de contenu vous même comme l’exemple ci dessus, mais c’est je trouve pas le plus pratique. Voici un exemple de code ci-dessous :

#hello_world.rb
 
require 'rack/request'
require 'rack/response'
 
class HelloWorld
  def call(env)
      request = Rack::Request.new(env)
 
      response = Rack::Response.new
 
      response.write "<h1>Hello world</h1>"
      response.write "<p>"
      response.write "  Hello " + request.GET['name']
      response.write "</p>"
      response.finish
  end
end

Pour tester votre application vous avez plusieurs choix (dont Apache si vous le souhaitez) mais je vous conseille pour commencer d’utiliser rackup qui vous permettra d’avoir un serveur de test assez facilement. Pour ce faire créez un fichier config.ru avec le contenu suivant dedans :

#config.ru
 
require 'hello_world'
 
run HelloWorld.new

Rien de bien compliqué ici, on inclut le fichier hello_word.rb précédemment créé et on dit à rackup de lancer notre application.

Installez ensuite les gem nécessaires :

sudo gem install webrick rackup

Puis pour lancez le serveur web (webrick par défaut) avec rackup, placez vous dans le répertoire contenant vos fichiers puis exécutez la commande suivante :

rackup -I.

Vous devriez pouvoir vous rendre sur http://127.0.0.1:9292/?name=Vincent et voir votre première page web en Ruby !

Petite précision, si vous souhaitez modifier votre code et voir les modifications sans relancer le serveur web, utilisez shotgun à la place de rackup (à n’utiliser qu’en développement) :

sudo gem install shotgun
shotgun -I.

Conclusion

Ruby est un langage fort sympathique avec beaucoup de possibilités que PHP ne permet même pas d’entrevoir. En revanche en ce qui concerne le web on comprend un peu mieux pourquoi PHP est beaucoup plus populaire que Ruby pour faire du web : PHP a été prévu pour, pas Ruby. Mais je ne saurais vous conseiller d’essayer le Ruby, on y prend vite goût.

Crédit photo : http://www.flickr.com/photos/pswansen/41832591/

Modèle et persistance

La première chose que l’on m’a apprise lorsqu’on m’a parlé de MVC, c’était que le M (pour model) devait contenir la logique « métier » de notre application. Quand on parle de métier, c’est bien ce qui est spécifique à l’application développée. La partie Modèle d’une calculatrice doit savoir calculer (Lapalisse si tu m’entends, elle est pour toi celle là), la partie Modèle d’une gestion de facturation doit savoir gérer les relances, les impayés, les factures … Bon bah très bien tout ça.

Et là c’est le drame, vous vous mettez à utiliser symfony et un des deux principaux ORM du monde PHP : Propel ou Doctrine. Tout d’abord vous trouvez ça chouette, vous pouvez faire un ->save() ou un ->delete() directement sur votre objet, la classe. Mais qu’est-ce que ça veut dire ça ? Ca veut dire que votre objet connait la façon dont il doit persister. Il est fortement couplé à la façon dont vous voulez l’enregistrer, dans notre cas dans une base de données.

C’est assez facile à voir, regardez le graphe d’héritage de votre objet, pour Doctrine tous les objets de votre modèle héritent de la classe Doctrine_Record. Et si, par le plus grand des hasards, vous voulez réutiliser votre logique métier dans une autre application PHP qui n’a rien à voir avec celle que vous développez avec symfony/Doctrine ? Vous êtes bons pour de jolis copier/coller.

DataMapper à la rescousse

L’idéal pour réaliser des M qui ne font que du M, c’est de n’avoir que des PPO (Plain PHP Object), c’est à dire des objets PHP standards (qui n’héritent pas d’une classe comme Doctrine_Record par exemple). Ces PPO doivent réaliser la logique métier de notre application (le M), et une autre partie de l’application doit pouvoir prendre ce PPO et le faire persister quelque part (système de fichier, base de données, …). C’est là qu’intervient le design pattern DataMapper. Il va permettre de faire le lien entre l’objet (l’Entity dans le jargon Doctrine2) et la façon dont il devra persister. Dans Doctrine2, c’est l’Entity Manager qui va réaliser le rôle de DataMapper avec sa méthode flush() qui sauvegarde les changements dans la base de données.

Unit of Work, le copain du DataMapper

La méthode ->flush() de l’EntityManager va permettre d’enregistrer les changements effectués sur les PPO dans la base de données. Ces changements auront été notifiés au préalable à l’Entity Manager par la méthode persist(). Cette méthode permet de dire à l’Entity Manager que l’on veut faire persister notre PPO passé en paramètre de la méthode. Ça se résume comme ça :

<?php
$user = new User;
$user->setName('Mr.Right');
$em->persist($user);
$em->flush();

Ici on informe l’Entity Manager (em), que l’on voudra faire persister les changements apportés à l’objet user via la méthode $em->persist($user). Les changements ne seront effectués dans la base de données qu’une fois la méthode ->flush() invoquée. Si nous avions fait plusieurs ->persist() différents avant de faire notre ->flush(), rien n’aurait encore été écrit dans la base. Mais alors, comment Doctrine fait pour garder trace de ces changements jusqu’au flush ? Il utilise le design pattern Unit of Work. Ce design pattern permet de garder trace de toutes les modifications apportées entre 2 flush(). Il met en place une sorte de transaction, mais au niveau des objets. C’est en partie son utilisation qui permet d’avoir un beau Data Mapper comme l’EM.

Conclusion

L’utilisation d’un DataMapper n’est pas vraiment nouveau dans le monde de la programmation : Hibernate l’implémente déjà pour Java et SQLAlchemy pour Python. En revanche, c’est une petite révolution dans le monde PHP. Si des fois vous préférez garder votre bon vieux Active Record, il existe aussi des solution en PHP : vous pouvez utiliser l’ORM Propel qui est toujours activement maintenu par François Zaninotto ou utiliser des implémentations du pattern Active Record réalisées avec Doctrine2 comme Doctractor ou ActiveEntity codé par l’équipe de Doctrine2. C’est deux derniers exemples montrent bien toute la flexibilité et la puissance de cette nouvelle version de Doctrine !

L’idée dans le tuto d’aujourd’hui est de faire un petit point sur la partie « security » très bien documentée sur le site officiel mais qui change assez des habitudes de symfony 1 et donc semble un peu déroutante au début.

Ce billet est issu de ma propre et récente expérience sur le sujet et sur la branche master de fabien. Les choses peuvent changer ou être inexactes. Dans ce dernier cas, n’hésitez pas à me reprendre via les commentaires ;)

Contexte

Pour l’illustration, je vais simplement partir de la sandbox officielle d’origine configurée sur l’url suivante en local chez moi :

http://sandbox.local

et où je vais vous montrer comment y intégrer votre admin avec un formulaire d’identification sur l’url suivante :

http://sandbox.local/admin/

L’utilisateur sera géré directement via la config, pas de bdd, on veut quelque chose de très simple et rapide à mettre en place.

Première chose à comprendre dans une application Symfony2, il n’y a plus qu’une application… Oui hein, ça parait fou dis comme ça :D Toute la séparation se situe au niveau des bundles, chacun d’eux pouvant embarquer des modèles, controllers, vues différentes, tout en pouvant communiquer avec les autres bundles. Fini les galères pour faire des liens entre un backend et un frontend !

Pour notre admin, nous allons donc générer un nouveau bundle dans notre application via la commande :

php app/console init:bundle Application/AdminBundle

On se retrouve donc avec un controller basique dans ce bundle qui sera la base de notre admin. Première chose à faire, l’activer dans le fichier app/AppKernel.php via la méthode registerBundles.

Mise en place url admin

On va maintenant tenter d’y accéder via l’url /admin/

Pour ça, c’est très simple ! On va modifier notre fichier routing.yml (ou xml ou php hein, mais moi j’aime bien le yml ! ) comme ceci :

#path:app/config/routing.yml
 
homepage:
    pattern:  /
    defaults: { _controller: FrameworkBundle:Default:index }
 
hello:
    resource: HelloBundle/Resources/config/routing.yml
 
admin:
   resource: AdminBundle/Resources/config/routing.yml
   prefix: /admin

et du coup créer le fichier de routing de notre nouveau AdminBundle. Pour ça, on va faire quelque chose de très simple aussi:

#src/Application/AdminBundle/Resources/config/routing.yml
admin_homepage:
  pattern:  /
  defaults: { _controller: AdminBundle:Default:index }

Et par magie, maintenant, si vous accédez à l’url :

http://sandbox.local/admin/

Vous obtenez le mot « Hello » qui n’est d’autre que la vue par défaut qui a été générée par la commande init:bundle
Pour pas se perdre, on va modifier la vue, pour y indiquer le mot admin, ca sera plus clair.

Sécuriser l’url d’admin

2e étape, comment sécuriser tout ça pour ne pas laisser tout le monde accéder à votre admin. Pour ça il y a en fait plusieurs solutions.

• Sécuriser toutes les urls de votre application, en autorisant les connexions anonymes partout, sauf dans votre admin
• Sécuriser toutes les urls de votre admin seulement

La 1ere a l’avantage de faire écrire très peu de ligne de config, mais honnêtement, je ne sais pas s’il y en a une de meilleure que l’autre, donc je présente la première dans ce tuto, mais je vous met le code de la deuxième à la fin. Elles font sensiblement la même chose.

On va donc se lancer dans la config du component security. Pour ça, on se retrouve dans notre config.yml pour y ajouter un provider, qui sera en fait le compte utilisateur de notre admin.

#app/config/config.yml
security.config:
  providers:
    admin:
      users:
        monadmin: { password: monpass, roles: ROLE_ADMIN }

Nous voici avec un compte « monadmin » identifié grâce au mot de passe « monpass » qui sera crédité de l’autorisation « ROLE_ADMIN » (pour pourriez mettre TOTO à la place de ADMIN, ca changerait rien, par contrel mot ROLE est apparemment obligatoire)

Pour l’instant, ca ne change rien. Définissons maintenant une règle firewall ! Le mot utilisé pour définir ce nouveau service fait sourire j’avoue, en fait il s’agit de définir des règles de sécurité pour des motifs d’urls.

On reste dans notre config.yml qu’on enrichit comme ceci:

#app/config/config.yml
security.config:
  providers:
    main:
      users:
        monadmin: { password: monpass, roles: ROLE_ADMIN  }
 
  firewalls:
    admin:
      pattern: .*
      http_basic: true

Et là, vous obtenez normalement une demande d’authentification HTTP sur tout votre site. Ok! Maintenant, on va autoriser des connexions anonymes, c’est à dire qu’on ne va pas forcer les gens à se connecter:

#app/config/config.yml
security.config:
  providers:
    main:
      users:
        monadmin: { password: monpass, roles: ROLE_ADMIN }
 
  firewalls:
    admin:
      pattern: .*
      http_basic: true
      anonymous: true

Maintenant, voyons voir pour mettre en place un formulaire plus conventionnel (et il me semble plus secure si bien fait, mais à confirmer).

#app/config/config.yml
security.config:
  providers:
    main:
      users:
        monadmin: { password: monpass, roles: ROLE_ADMIN }
 
  firewalls:
    admin:
      pattern: .*
      form_login: true
      anonymous: true

Ici on a changé le mode d’authentification pour celui d’un formulaire classique, grâce à l’option form-login

Maintenant, on va verrouiller l’accès à notre admin. Pour ce faire, on va demander une autorisation pour notre url /admin:

#app/config/config.yml
security.config:
  providers:
    main:
      users:
        monadmin: { password: monpass, roles: ROLE_ADMIN }
 
  firewalls:
    admin:
      pattern: .*
      form_login: true
      anonymous: true
 
  access_control:
      - { path: /admin/.*, role: ROLE_ADMIN }

Et maintenant, si vous essayez d’accéder à l’url :

http://sandbox.local/admin/

Vous êtes redirigés vers l’url:

http://sandbox.local/login/

qui se termine en 404! Jusqu’ici c’est normal.

Symfony2 par défaut, utilise 3 urls pour la gestion de l’authentification :

• login
• login_check
• logout

Nous allons donc les rajouter dans notre routing.yml tout simplement. Attention de bien les mettre au début, histoire d’éviter tout conflit avec une autre de vos règles.

_security_login:
  pattern: /login
  defaults: { _controller: AdminBundle:Default:login }
 
_security_check:
  pattern: /login_check
 
_security_logout:
    pattern: /logout

Le login a besoin de nous pour constituer le formulaire d’identification, les 2 autres doivent seulement exister ! Les patterns des urls peuvent varier, mais il faut alors donner les nouveaux paths dans le config.yml, nous verrons ça plus tard.

Maintenant, si nous accédons à notre admin nous avons bien sûr l’exception suivante:

Method "Application\AdminBundle\Controller\DefaultController::loginAction" does not exist.

On la crée donc:

<?php
// src/Application/AdminBundle/Controller/DefaultController.php
 
namespace Application\AdminBundle\Controller;
 
use Symfony\Bundle\FrameworkBundle\Controller\Controller;
use Symfony\Component\Security\SecurityContext; // à rajouter
 
class DefaultController extends Controller
{
    public function indexAction()
    {
        return $this->render('AdminBundle:Default:index.php');
    }
 
    public function loginAction()
    {
       // get the error if any (works with forward and redirect -- see below)
      if ($this->get('request')->attributes->has(SecurityContext::AUTHENTICATION_ERROR)) {
          $error = $this->get('request')->attributes->get(SecurityContext::AUTHENTICATION_ERROR);
      } else {
          $error = $this->get('request')->getSession()->get(SecurityContext::AUTHENTICATION_ERROR);
      }
 
      return $this->render('AdminBundle:Default:login.twig', array(
          // last username entered by the user
          'last_username' => $this->get('request')->getSession()->get(SecurityContext::LAST_USERNAME),
          'error' => $error,
      ));
    }
}

Donc là, j’ai simplement récupéré le code fourni dans la doc officielle, pas de mystère non plus. Et voici la vue correspondante :

<form action="{% path "_security_check" %}" method="post">
 
  {% if error %}
	<div class="notification error png_bg">
		<div>
			{{ error }}
		</div>
	</div>
  {% endif %}
 
  <p>
      <label>Username</label>
	<input class="text-input" type="text" name="_username" value="{{ last_username }}" />
   </p>
   <p>
      <label>Password</label>
      <input class="text-input" type="password" name="_password" />
   </p>
   <p id="remember-password">
      <input type="checkbox" />Remember me
   </p>
 
   <p>
	<input class="button" type="submit" name="login" value="Sign In" />
   </p>
</form>

Là aussi, très basique mais ça vous donne l’occasion d’essayer twig ;) Ce qui compte pour le coup, c’est surtout les attributs name des input (_username et _password), et de rediriger vers /login_check

A noter que l’utilisation du tag path dans la dernière version de twig n’est plus d’actualité. C’est désormais une fonction, donc à utiliser comme ceci {{ path(‘_security_check’) }}

Alors oui, il faudrait un layout et tout, mais bon, on va aller droit à l’essentiel.

On retrouve bien notre formulaire de login maintenant, si on essaye d’accéder à notre admin ! Encore mieux, si on essaye de s’authentifier, avec le couple login/password défini au début, on obtient notre page « admin! » Et il suffit d’ajouter une dernière ligne à notre config, pour ajouter le listener manquant sur le /logout :

#app/config/config.yml
security.config:
  providers:
    main:
      users:
        monadmin: { password: monpass, roles: ROLE_ADMIN }
 
  firewalls:
    admin:
      pattern: .*
      form_login: true
      anonymous: true
      logout: true
 
  access_control:
      - { path: /admin/.*, role: ROLE_ADMIN }

Et maintenant, vous pouvez vous déloguer sur l’url :

http://sandbox.local/logout

Histoire d’illustrer un peu plus, voici une autre config qui fonctionne aussi et qui permet de ne sécuriser que l’admin:

security.config:
  providers:
    main:
      users:
        monadmin: { password: monpass, roles: ROLE_TOTO }
 
  firewalls:
    admin: { pattern: /admin/.*, form_login: true }
    login: { pattern: /login, anonymous: true, form_login: true }
    login_check: { pattern: /login_check, anonymous: true, form_login: true }
    logout: { pattern: /logout, form_login: true, logout: true }
 
  access_control:
       - { path: /admin/.*, role: ROLE_TOTO }

Il y a bien sûr, beaucoup de tuning possible, pour encoder le password par exemple, mais maintenant qu’on a la base, je vous laisse lire vraiment la doc entière cette fois-ci ;)

Maintenant que c’est fait, nous allons parler ici d’un des aspects de symfony les plus intéressant, mais aussi d’un des moins bien documenté. Pas que les forms « basiques » ne soient pas documentés, mais dès que vous voulez faire autre chose qu’un form qui représente tel quel (ou presque) un objet de la base de données, ça se complique un peu.

Je vais essayer de vous faire un petit tour d’horizon de ce qu’on peut faire avec les embedded forms.

Les forms, c’est de la POO

Vous allez me dire que tout symfony est de la POO (Programmation Orientée Objet), et vous avez raison. Mais on peut utiliser symfony sans être un expert de la POO (voire sans vraiment savoir ce que c’est), en suivant Jobeet et en comprenant que executeIndex inclut le template indexSuccess.php en cas de succès. À partir de là, on est le roi du monde.

Enfin, du monde, moins les forms. Car les forms sont – à mon sens – la partie de symfony qui est à la fois utilisée par tous les utilisateurs de symfony, et à la fois très orientée objet (les factories sont par exemple beaucoup moins utilisées …). Du coup, ça mérite quelques explications.

Tout le monde n’est pas doué en POO

Certes tout le monde n’est pas doué en POO, professionnel ou pas d’ailleurs ;) À l’inverse de JAVA où les programmeurs n’ont pas vraiment le choix, la POO est récente dans PHP et certains l’ont découvert comme un cheveu sur la soupe.

L’impression que l’on a quand on essaye de changer le comportement des embed form c’est : mais où est-ce que je peux bien faire ce que j’ai envie de faire? doBind, doUpdateObject, saveEmbeddedForms, … les choix sont multiples.

Et pour cause, les forms utilisent énormément l’héritage, et disposent donc de moultes méthodes que l’on peut surcharger, sans que ce ne soit vraiment documenté autre part que dans l’API. Si on ne comprend pas les principes de base de la POO, les forms sont une vraie galère (déjà que quand on les comprend …).

Petit rappel sur la POO sur developpez.com : Consultez au moins la partie sur l’héritage pour ceux qui sont largués.

Principales étapes de gestion des formulaires

Il faut quand même que vous ayez quelque chose à l’esprit, il y a pour moi deux principales étapes quand vous souhaitez traiter un formulaire qui vient d’être soumis :

• 1 ère étape : lier les valeurs qui sont récupérées dans la requête à l’objet Form (c’est à dire les recopier en s’assurant qu’elles sont valides et nettoyées)
• 2 ème étape : Une fois les valeurs recopiés dans le $values du formulaire (qui n’est en fait qu’un tableau de valeurs nettoyées), réaliser un traitement dessus ou sur l’objet qui en découlera (nous verrons cela par la suite)

Il est toujours bon de se demander ce que l’on veut faire exactement : agir sur les valeurs qui seront recopiées et validées dans notre form, ou alors agir sur les valeurs nettoyées et recopiées, avant qu’elles ne soient sauvegardées en base.

Première étape

Lors de la première étape de liaison/validation/recopie des valeurs de la requête dans votre formulaire (votre objet Form), vous pourrez agir sur les données avant qu’elles ne soient passées dans les validateurs, ou alors une fois qu’elles sont passées dans les validateurs.

Vous pourrez faire votre bourrin : enlever des parties de votre formulaire de la requête en vous basant sur certaines valeurs soumises.
Par exemple enlever tout un formulaire embarqué, si certaines valeurs ne sont pas saisies (c’est l’exemple qu’on trouve pas mal sur le web d’ailleurs).
Petit souci : les valeurs de la requête n’auront pas été validées/nettoyées par les validateurs, vous vous exposez donc à quelques soucis (dans le style le gars qui n’aura rempli que des espaces dans un champ texte, faudra penser à faire vous même le trim avant de vérifier la valeur …).

Deuxième étape

Lors de la deuxième étape, c’est ici que vous devrez effectuer les traitements concernant votre logique métier à proprement parler. La première étape s’est occupée de vous donner accès aux valeurs dans votre formulaire (via le tableau $values), maintenant que c’est fait vous pouvez jouer avec.

Vous voulez mettre à jour un objet qui dépend de celui que vous allez sauvegarder automatiquement, vous souhaitez insérer votre objet dans un nested set, etc etc … C’est dans cette étape que vous ferez ça.

Je sépare sciemment le processus en deux étapes, après vous pouvez le voir autrement. Les étapes étant chaînées, vous pouvez les mélanger et faire un peu de business logic à la fin de l’étape 1 par exemple, mais essayez de rester constant partout dans votre code, où vous ne saurez plus où aller voir quand il y a un souci.

Étude de cas

On va prendre ici un cas tout simple, celui d’un formulaire auto-généré par doctrine à partir d’une table de votre modèle.

Appelons notre modèle PetitSuisse. On aura donc une classe nommée PetitSuisseForm.class.php dans lib/form/doctrine/

On va vite fait faire le parcours d’héritage de cette classe :
PetitSuisseForm => BasePetitSuisseForm => BaseFormDoctrine => sfFormDoctrine => sfFormObject => BaseForm => sfFormSymfony => sfForm (ouf)

Même si quelques unes de ces classes sont vides, on comprend que ça puisse devenir un peu dur de savoir où chercher. Alors oui l’abstraction c’est bon mangez en, mais ça engendre une complexité de lecture du code non négligeable.

Les classes qui sont « à vous » et donc dans lesquelles vous pourrez surcharger des méthodes sont PetitSuisseForm et BaseFormDoctrine.

La première vous permettra de surcharger une méthode relative au formulaire du modèle PetitSuisse, la deuxième vous permettra de surcharger de manière plus globale (chacun des forms auto-générés par doctrine héritant de BaseFormDoctrine). Je parle ici de symfony 1.3+, vous n’aurez pas toutes ces classes dans les versions précédentes.

On va maintenant parler des principales méthodes que vous aurez (peut être) à surcharger. Il en existe d’autres, si celles ci ne vous vont pas, lisez le code de symfony ;-)

1 ère étape (liaison)

doBind(array $values)

C’est la méthode qui va faire appel aux validateurs pour nettoyer les valeurs de la requête avant de les placer dans le tableau des valeurs. Ce sont ensuite sur ces valeurs nettoyées que nous travaillerons. Vous pouvez ici toucher aux données brut de pomme qui sortent directement du formulaire envoyé, sans traitement préalable.

2 ème étape (sauvegarde)

doSave($con = null)

C’est cette méthode qui sera appelée (par save() ) lorsque vous demandez la sauvegarde de votre formulaire. Elle se charge de mettre à jour votre objet avec les valeurs du form en appelant updateObject (qui appelera doUpdateObject que nous verrons par la suite).
Si vous souhaitez changer le processus de sauvegarde, ajouter par exemple l’appel d’une vos méthodes à chaque sauvegarde du formulaire (pourquoi pas garder trace dans un fichier de toutes les sauvegardes de vos formulaires), c’est ici que vous devez le faire.

processValues($values)

C’est ici que vous pouvez toucher les valeurs qui ont été nettoyées par les validateurs, avant qu’elles ne soient passées à la méthode updateObject (que nous verrons par la suite). Je n’ai pas de traitement particulier en tête, mais l’idée est là : modifier des valeurs avant qu’elles ne soient utilisées pour mettre votre objet à jour.

doUpdateObject($values)

C’est cette méthode que vous devrez surcharger si vous voulez réaliser une opération spéciale sur votre objet avant qu’il ne soit enregistré dans la base.
Par exemple, si vous voulez insérer cet objet à la fin d’un NestedSet, vous ferez ça ici. Le $values passé en paramètre est un tableau contenant les valeurs du formulaire, une fois qu’elles ont été nettoyées/vérifiées par les validateurs.

updateObjectEmbeddedForm($values)

Je pense qu’elle veut bien dire ce qu’elle veut dire. Elle va se charger d’appeler la fonction updateObject de chaque formulaire embarqué. Vous voulez agir sur le traitement des données par vos forms embarqués ? C’est par ici !

saveEmbeddedForms($con = null, $forms = null)

Allez la petite dernière pour la route : elle se charge de la sauvegarde de chacun des objets de vos forms embarqués. Fabien Potencier en donne un exemple de surcharge dans le livre « More with symfony »

Exemple d’utilisation

C’est bien beau de parler, mais un peu de concret ne fait pas de mal.

Vous trouverez un bon exemple pour comprendre le comportement des forms sur le blog de n1k0 dans son article Embedding Relations in Forms with Symfony 1.3 and Doctrine. Certes c’est en anglais, mais le code est universel ! Si vous avez des bons articles en français je suis preneur aussi.

Il existe maintenant la méthode embedRelation() et le plugin de Daniel Lohse ahDoctrineEasyEmbeddedRelationsPlugin qui font ça tout seul. Mais c’est toujours bien de comprendre ce que l’on fait ;-)

Conclusion

Je vous ai fait un petit tour d’horizon des principales méthodes que vous pouvez surcharger dans votre formulaire. Comme je l’ai dit plus haut, ce n’est pas une liste exhaustive, mais vous devriez avoir de quoi vous amuser.

J’ai juste essayé de voir tout cela d’une manière un peu plus globale et de ne pas proposer un n-ième exemple de code pour les formulaires embarqués.

Mais avec tout cet attirail, gardez à l’esprit que votre code d’action ne doit pas dépasser le classique Bind > Save! Ce qui est au traitement de votre formulaire, reste dans votre formulaire! Enjoy!

Crédit photo: http://www.flickr.com/photos/fromeyetopixel/2470999873/

Comme vous ne l’avez peut-être pas loupé si vous suiviez le trac symfony ou si vous suivez les bonnes personnes ( ;-) ) sur twitter, Symfony2 utilise maintenant Git comme gestionnaire de version et non plus Svn. Le code source a été déplacé sur github ici. Cela devrait permettre plus de participations externes (ça a déjà commencé avec pborelli, CodingFabian et denderello), vu la facilité pour cloner un repository (le repository c’est l’endroit où sont stockées le sources à distance) avec git.

Si comme moi, vous connaissez mal ou peu Git, vous pourrez commencer par lire le « Learn GitHub » qui pourra vous en apprendre un peu plus. Je vais essayer de vous donner les commandes de base pour récupérer en lecture seule ou en écriture le repository Symfony2

Récupérer le code source

Le premier cas : vous souhaitez juste récupérer le code source pour jouer avec, sans le modifier. Dans ce cas, pas besoin de créer une branche du repository principal, récupérez le juste en lecture seule. Je pars ici du principe que vous êtes sur un *nix et que Git est installé, si vous n’avez pas installé Git allez le faire de ce pas, si vous êtes sous Windows je ne peux vous aider !

Rendez-vous sur l’url du dépôt GitHub de Symfony2 et copiez l’url Read-Only qui devrait être : git://github.com/symfony/symfony.git

Vous pouvez ensuite récupérer les sources en local avec la commande

git clone git://github.com/symfony/symfony.git

Vous aurez un beau répertoire symfony avec les sources.

Effectuer des changements

Si vous voulez effectuer des changements comme un grand sur le code source de symfony, il vous faudra créer une branche. Vous devez être au préalable inscrit sur GitHub. Si vous vous rendez à l’url du dépôt GitHub de Symfony2 vous devriez avoir quelque chose comme cela en haut :

À la place de « Your fork » vous aurez la possibilité de forker. Je ne l’ai plus car j’ai déjà forké en fait ;-) Cela vous créera un repository dans votre compte GitHub auquel vous pourrez accéder comme précédemment, mais cette fois-ci en lecture/écriture. Juste l’url du repository devrait avoir changée, pour moi la commande c’est :

git clone git@github.com:vjousse/symfony.git

N’oubliez pas d’avoir généré et envoyé votre clef publique sur GitHub avant, sinon vous aurez une belle erreur. Voilà, vous pouvez maintenant effectuer vos changements et les répercuter sur le serveur comme expliqué dans le « Learn GitHub ».

Symfony2, un exemple de code

Tout d’abord il va vous falloir PHP 5.3 d’installé, si ce n’est pas le cas n’allez pas plus loin ! Ensuite il va falloir vous faire aux namespaces PHP et ses \, mais ça ça viendra avec le temps ! Pour finir, allez faire un tour sur git pour recopier un petit snippet d’ubermuda modifié par Fabien Potencier. Je vous le recopie ici :

// change this with the actual path you cloned sf2 to
$sf2_path = '~/symfony/src';
 
use Symfony\Foundation\ClassLoader;
use Symfony\Components\CLI\Application;
 
require_once $sf2_path.'/Symfony/Foundation/ClassLoader.php';
 
$loader = new ClassLoader();
$loader->registerNamespace('Symfony', $sf2_path);
$loader->register();
 
$app = new Application();
$app->run();

On ne parle pour l’instant que du composant CLI de Symfony2 qui vient juste d’être ajouté, on ne manquera pas de vous tenir au courant du reste des évolutions par la suite. À vous de jouer !

J’ai donc pris 5min de mon temps pour faire rapido presto, un petit coup de jquery pour pouvoir bouger ma debug bar!

Tout simplement, j’ai juste utilisé un script jquery qui permet d’ajouter un event de type « drag » à un élément du DOM. Un petit coup de jquery pour l’utiliser sur la debug bar:

jQuery(document).ready(function($) {
  $("#sfWebDebugBar")
    .bind("dragstart",function( event ){
      $(this).css("right","auto")
    })
    .bind("drag",function( event ){
      $(this).css({
        top: event.offsetY,
        left: event.offsetX
      });
    });
});

Il ne reste plus qu’à faire un petit filtre pour inclure ces 2 scripts automatiquement à la volée en environnement de dev. J’ai tout mis dans un petit plugin disponible plus bas mais je vous détaille le code ici pour ceux qui voudraient juste jeter un œil:

class moveWebDebugBarFilter extends sfFilter
{
  public function execute($filterChain)
  {
    if ('dev' == sfConfig::get('sf_environment'))
    {
      $response = $this->getContext()->getResponse();
 
      $response->addJavascript('/moveDebugBarPlugin/js/jquery.event.drag-1.5.min.js','last');
      $response->addJavascript('/moveDebugBarPlugin/js/moveDebugBar.js','last');
    }
 
    $filterChain->execute();    
  }
}

que l’on rajoute dans notre filters.yml

rendering: ~
security:  ~
 
# insert your own filters here
moveDebugBar:
  class: moveWebDebugBarFilter
 
cache:     ~
execution: ~

Il ne reste plus qu’à télécharger:
moveDebugBarPlugin
et à lancer un petit:

php symfony plugin:publish-asset

Le plugin est très basique et rudimentaire évidemment, il ne sera pas encore sur le site de Symfony du coup. Mais si vous avez des idées d’améliorations ou d’enrichissements hésitez pas, sait-on jamais.

Voilà le rendu en vidéo, a noter que je l’ai testé avec Symfony 1.2 et 1.3:

Crédit photo: http://www.flickr.com/photos/kaidohmaru/453263320/

Il existe sur Internet, de nombreux sites de veille sécuritaire permettant de vous maintenir au courant des dernières vulnérabilités découvertes. Si vous utilisez une application open-source (forum, blog, cms …), des visites régulières sur ces sites ou abonnement aux flux RSS, vous permettent de maintenir à jour votre application et minimiser les risques de piratages.

Mais, que vous utilisiez une application web open-source (ou non) à jour, cela n’empêche pas les tentatives d’attaques, c’est pourquoi je vous propose ici un petit script python pour effectuer vous même votre veille sécuritaire.

Cet article est la 1ère partie d’une série de 3 :

• Part 1: Configuration des logs apache, création de la BDD puis présentation et configuration du script de traitement.
• Part 2: Script de génération du flux RSS avec présentation détaillées des informations dans le flux.
• Part 3: Amélioration du script avec des expressions régulières plus poussés, rajout d’options …

Il est intéressant de noter que la Partie 1 est la plus importante, les 2 autres parties pouvant être réalisées sans attendre la suite de l’article si vous savez programmer.

Logs apache, BDD & script de traitement

Configuration des logs apache

Ce script de veille se base sur les fichiers de logs apache, il faut donc vous assurer dans un premier temps que les directives de logs sont bien renseignées au niveau de votre configuration.
L’article ne portant pas sur la configuration d’apache, je ne vais pas m’étendre dessus, voici donc les lignes nécessaires à la génération des logs.

LogFormat %V %{canonical}p %h %{X-Forwarded-For}i %{PHPSESSID}C %t \"%r\" %gt;s %b \"%{Referer}i\" \"%{User-Agent}i\"
ErrorLog /var/log/apache/my_error_log

Ceci est un exemple de format de log, vous pouvez le modifier sans problème :

• %V: Nom du serveur
• %{canonical}p: port
• %h: IP du visiteur
• %{X-Forwareded-for}i: IP du proxy
• %{PHPSESSID}C: ID de session (pratique pour retracer le chemin d’un pirate potentiel)
• %t: Date
• %r: Requête
• %>s: Status de la requête
• %b: Taille de la requête
• %{Referer}i: Referer (lien précédent)
• %{User-Agent}i: Informations sur le navigateur du visiteur

Pour plus d’infos, je vous invite à consulter la documentation officielle concernant les directives logs d’apache.
Une fois votre fichier modifié, n’oubliez pas de le recharger. Un simple reload doit normalement suffire.

/etc/init.d/apache2 reload

Création de la BDD MySQL

Les informations traitées par le script seront enregistrées en BDD pour pouvoir garder une trace, voici le code SQL pour la création des tables concernées.

--
-- Création de la table des attaques potentielles recensées
--
 
CREATE TABLE `veille_vuln` (
	`id_vuln` BIGINT(20) UNSIGNED NOT NULL AUTO_INCREMENT,
	`ip` VARCHAR(15),
	`url` text,
	`log` text,
	`temps` datetime,
	`id_type` tinyint(3) UNSIGNED,
	PRIMARY KEY (`id_vuln`),
	UNIQUE KEY (`ip`,`url`(150),`log`(150),`temps`,`id_type`)
) ENGINE=MyISAM DEFAULT CHARSET utf8;
 
--
-- Création de la table des types d'attaques surveillées
--
 
CREATE TABLE `veille_vuln_type` (
	`id_type` tinyint(3) UNSIGNED NOT NULL DEFAULT '0',
	`nom` VARCHAR(45),
	`link` VARCHAR(250),
	PRIMARY KEY (`id_type`)
) ENGINE=MyISAM DEFAULT CHARSET utf8;
 
--
-- Insertion des types de vulnérabilités surveillées
--
 
INSERT INTO `veille_vuln_type` (`id_type`, `nom`, `link`) VALUES 
('1', 'XSS', 'http://fr.wikipedia.org/wiki/Cross_site_scripting'),
('2', 'Unicode', ''),
('3', 'Include', ''),
('4', 'SQL Injection', 'http://fr.wikipedia.org/wiki/Injection_SQL'),
('5', 'Mot sensible', '');

Script veille-secu

Une fois les logs apache configurés et la BDD créée, nous allons nous attaquer au script de traitement.
En début de script, appel des différentes librairies nécessaires.

#!/usr/bin/python
 
# Importation des librairies necessaires
import re, cgi, time, MySQLdb, sys
from getopt import getopt,GetoptError

Ensuite, la partie à configurer pour :

• Effectuer la connexion à la BDD
• Indiquer le fichier pointer
• Gérer vos expressions régulières.

Le fichier pointer va vous permettre de conserver la dernière ligne de logs traitée par le script afin de ne pas repasser sur tout le fichier et utiliser des ressources mémoires inutilement.
Juste après ces infos, deux bloc d’expressions régulières qui permettront de traiter la ligne de log pour la découper puis de détecter une éventuelle tentative d’attaque.

#---------------------------------#
#	PARTIE A CONFIGURER
#---------------------------------#
 
# Declaration des variables generales (chemin absolu)
file_pointer = '/path/to/your/pointer'
 
# Declaration des variables de connexion a la BDD MySQL
bdd_host	= '127.0.0.1'
bdd_user	= 'mon_user'
bdd_pass	= 'mon_pass'
bdd_db		= 'ma_bdd'
 
# Declaration des regexp de traitement des logs
pattern_ip 	= re.compile('[0-9]{1,3}\.[0-9]{1,3}\.[0-9]{1,3}\.[0-9]{1,3}')
pattern_date 	= re.compile('[0-9]{2}\/...\/[0-9]{4}:[0-9]{2}:[0-9]{2}:[0-9]{2}')
pattern_url 	= re.compile('(GET|POST|PUT|DELETE|HEAD|PROPFIND|LOCK|OPTIONS)\ [^ ]*\ ')
 
# Declaration des regexp de detection d'attaques potentielles
p_faille_xss 	=  re.compile('((\%3C)|<)[^\n]+((\%3E)|>)', re.IGNORECASE)
p_faille_unicode = re.compile('\.exe|\/syntaxe\/winnt\/system32\/', re.IGNORECASE)
p_faille_inc 	= re.compile('(http|ftp):\/\/|\/etc\/(passwd|shadow)|\/(sbin|bin)\/|\.\.\/', re.IGNORECASE)
p_faille_sql 	= re.compile('(\ |%20)(union|or)(\ |%20)', re.IGNORECASE)
p_faille_word 	= re.compile('(root|htaccess|passwd|\.log|\.conf)', re.IGNORECASE)

La suite du fichier concerne le traitement des options et des arguments qu’il est possible de passer au script, ici une seule option « –help » et un seul argument « le fichier ». Nous verrons dans la partie 3 des cas beaucoup plus poussés pour faire de ce script un mini IDS et limiter au maximum les faux-positifs.

#-----------------------------------------------------#
#	NE PAS MODIFIER CETTE PARTIE
#-----------------------------------------------------#
 
# Declaration des options et arguments
optionmap = [
	["-h", "--help", "Affiche l'aide"],
	["-f", "--logfile", "Specifie le fichier de log a traiter (chemin absolu)"],
]
 
# Traitement des options et arguments
args = []
params = []
try:
	args, params = getopt(sys.argv[1:], "".join([o[0][1] for o in optionmap]), \
		[x[2:] for x in reduce(lambda x,y: x+y, [z[1:-1] for z in optionmap])])
	args = [a for a,b in args]
 
	log = 0
	mode = None
 
	for option in ["--help", "-h"]:
		if option in args:
			args.remove(option)
			mode = "help"
 
	for option in ["--logfile", "-f"]:
		if option in args:
			args.remove(option)
			log = params.pop(0)
 
# Traitement des errreurs
except GetoptError, e:
	sys.stderr.write("option invalide: ")
	sys.stderr.write(str(e)+"\n")
	mode = "help"
 
# Affichage de l'aide si le mode "help" est defini ou si le fichier de log est equivalent a 0
if mode == "help" or log == 0:
	sys.stderr.write("Syntax: veille-secu \n")
	for m in optionmap:
		sys.stderr.write(m[0] + "\t" + m[1] + "   \t: " + m[-1] + "\n")
		for o in m[2:-1]:
			sys.stderr.write("\t" + o + "\n")
	sys.exit(1)

Connexion à la BDD avec les informations renseignées en début de fichier.

# Connexion a la BDD
cnx = MySQLdb.connect(
	host	= bdd_host,
	user	= bdd_user,
	passwd	= bdd_pass,
	db		= bdd_db
)
c = cnx.cursor()

Comme expliqué précédemment, nous allons ici vérifier l’existence et la valeur du pointer pour ne pas reprendre le fichier complet puis ouvrir le fichier de log au niveau du pointer.
Nous verrons en fin d’article la possibilité de remettre ce pointer à 0 si vous avez un logrotate activé sur votre serveur.

# Vérification du pointer pour ne pas reprendre le fichier a 0
pointer = 0
verif = open(file_pointer,'r')
for num in verif.xreadlines():
	pointer = int(num)
verif.close()
 
# Ouverture du fichier de log et vérification du pointer
logapache = open(log,'r')
if pointer > 0:
	logapache.seek(pointer, 0)

Traitement du fichier ligne par ligne. A chaque ligne de log, le script va analyser l’url et déterminer, en fonction des regexp définies plus haut, si la requête est une tentative d’attaque ou non.
Dans cet exemple du script, les regexp de détection sont assez basiques, dans la partie 3 nous élaborerons des techniques plus poussées.

Si une attaque potentielle est détectée, alors elle sera enregistrée en BDD pour générer par la suite le flux RSS ou tout simplement consulter les différents enregistrements à partir d’une interface web comme nous le verrons dans la partie 2 de l’article.

# Traitement du fichier ligne par ligne
k=1
for line in logapache.xreadlines():
	# Initialisation des Variables
	data_ip 		= 'NULL'
	data_date		= 'NULL'
	data_url		= 'NULL'
	# IP
	field_ip = pattern_ip.search(line)
	if field_ip:
		data_ip = field_ip.group()
	# DATE
	field_date = pattern_date.search(line)
	if field_date:
		tmp_date = time.strptime(field_date.group(), "%d/%b/%Y:%H:%M:%S")
		data_date = time.strftime("%Y-%m-%d %H:%M:%S", tmp_date)
	# URL
	field_url = pattern_url.search(line)
	if field_url:
		data_method,data_url = (field_url.group().strip().split() + ['0','0'])[:2]
		# ATTAQUES POTENTIELLES
		field_faille_xss 		= p_faille_xss.search(data_url)
		field_faille_unicode 	= p_faille_unicode.search(data_url)
		field_faille_inc 		= p_faille_inc.search(data_url)
		field_faille_sql 		= p_faille_sql.search(data_url)
		field_faille_word 		= p_faille_word.search(data_url)
		if field_faille_xss or field_faille_unicode or field_faille_inc or field_faille_sql or field_faille_word:
			if field_faille_xss:
				faille_type = '1'
			elif field_faille_unicode:
				faille_type = '2'
			elif field_faille_inc:
				faille_type = '3'
			elif field_faille_sql:
				faille_type = '4'
			elif field_faille_word:
				faille_type = '5'
			c.execute("INSERT IGNORE veille_vuln (ip, url, log, temps, id_type) VALUES (%s, %s, %s, %s, %s)", (data_ip, data_url, line, data_date, faille_type))
			k = k + 1

Une fois le fichier traité, nous allons successivement :

• Fermer la connexion MySQL
• Récupérer la position du pointer
• Fermer le fichier de log

# Fermeture de la connexion MySQL
cnx.commit()
c.close()
 
# Recuperation position actuelle du pointer puis fermeture du fichier
eof = logapache.tell()
logapache.close()
 
# Sauvegarde du pointer en cours
new_verif = open(file_pointer,'w')
new_verif.write(str(eof))
new_verif.close()

Si vous n’avez qu’un seul fichier de log que vous videz de temps en temps, il suffit de mettre en tâche cron le script veille-secu, mais si vous utilisez un logrotate, il faudra rajouter une étape.

Ci-dessous, on fait tourner le script toutes les 5min.

*/5	*	*	*	*	/usr/sbin/veille-secu -f /path/to/your/apache_log

Dans le cas d’une utilisation de logrotate, dans votre fichier de conf, on va ajouter au niveau de postrotate une commande permettant de remettre le pointer à 0 à chaque rotation de log.

postrotate
	if [ -f /var/run/apache2.pid ]; then
		/etc/init.d/apache2 restart > /dev/null
		echo 0 > /path/to/your/pointer
	fi
endscript

Voilà, j’espère que ce premier article vous plaira sinon Tim risque de pas être content et il ne voudra plus venir me voir ^^

En ce qui nous concerne, avec les annonces faites lors de la dernière Symfony Conference Live, il faut bien commencer à se lancer dans Doctrine. Et c’est l’occasion de découvrir petit à petit cet ORM qui change beaucoup de Propel, pas toujours en bien à mon goût, mais il y a quand même des choses très bien pensées.
En parcourant la doc, je suis donc tombé sur un behavior que j’ai trouvé fort intéressant: Geographical.

Je me suis donc laissé tenté par un test de celui-ci!

Le principe est simple, il rajoute 2 champs à notre table, latitude et longitude, qui outre le fait de donner les coordonnées GPS de notre adresse, pouvant ainsi alimenter une googlemap, permet également de faire des calculs de distance (à vol d’oiseau évidemment).
Et d’ailleurs apparemment, c’est sa seule fonction, car le remplissage des champs est à notre charge. Mais ça reste une fonctionnalité intéressante.

On se lance donc dans une application à un projet, symfony bien évidemment, avec une table classique d’adresse avec le behavior de déclaré.
Voici notre schema.yml

adresses:
  actAs: [ Geographical]
  tableName: adresses
  columns:
    aid: { type: integer(4), primary: true,  autoincrement: true }
    adresse1: { type: string(255), notnull: true }
    adresse2: { type: string(255) }
    cp: { type: string(5), notnull: true }
    ville: { type: string(100), notnull: true }

Ce qui donne en base une fois notre table créé:

+------------+--------------+------+-----+---------+----------------+
| Field      | Type         | Null | Key | Default | Extra          |
+------------+--------------+------+-----+---------+----------------+
| aid        | int(11)      | NO   | PRI | NULL    | auto_increment |
| adresse1   | varchar(255) | NO   |     | NULL    |                |
| adresse2   | varchar(255) | YES  |     | NULL    |                |
| cp         | varchar(5)   | NO   |     | NULL    |                |
| ville      | varchar(100) | NO   |     | NULL    |                |
| latitude   | double       | YES  |     | NULL    |                |
| longitude  | double       | YES  |     | NULL    |                |
+------------+--------------+------+-----+---------+----------------+

Maintenant que les bases sont posées, on va créer une petite classe rapide qui va nous permettre d’alimenter les champs latitude et longitude de notre table. Pour cela on va se servir de l’inévitable googlemap. Il vous faudra pour cela une clé pour utiliser leur API.

class Geoloc
{
  protected 
    $adr = null,
    $key = null,
    $url = null,
    $context = null,
    $format = null,
    $x = null,
    $y = null;
  }
 
  public function execute()
  {
    // On utilise un stream_context pour avoir la main sur certaines options plus facilement, comme le timeout de notre connexion
    $context = stream_context_create(array(
      'http' => array(
        'method'  => 'GET',
        'header' => "Content-type: application/x-www-form-urlencoded\r\n",
        'timeout' => 5,
      ),
    ));
 
    // Google n'autorise que les requêtes en GET, on construit donc notre liste de paramètre prêt à emploi
    $param = http_build_query(array(
          'q' => $this->adr,
          'output' => $this->format,
          'oe' => 'utf8',
          'sensor' => 'false',
          'key' => $this->key
    ));
 
    $content = file_get_contents($this->url.'?'.$param, false, $context);
    if ($content)
    {
      // Le traitement est prévu ici pour du csv
      $retour = explode(',',$content);
 
      // Si le retour est bon, on récupère les coordonnées
      if ($retour[0] == '200')
      {
        $this->x = $retour[2];
        $this->y = $retour[3];
 
        return array($this->x,$this->y);
      }
    }
 
    return false;
  }
 
  public function getX()
  {
    return $this->x;
  }
 
  public function getY()
  {
    return $this->y;
  }
}

Voilà, il suffit de placer cette classe dans un dossier Lib de Symfony, où on bon vous semble. Maintenant on va créer dans notre fichier adresses.class.php 2 méthodes:
- la première qui lancera la mise à jour des champs via google
- la deuxième qui automatisera cette mise à jour, lors d’une nouvelle insertion et seulement dans ce cas. (et non pas à chaque mise à jour)

public function updateCoordonnees()
{
    $completeAdr = $this->;adresse1.' '.(!empty($this->adresse2)?$this->adresse2.' '.:'').$this->cp.' '.$this->ville; // Ajout adresse2 seulement si non vide
    $geoloc = new Geoloc($completeAdr,'maCleGoogleMap');
 
    if ($data = $geoloc->execute())
    {
      $this->latitude = $data[0];
      $this->longitude = $data[1];
    }
}
 
/**
 *  Méthode appelé avant l'insertion d'un nouvel élément. Elle est à surcharger au besoin.
 */
public function preInsert($event)
{
  $this->updateCoordonnees();
}

Et voilà, avec un fichier de fixtures.yml du genre:

adresses:
  adresse_1:
    adresse1: 165 avenue du prado
    cp: 13008
    ville: Marseille
  adresse_2:
    adresse1: 7 rue de verdun
    cp: 13005
    ville: Marseille
  adresse_3:
    adresse1: 57 Bd Romain Rolland 
    cp: 13010
    ville: Marseille
  adresse_4:
    adresse1: Route de Gemenos 
    cp: 13400
    ville: Aubagne

En le chargeant via symfony, on obtient en base:

select * from adresses ;
+-----+----------------------+----------+-------+-----------+------------+-----------+
| aid | adresse1             | address2 | cp    | ville     | latitude   | longitude |
+-----+----------------------+----------+-------+-----------+------------+-----------+
|   1 | 165 avenue du prado  | NULL   | 13008 | Marseille | 43.2783515 | 5.3883703 |
|   2 | 7 rue de verdun      | NULL     | 13005 | Marseille |  43.296542 | 5.3958405 |
|   3 | 57 Bd Romain Rolland | NULL     | 13010 | Marseille | 43.2774579 | 5.4202946 |
|   4 | Route de Gemenos     | NULL     | 13400 | Aubagne  | 43.2975544 | 5.5888222 |
+-----+----------------------+----------+-------+-----------+------------+-----------+

Un petit bout de code dans une action, rapidement pour tester:

public function executeTest(sfWebRequest $request)
{
    $adr1 = Doctrine::getTable('adresses')->find(1);
    $adr2 = Doctrine::getTable('adresses')->find(2);
    echo number_format($adr1->getDistance($adr2, true),2,',','').'Km'; // Par défaut, retourne en miles, il faut mettre le 2e paramètre à true pour avoir le résultat en km
 
    return sfView::NONE;
}

Et on obtient la distance en km entre nos 2 premières adresses. (Ici la distance entre chez moi et mon boulot :p)
Comme l’indique la doc, on peut aller plus loin, en récupérant pour une adresse donnée, les N adresses les plus proches, ce qui peut donner lieu à des fonctionnalités très intéressantes:

public function executeTest2(sfWebRequest $request)
{
    $adr1 = Doctrine::getTable('adresses')->find(1);
    $q = $adr1->getDistanceQuery();
    $result = $q->orderby('miles asc') // On les trie par distance
              ->addWhere($q->getRootAlias(). '.aid != ?',$adr1->aid) // On exclut l'adresse de référence
              ->execute();
 
    foreach ($result as $res)
    {
       echo $res->cp . " - " . $res->kilometers . "<br/>";
    }
 
    return sfView::NONE;
  }

A noter que le code du behavior est très simple en fait, il ajoute juste une formule mathématique pour ces calculs de distance. Mais c’est ce genre de petites fonctionnalités qui me font apprécier la découverte de Doctrine!

Après avoir définitivement abandonné TinyMCE, car trop usine à gaz et n’en faisant qu’à sa tête, j’ai essayé nicedit comme je vous l’avais signalé dans un bon plan de la semaine. Malheureusement, il reste un peu juste pour certains besoins.
Sur les conseils de Sam, je me suis donc relancé dans une vieille connaissance, FCKEditor, un des plus vieux RTE avec TinyMCE.

S’il est a noté de nets progrès, il fait encore un peu usine à gaz (mais moins que TinyMCE quand même) et je le trouve particulièrement moche, mais c’est un détail qui peut se modifier, donc on va le mettre de côté pour l’instant ;)

Un des impératifs par contre, c’est la personnalisation et donc la création de plugin permettant de rajouter des boutons avec des fonctionnalités que l’on aura déterminer nous même. Et vu les difficultés que j’ai pu rencontrer pour créer mon premier, je me suis dis que ca valait bien quelques explications. Dans un souci de clarté, je ne détaillerai pas l’installation de fck, je vous invite à faire un tour sur leur site pour ça.

Première chose quand on veut créer un plugin fck, créer son arborescence, dans editor/plugins. Ici, on va créer un plugin qui nous permettra de rajouter un bouton à notre toolbar qui lancera une fenêtre nous permettant de faire un peu ce qu’on veut, en l’occurrence dans notre cas, afficher une liste des pages de notre gestionnaire de contenus symfony afin de pouvoir insérer des liens internes entre elle.

Dans notre nouveau dossier, vous créez donc un fichier plugin.js avec à l’intérieur:

// Ici je crée une action FCK qui s'appelle Internlink, et qui chargera le fichier test.html (qui sera au même niveau que ce fichier) lors de son appel
FCKCommands.RegisterCommand('Internlink', new FCKDialogCommand('Internlink','Ajout lien interne',FCKConfig.PluginsPath+'internlink/test.html', 300, 300 ));
 
// Ici je crée un bouton pour la toolbar auquel j'associe l'action précédemment définie
FCKToolbarItems.RegisterItem( 'Internlink', new FCKToolbarButton( 'Internlink', 'Lien interne', null, FCK_TOOLBARITEM_ICONTEXT, true, true, 1 ) ) ;

Ensuite on enchaine avec le template de notre popup qu’on a appelé test.html plus haut (on le met bien où on veut mais j’ai définis au-dessus de le mettre au même niveau):

<!DOCTYPE html PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN" "http://www.w3.org/TR/html4/loose.dtd">
<html>
<head>
  <meta http-equiv="Content-Type" content="text/html; charset=UTF-8">
  <script type="text/javascript" src="http://ajax.googleapis.com/ajax/libs/jquery/1.3.2/jquery.min.js"></script>
  <script type="text/javascript">
    // Cette partie est nécessaire pour pouvoir utiliser les fonctions de fck à l'intérieur de notre popup 
    var oEditor = window.parent.InnerDialogLoaded();
    var FCKConfig = oEditor.FCKConfig;
    var dialog = window.parent;
    document.write('<script src="' + FCKConfig.BasePath + 'dialog/common/fck_dialog_common.js" type="text/javascript"><\/script>');
    dialog.SetOkButton(true); // Par défaut, seul le bouton annuler est affiché, on rajoute le bouton ok	
 
    // Maintenant on fait bien ce qu'on veux, ici j'ai décidé de récupérer en AJAX, une liste en JSON de toutes mes pages et d'alimenter ma selectbox avec
    jQuery(document).ready(function(){
      $.getJSON("/content/selectJson",{}, function(j){
        var options = '';
        for (var i = 0; i < j.length; i++) {
          options += '<option value="' + j[i].optionValue + '">' + j[i].optionDisplay + '</option>';
        }
        $("select#intern-link").html(options);
      })
    });
 
    // Puis on surdéfinit une fonction Ok qui est appelé par fck quand on appuye sur le bouton ... ok
    function Ok()
    {
      // Maintenant on utilise fck pour rajouter du contenu à notre RTE. Ici je rajoute simplement les valeurs de mes 2 champs définis dans mon HTML ci-dessous
      oEditor.FCK.InsertHtml( '<a href="'+ jQuery('#intern-link').val() +'" class="extern">'+ jQuery('#intern-label').val() +'</a>' );
      return true; // Il faut renvoyer true pour fermer la popup
    }
</script>
</head>
<body>
	<div id="add-intern-link">		
		<p>
			<label for="intern-link">Lien interne</label>
			<select id="intern-link" name="intern-link">
			</select>						
		</p>
		<p>
			<label for="intern-label">Label</label>
			<input type="text" id="intern-label" name="intern-label" />						
		</p>
	</div>
</body>
</html>

Il ne reste plus qu’à charger notre plugin dans notre conf:

FCKConfig.Plugins.Add( 'internlink' ) ;

et ajouter le bouton à notre toolbar comme par exemple:

FCKConfig.ToolbarSets["nice"] = ['Internlink'];

et on obtient:

On a maintenant accès à toutes nos pages, et un clic sur ok, nous rajoutera un lien dans notre contenu avec le label renseigné.

Il ne reste plus qu’à adapter à vos besoins ces petits bouts de codes!

Alors bien sûr, la solution radicale, c’est de réduire le nombre de colonnes, mais souvent le client, il les veut ses colonnes! La 2e solution est de supprimer ce bloc de filtre. On fait ça très simplement dans le generator.yml:

filter:
  class: false

Cependant, il arrive quand même que le filtrage soit nécessaire mais bien souvent, seulement 2 ou 3 valeurs. J’ai donc décidé de prendre le taureau par les cornes et faire la modification dont je rêve depuis longtemps, passer ce bloc de filtre, au dessus du tableau! Pour ce faire, j’ai modifié 2 fichiers. Tout d’abord, le fichier _filters.php qu’il faudra rajouter dans le dossier templates de vos modules visés:

<div class="sf_admin_filter">
 
	<div class="content_filter">
  <?php if ($form->hasGlobalErrors()): ?>
    <?php echo $form->renderGlobalErrors() ?>
  <?php endif; ?>
 
 
  <form action="<?php echo url_for('produits_collection', array('action' => 'filter')) ?>" method="post">
	  <?php foreach ($configuration->getFormFilterFields($form) as $name => $field): ?>
	  <div class="bloc_filter">
        <?php if ((isset($form[$name]) && $form[$name]->isHidden()) || (!isset($form[$name]) && $field->isReal())) continue ?>
          <?php include_partial('produits/filters_field', array(
            'name'       => $name,
            'attributes' => $field->getConfig('attributes', array()),
            'label'      => $field->getConfig('label'),
            'help'       => $field->getConfig('help'),
            'form'       => $form,
            'field'      => $field,
            'class'      => 'sf_admin_form_row sf_admin_'.strtolower($field->getType()).' sf_admin_filter_field_'.$name,
          )) ?>
    </div>
    <?php endforeach; ?>
 
     <?php echo $form->renderHiddenFields() ?>
     <?php echo link_to(__('Reset', array(), 'sf_admin'), 'produits_collection', array('action' => 'filter'), array('query_string' => '_reset', 'method' => 'post')) ?>
     <input type="submit" value="<?php echo __('Filter', array(), 'sf_admin') ?>" />
  </form>
  </div>
</div>

Au final, j’ai simplement supprimé le tableau, par défaut et mis chaque widget dans un div. On obtient donc quelque chose qui change pas vraiment la donne pour l’instant:

Mais en lui appliquant un peu de css:

div#sf_admin_bar {
	float:none;
	margin: 0;
}
 
#sf_admin_bar .sf_admin_filter form div.bloc_filter {
	display:inline;
	padding:0 20px 0 0;
}
 
div#sf_admin_container #sf_admin_bar label {
	display:inline;
	float:none;
	padding:0;
}

On commence à approcher de ce que l’on souhaite:

Maintenant, on habille un peu la chose, histoire de gagner en clarté:

#sf_admin_bar .sf_admin_filter {
	background-color:#FFF;
	margin:12px 0;
}
 
#sf_admin_bar .sf_admin_filter .content_filter {
	border:1px solid #DDDDDD;
	padding:5px;
}

Pour obtenir finalement:

Un dernier détail, le filtre « référence » avec sa colonne « is_empty » casse un peu notre rendu. Personnellement, je ne me sers pas de cette checkbox, on va donc redéfinir notre filtre pour la supprimer dans lib/filters/MonModuleFilters.class.php:

public function configure()
  {
    $this->widgetSchema['reference'] = new sfWidgetFormFilterInput(array(
      'template' => '%input%'
    ));
  }

Et voilà, une jolie barre de recherche beaucoup plus du goût des clients en général :)

Alors bien sûr, cette solution ne fonctionne qu’avec un nombre limité de filtre, sinon on aurait un rendu un peu moins visuel, mais je pense que ça reste toujours mieux que 2 blocs qui se chevauchent.