Dans cette publication, nous allons voir comment mettre en place un système d’identification basé sur le plugin sfDoctrineGuard. Pour que cela fonctionne, il vous faut également l’excellente librairie jquery. Dans cette article, je n’aborde pas l’installation du plugin, ni l’installation et le chargement de jquery.

Nous allons commencer par générer un nouveau module « user » dans notre projet avec la commande ci-dessous:

./symfony generate:module frontend user

Nous allons dès maintenant modifier notre module « user » pour y mettre notre propre code. Pour cela nous allons inclure la classe « BasesfGuardAuthActions » dans notre classe et changer l’extends:

require_once(sfConfig::get('sf_plugins_dir').'/sfDoctrineGuardPlugin/modules
/sfGuardAuth/lib/BasesfGuardAuthActions.class.php');

class userActions extends BasesfGuardAuthActions
{
  ...
}

J’avais un problème a résoudre lors de l’affichage de la page signin lors de l’appel d’une page protégée. J’ai choisi d’y mettre uniquement une information utilisateur lui indiquant de s’identifier avec le formulaire. J’ai créé le fichier signinSuccess.php dans le dossier templates.

Nous allons maintenant monter le formulaire d’identification dans un component.

class userComponents extends sfComponents
{
  public function executeSignin(sfWebRequest $request)
  {
    $class = sfConfig::get('app_sf_guard_plugin_signin_form', 'sfGuardFormSignin');
    $this->form = new $class();
  }
}

template: _signin.php

<div id="form_message">&nbsp;</div>
<form id="guard" action="<?php echo url_for('@sf_guard_signin') ?>" method="post">
  <?php echo $form->renderHiddenFields(); ?>
  <label>Utilisateur:</label>
  <?php echo $form['username']->render(); ?>
  <label>Mot de passe:</label>
  <?php echo $form['password']->render(); ?>
  <?php echo $form['remember']->render(array('id' => 'remember')); ?>
  Se souvenir de moi

  <input type="submit" value="S'identifier" />
  <a href="<?php echo url_for('@sf_guard_password') ?>">Mot de passe oublié ?</a>
</form>

<script type="text/javascript">
  $('#guard').submit(function() {
    $.post("<?php echo url_for('@sf_guard_signin'); ?>", $('#guard').serialize(), function(response) {
      switch(response.status) {
        case 'success':
        $('#form_message').html(response.message);
        $(location).attr('href',response.url);
        break;
        case 'failure':
        $('#form_message').html(response.message);
        $('#form_message').show();
        break;
      }
    }, 'json');
    return false;
  });
</script>

Nous allons rajouter un peu de css pour cacher notre zone « form_message »:

#form_message {
  display: none;
  font-weight: bold;
  color: red;
}

Prochaine phase, désactiver les routes et y mettre nos propres paramètres. Nous allons pour cela toucher 3 fichiers:

app.yml

all:
  sf_guard_plugin:
    routes_register: false

routing.yml

sf_guard_signin:
  url:      /login
  param:    { module: user, action: signin }

sf_guard_signout:
  url:      /logout
  param:    { module: user, action: signout }

sf_guard_password:
  url:      /password
  param:    { module: user, action: password }

settings.yml

all:
  .actions:
    login_module:           user
    login_action:           signin
        
    secure_module:          user
    secure_action:          secure

La dernière phase de cette réalisation est l’implémentation de notre fonction signin. Voici le code utilisé pour un dialogue ajax:

class userActions extends BasesfGuardAuthActions
{
  public function executeSignin($request)
  {
    $user = $this->getUser();
    if ($user->isAuthenticated())
    {
      return $this->redirect('@homepage');
    }

    if($request->isMethod('post') && $request->isXmlHttpRequest())
    {
      $class = sfConfig::get('app_sf_guard_plugin_signin_form', 'sfGuardFormSignin');
      $form = new $class();
      $form->bind($request->getParameter($form->getName()));
      if ($form->isValid())
      {
        $values = $form->getValues();
        $user->signin($values['user'], array_key_exists('remember', $values) ? $values['remember'] : false);
        $signinUrl = sfConfig::get('app_sf_guard_plugin_success_signin_url', $user->getReferer($request->getReferer()));

        return $this->renderText(json_encode(array('status' => 'success', 'url' => $signinUrl)));
      }
      else
      {
        return $this->renderText(json_encode(array('status' => 'failure','message' => 'Identification incorrecte')));
      }
    }

    $this->getResponse()->setStatusCode(401);
  }
}

Il nous reste plus qu’à insérer notre component dans notre layout ou notre template:

<?php if (!$sf_user->isAuthenticated()): ?>
<?php include_component('user', 'signin'); ?>
<?php endif; ?>

L’implémentation est terminée. J’espère que ce petit article vous permettra de mettre en place un formulaire à la web 2.0 😉

Il y a souvent des questions concernant la récupération de l’id utilisateur lorsque l’on utilise sfDoctrineGuardPlugin. En faite vous avez le choix entre deux possibilités. La première va lancer une requête dans la base de données, la seconde va récupérer l’id dans la session courante.

Exemple 1:

$this->user_id = $this->getUser()->getGuardUser()->getId();

Exemple 2:

$this->user_id = $this->getUser()->getAttribute(
'user_id', null, 'sfGuardSecurityUser');

Nous allons maintenant créer une nouvelle fonction dans notre classe myUser permettant d’accéder directement à notre id:

class myUser extends sfGuardSecurityUser
{
  public function getId()
  {
    return $this->getAttribute('user_id', null, 'sfGuardSecurityUser');
  }
}

Après avoir créer cette nouvelle fonction, vous avez accès à votre id en exécutant le code suivant:

$this->user_id = $this->getUser()->getId();

Voilà pour la petite mise en place.

Pour compléter mon article précédent De la culture au language, j’ai réalisé un filtre permettant de faire une re-direction sur la page d’accueil selon le langage du navigateur web. Si ce langage n’est pas disponible, le navigateur sera automatiquement redirigé vers la langue par défaut.

Nous allons commencer par définir quelques paramètres dans le fichier app.yml du dossier config:

all:
  language:
    homepage_route:   home_language
    allowed:
      fr: fr_CH
      de: de_CH
      en: en_US

Nous allons également définir la route par défaut inscrite dans le paramètre « homepage_route »:

home_language:
  url:  /:sf_language
  param:  { module: main, action: index }

Nous poursuivons par la mise en place du filtre. Ajoutons le fichier nommé « languageFilter.class.php » dans le dossier lib de votre application:

class languageFilter extends sfFilter
{
  public function execute($filterChain)
  {
    // Execute this filter only once
    if ($this->isFirstCall())
    {
      $is_correct_url = true;
      
      $context = $this->getContext();

      $language = $context->getRequest()->getParameter('sf_language');
      
      $language_allowed = sfConfig::get('app_language_allowed');

      // Si la langue n'est pas dans l'url
      if($language == NULL)
      {
        // Récupération de la langue préférée du navigateur
        $language = substr($context->getRequest()->getPreferredCulture(), 0, 2);
        
        // Nous contrôlons si cette langue est dans la liste des langues valident
        // Si ce n'est pas le cas, nous prenons la langue par défaut
        if(!array_key_exists($language, $language_allowed))
        {
          $language = substr(sfConfig::get('sf_default_culture'), 0, 2);
        }
        $is_correct_url = false;
      }
      
      // Si la langue n'est pas définie comme active
      // Nous redirigeons sur la page erreur 404
      if(!array_key_exists($language, $language_allowed))
      {
        $module = sfConfig::get('sf_error_404_module', 'default');
        $action = sfConfig::get('sf_error_404_action', 'error404');
        $context->getController()->forward($module, $action);
        exit;
      }
      else
      {
        // Nous récupérons la culture valide selon le code de langue
        $user_culture = $language_allowed[$language];

        // Si la culture est différente de la culture de session
        // Nous la changeons
        if($user_culture != $context->getUser()->getCulture())
        {
          $context->getUser()->setCulture($user_culture);
        }
        
        // Nous renseignons la valeur meta de la langue
        $context->getResponse()->addHttpMeta('content-language', $language);
        
        // Nous effectuons la redirection
        $actionname = $context->getActionName();
        if($is_correct_url == false && $actionname != 'error404')
        {
          $context->getController()->redirect(
                             sfConfig::get('app_language_homepage_route'));
        }
      }
    }
    
    // Execute next filter
    $filterChain->execute();
  }
}

Il nous suffit maintenant d’activer ce filtre en ajoutant ces lignes dans le fichier filters.yml du dossier config:

rendering: ~
security:  ~

# insert your own filters here
language:
  class:  languageFilter
  
cache:     ~
common:    ~
execution: ~

Dès à présent, si votre navigateur est en langue française, si vous tapez « http://monsite.com », vous allez être redirigé vers l’adresse « http://monsite.com/fr ». Dans le cas d’une langue non reconnue, vous obtiendrez une erreur 404.

Avec ce filtre, nous avons une solution robuste pour gérer correctement notre langue.

Bonne découverte.

Symfony ne proposant pas de système pour la gestion du langage selon la culture utilisée, j’ai cherché une solution viable. Je m’explique. Dans mon cas, un utilisateur reçoit une culture « fr_CH » pour permettre un formatage correct sur les nombres. Par contre, dans les urls du site, je désire y mettre uniquement la première partie « fr ». Je vous propose dans ce post de vous livrer ma solution. J’ai pour cela utilisé le système d’Event, qui au passage est vraiment un truc super. Je vous conseille vraiment de découvrir cette petite merveille.

Pour débuter, j’ai rajouté ces quelques lignes dans mon fichier myUser.class.php se trouvant dans le dossier lib de l’application:

class myUser extends sfGuardSecurityUser
{
  public function initialize(sfEventDispatcher $dispatcher, sfStorage $storage, $options = array())
  {
    $dispatcher->connect('user.change_culture', array($this, 'listenToChangeCultureEvent'));
    parent::initialize($dispatcher, $storage, $options);
  }
  
  public function listenToChangeCultureEvent(sfEvent $event)
  {
    $result = explode('_', $this->culture);
    $this->setLanguage($result[0]);
  }
  
  public function setLanguage($language)
  {
    $this->language = $language;
  }
  
  public function getLanguage()
  {
    return $this->language;
  }
}

Comme vous pouvez le voir dans ce code, je me suis connecté à l’event « user.change_culture ». Avec cette fonction, je vais scinder les deux parties de la culture pour ne garder plus que le terme « fr ».

Je voulais ensuite avoir la possibilité d’accéder au paramètre « sf_language » dans mon fichier de routing. J’ai pour cela surchargé la méthode « listenToChangeCultureEvent » de la classe « sfPatternRouting ». J’ai créé un nouveau fichier nommé « mysfPatternRouting.class.php » dans mon dossier lib (toujours dans mon app) avec le code suivant:

class mysfPatternRouting extends sfPatternRouting
{
  public function listenToChangeCultureEvent(sfEvent $event)
  {
    $result = explode('_', $event['culture']);
    $this->setDefaultParameter('sf_language', $result[0]);
    parent::listenToChangeCultureEvent($event);
  }
}

Pour charger ma classe routing, j’ai également modifié le fichier factories.yml en activant cette partie.

all:
  ...
  routing:
    class: mysfPatternRouting
    param:
      load_configuration: true
      suffix:             .
      default_module:     default
      ...

J’ai remplacé le contenu du tag class par « mysfPatternRouting » (Valeur par défaut: sfPatternRouting).

Ensuite, il suffit de vider le cache de symfony pour qu’il charge la nouvelle classe

$ ./symfony cc

Dès maintenant, on aura accès au nouveau paramètre « sf_language » dans notre fichier de routing.yml. Voici un exemple

user_index:
 url:  /:sf_language/user
 param:  { module: user, action: index }
 requirements:
   - sf_language: (?:fr|en|de)

J’espère que cette solution vous sera utile dans vos prochains développements 😛

Prérequis: L’activation du plugin sfDoctrineGuardPlugin

Dans le cadre d’un développement, je cherchais à passer à mon application en mode maintenance pour un utilisateur normal mais que le super admin puisse continuer à visualiser les pages du site. La tâche symfony n’est pas satisfaisante dans ce cas car elle verrouille complètement l’accès à celui-ci. Voici donc ma solution:

Premièrement, j’ai activé le paramètre check_lock dans le fichier settings.yml de mon application.

Path: /apps/[NomApp]/config/settings.yml

all:
  .settings:
    check_lock:             on

Pour stocker mon fichier de verrouillage, j’ai créé un dossier « lock » dans le dossier data

mkdir data/lock

Attention: ce dossier doit être en écriture

J’ai ensuite inséré le code suivant dans ProjectConfiguration

Path: /config/ProjectConfiguration.class.php

class ProjectConfiguration extends sfProjectConfiguration
{
  public function setup()
  {
    ...
  }
  
  public function getApplicationLockFile()
  {
    return sfConfig::get('sf_data_dir').DIRECTORY_SEPARATOR.
               'lock'.DIRECTORY_SEPARATOR.$this->getApplication().'.lck';
  }
}

Vient maintenant la partie contrôle de l’accès. Pour cela j’ai créé un filtre que voici

Path: /lib/isApplicationActivatedFilter.class.php

class isApplicationActivatedFilter extends sfFilter
{
  public function execute ($filterChain)
  {
    if ($this->isFirstCall())
    {
      if (sfConfig::get('sf_check_lock'))
      {
        $context = $this->getContext();
        $config = $context->getConfiguration();
        $user = $context->getUser();

        $fileLock = $config->getApplicationLockFile();
        if (file_exists($fileLock) && !$user->isSuperAdmin())
        {
          $files = array(
            sfConfig::get('sf_app_config_dir').'/unavailable.php',
            sfConfig::get('sf_config_dir').'/unavailable.php',
            sfConfig::get('sf_web_dir').'/errors/unavailable.php',
            sfConfig::get('sf_symfony_lib_dir').'/exception/data/unavailable.php',
          );
          
          foreach ($files as $file)
          {
            if (is_readable($file))
            {
              include $file;
              break;
            }
          }

          die(1);
        }
      }
    }
    $filterChain->execute();
  }
}

Il reste maintenant à charger ce filtre dans notre application

Path: /apps/[NomApp]/config/filters.yml

rendering: ~
security:  ~

# insert your own filters here
isApplicationActivated:
  class:  isApplicationActivatedFilter
  
cache:     ~
common:    ~
execution: ~

Il faut suffit maintenant de personnaliser votre page de maintenance en créant le fichier unavailable.php dans votre dossier config.

Dès à présent, si vous créer un fichier [NomApp].lck dans le dossier lock, votre application passera en mode maintenance.

Dans cette article, je ne détaille pas la création et la suppression de ce fichier lck. Je vous laisse le soin de le faire avec votre propre gestion.

Pour tester le bon fonctionnement de ce procédé, vous pouvez créer deux comptes dans votre base de données:

• Compte admin avec le flag is_super_admin: true
• Compte user sans le flag is_super_admin

Vous vous identifiez avec le compte admin et ensuite vous créer le fichier [NomApp].lck dans votre dossier lock et vous vous rendez compte que vous avez toujours accès au page de votre site. Si vous répétez la chose avec le compte user, vous verrez apparaître la page de maintenance.

J’espère que ce code vous servira dans votre prochain développement.

Bonne découverte.