Laravel : utilisation (cas d’une page dynamique)

Route

Créons une route qui mènera à la page power (c'est-à-dire http://localhost/monprojet/public/power), et dont les opérations seront gérées par la méthode activate() de mon contrôleur TestController :

Route::get('power','TestController@activate');

 

Vues

Afin d'aller un peu plus loin dans la découverte de Blade, nous allons garder les vues default.blade.php et informations.blade.php, comme nous les avons créées précédemment, mais en y ajoutant un peu de contenu.

vues.png

1. Le gabarit default (vue générique / parent)

J'ai étendu le gabarit pour permettre de constater que @yield peut agréger autre chose que des sections nommées content :

<!DOCTYPE html>
<html lang="fr">
<head>
<meta charset="UTF-8">
<title>Page de test</title>
</head>
<body>
<h1>Mon site test</h1>

@yield('header')
@yield('nav')
@yield('content')

</body>
</html>

Nous allons voir que les @yield('header') et @yield('nav') permettent d'agréger les sections nommées 'header' et 'nav' de la vue enfant, comme cela était le cas pour la section content.

2. La vue informations (vue spécifique / enfant)

Dans la page informations.blade.php sous mon dossier test, j'ai adapté le code pour quelque chose de plus complet, qui permette de jauger plus significativement le potentiel de Blade :

@extends('default')


@section('header')
    <form method="get">
        <input type="submit" name="etat" value="{{ $value }}">
    </form>
@endsection


@section('nav')
    <ul>
        @foreach($nav as $item)
            <li><a href="#">{{ $item }}</a></li>
        @endforeach
    </ul>
@endsection


@section('content')
@if($value !== 'Activer')
    @include('test.bonjour')
@endif
@endsection

Section "header"

Dans la section header, je crée un simple formulaire en méthode GET. Aucun changement n'est observable dans cette partie du code, à l'exception de la value du formulaire qui accueille une variable entre double accolades. Les double accolades permettent d'afficher le contenu d'une variable en l'échappant. {{ $value }} revient à écrire : <?php echo htmlentities($value); ?> Le contenu de cette variable n'est pas renseigné dans la vue puisqu'il est envoyé depuis le contrôleur – que nous créerons dans le point suivant – vers la vue.

Section "nav"

Dans la section nav, j'appelle un tableau envoyé par le contrôleur – voir plus loin – sur lequel je réalise une boucle foreach et affiche chaque élément du tableau en l'échappant : {{ }}. Bien sûr, le code est adapté à la sauce Blade, tant pour l'affichage du contenu des variables que pour la boucle itérative. S'il était produit en PHP, le script serait écrit comme ceci :

<ul>
   <?php
   foreach($nav as $item) {
   ?>
     <li><a href="#"><?php echo htmlentities($item); ?></a></li>
   <?php
   }
   ?>
</ul>

Le code est donc largement simplifié puisqu'il permet notamment de se passer des (rébarbatives) balises PHP.

Section "content"

Afin d'avoir fait un tour satisfaisant des options de Blade, j'ai créé dans la section content une condition spécifiant que si la variable $value (du header) est différente d' "Activer", j'inclus une autre page nommée bonjour.blade.php, située au même niveau que la présente vue, sous le dossier test. Le @if et le @include sont également propres à la syntaxe de Blade.

3. La vue bonjour : inclusion

Voici la vue bonjour.blade.php, qui sera embarquée quand le site sera établi comme "Activé" :

<p>Le service est activé ! Les épices, c'est bon.</p>
<hr>
<p>{{ "<strong>hibou</strong>" }}</p>
<p>{!! "<strong>hibou</strong>" !!}</p>
{{-- Un commentaire --}}

On y trouve : du contenu échappé, entre {{ }}, du contenu non échappé – qui sera donc interprété – entre {!! !!}, ainsi qu'un commentaire, entre {{-- --}}. Nous verrons ce que donne le résultat de ces trois lignes de code un peu plus bas.

Contrôleur

Comme prévu, nous voilà dans la méthode du contrôleur à laquelle menait la route.

<?php
namespace App\Http\Controllers;

use Illuminate\Http\RedirectResponse;
use Illuminate\Http\Request;

class TestController extends Controller {

	public function activate(Request $request) {
		$nav = ['aneth', 'bergamote', 'coriandre', 'estragon', 'fenouil']; ➊
		$etat = $request->etat;
		if($etat == 'Désactiver') {
			$value = 'Activer';
		} else {
			$value = 'Désactiver';
		} ➋
		return view('test.informations', compact('nav', 'value')); ➌
	}
}

➊ Nous pouvons trouver dans ce contrôleur le tableau $nav à 5 valeurs que nous avons déjà traité avec la boucle foreach (cf. point section nav de la vue 'informations').

➋ Ici, nous abordons les requêtes. Dans la ligne 11 du code ci-dessus, on affecte à la variable $etat la valeur du GET obtenue en cliquant sur le bouton (submit) du formulaire (cf. section header de la vue 'informations'). On demande en effet à Laravel d'établir une requête et d'aller chercher la valeur du GET auquel on a attribué l'attribut name, c'est-à-dire le submit lui-même.

⚠ Pour que $request->[name_du_get] fonctionne, il est nécessaire d'appeler le fichier Request au sommet du contrôleur (use Illuminate\Http\Request;) ainsi qu'en paramètre de la méthode (Request $request, Request servant à instancier l'existant). Ensuite j'établis une condition : si la variable $etat vaut "Désactiver", j'affecte à une variable nommée $value la valeur "Activer" ; mais pour toute autre valeur, la chaîne de caractères "Désactiver" sera affectée à ma variable $value.

➌ Enfin, on retourne la vue informations qui se trouve dans le dossier test, tout en passant à cette vue les variables $nav (➊) et $value (➋), de sorte qu'elles puissent y être exploitées, ce qui a été fait !

Résultat

Les vues ci-dessous varient en fonction qu'on clique sur le bouton en dessous du titre. Si l'on clique sur "Activer" (parce que le site est désactivé), on l'active, et le bouton prend alors dynamiquement la valeur "Désactiver" pour opérer dans le sens inverse (cf. Contrôleur). Par ailleurs, la vue bonjour n'est visible qu'à condition que le site soit établi comme actif (cf. Vue informations, section content).

active.png desactive.png

Conclusion

Désormais, nous avons fait un tour presque complet de Blade. @if @elseif @else, @for, @forelse, @isset – pour ne citer que celles-là – sont d'autres fonctions exploitables que vous pourrez découvrir sur la documentation officielle de Laravel. Le présent article nous a permis de voir comment communiquer des variables du contrôleur à la vue, ce qui est un premier pas vers l'élaboration d'un site ou d'une application plus dynamique. Dans le prochain article, nous verrons la gestion des formulaires en POST, Artisan (l'interface en ligne de commande) et les interactions avec une base de données. See you soon :) ! Enregistrer

Laravel : utilisation (cas d'une page statique)

Vues

1. Le gabarit (vue générique / parent)

Avec Blade – le moteur de templates de Laravel –, il convient de créer un gabarit sous resources > views. Nommons le default.blade.php, et déposons-y ce contenu :

<!DOCTYPE html>
<html lang="fr">
<head>
<meta charset="UTF-8">
<title>Page de test</title>
</head>
<body>

<h1>Mon site test</h1>

@yield('content')

</body>
</html>

Comme nous pouvons le voir, ce fichier HTML n'est pas complètement normé/standard. L'élément @yield('content') est en effet une des premières caractéristiques de Blade. L'élément yield permet d'agréger le contenu 'content' d'une page tierce, qui héritera du gabarit default.blade.php. Créons donc cette page tierce pour y voir plus clair.  

2. La vue (vue spécifique / enfant)

Dans le dossier views, créons un dossier test et créons-y un fichier informations.blade.php comprenant ce contenu :

@extends('default')

@section('content')
<p>Lorem ipsum dolor sit amet, consectetur adipisicing elit, sed do eiusmod tempor incididunt ut labore et dolore magna aliqua</p>
@endsection

Dans ce fichier, nous pouvons comprendre le code comme suit : hérite du fichier default (sous-entendu default.blade.php), gabarit qui agrègera (@yield) le contenu de la section 'content'.  

Route

Comme vu dans l'article précédent, le fichier routes.php – présent dans le dossier app > Http – indique l'action à accomplir en fonction de l'URL saisie dans le navigateur. Nous allons donc établir la route comme suit :

Route::get('informations', function() {
	return view('test.informations');
});

Dans le présent exemple, Laravel récupère la vue située dans mon dossier resources > views > test > informations pour l'afficher à l'adresse http://localhost/monprojet/public/informations.   ... Mais cette formulation est un raccourci barbare. Préférons-lui :

Route::get('informations', 'TestController@index');

Cette instruction peut être traduite comme suit : pour la route menant à http://localhost/monprojet/public/informations, exécute la méthode index() du contrôleur TestController. Reste donc à créer ledit contrôleur pour que la route génère un résultat...  

Contrôleur

Dans le dossier App > Http > Controllers, créez un contrôleur TestController avec ce contenu :

<?php
namespace App\Http\Controllers;

class TestController extends Controller {

	public function index() {
		return view('test.informations');
	}

}

La méthode index() du contrôleur ici présent – à laquelle il a été fait appel dans la route ci-dessus – retourne la vue informations.blade.php issue du dossier test sous resources > views (on aurait tout aussi bien pu écrire test/informations, Laravel accepte les deux nomenclatures)  

Résultat

En se rendant sur la page : http://localhost/monprojet/public/informations, nous obtenons ce résultat :  

Conclusion

Rien ne justifie le choix d'un framework pour la réalisation d'un site statique, puisqu'il complexifie énormément les choses, comme vous pouvez le voir. Toutefois, dès lors que nous exploiterons des données dynamiquement et communiquerons avec la base de données, les procédures s'en trouveront allégées : moins de code, plus de sécurité ;) . Le prochain article s'attardera sur la création d'une page plus dynamique pour permettre d'exploiter les vues Blade, les routes et les contrôleurs un peu plus loin. Et ce sera toujours sans modèle ni base de données, pour y aller pas à pas. Enregistrer

Laravel : introduction

laravel.pngNé en 2011, Laravel est le framework PHP à architecture MVCR dont on parle probablement le plus après Symfony depuis quelques années. Je suis partie à la rencontre de cet outil, et pour ne rien perdre des connaissances que j'en ai engrangées, je délivre dans le même temps ce mémo.


Installer Laravel

  • Installer Composer.composer.png
  • Installer Laravel : depuis l’invite de commandes, accéder au dossier www/htdocs de votre wamp/xampp et exécuter la commande suivante :
    composer create-project laravel/laravel {directory} "~5.0.0" --prefer-dist
  • Établir la connexion à la base de données : adapter les paramètres sous le fichier .env à la racine du dossier.

Préambule

Arborescence du framework

  • app (cœur de votre application)
    • Commands
    • Console
    • Events
    • Handlers
    • Commands
    • Events
    • Http
      • Controllers
      • Middleware
      • Requests
    • Providers
    • Services
  • bootstrap (fichiers d’initialisation de Laravel)
  • config (fichiers de configuration)
  • database (fichiers liés à la base de données)
    • migrations
    • seeds
  • public (assets : fichiers images, js, css)
    • package
  • resources (vues et fichiers de langue)
    • lang
    • views
  • storage (données temporaires de l’application : clés de session, caches…)
    • cache
    • logs
    • meta
    • sessions
    • views
    • work
  • tests (fichiers de tests unitaires)
  • vendor (composants de Laravel & dépendances)

Routes

Laravel impose l'utilisation de routes pour faire le pont entre ses vues et ses contrôleurs. S'il s'agit d'une caractéristique plutôt rébarbative au premier abord ((Face à des frameworks comme CodeIgniter, CakePHP ou Nette qui gèrent les routes automatiquement, Laravel force à se concentrer sur une composante de plus.)), on lui reconnaît les qualités de renforcer la sécurité et surtout d'améliorer la vitesse d'affichage, et donc l'expérience utilisateur. Présent dans le dossier app > Http, le fichier routes.php indique l'action à accomplir en fonction de l'URL saisie dans le navigateur. En fonction de l'URL explorée, les routes transmettent des données à la méthode d'un contrôleur, qui se charge d'exécuter une série d'instructions – en passant si nécessaire par le modèle, destiné à l'élaboration de requêtes dans la base de données – pour renvoyer enfin le résultat à la vue.

mcvr-1.png

Artisan

Laravel propose une interface en ligne de commande nommée Artisan. Artisan permet d'automatiser toute une série d'opérations de gestion au sein du framework, telles que la création de contrôleurs, de modèles, de migrations, ou l'affichage des routes existantes établies au sein de l'application créée.

Blade

Blade est le moteur de templates dépendant de Laravel. Il fonctionne sur un système d'héritage qui lui permet d'agréger des vues, et de faciliter par ailleurs l'affichage de variables (code PHP) en échappant la plupart des données qui sont embarquées dans les vues.

Eloquent

Eloquent est un ORM (Object-relational Mapping) implémentant ActiveRecord qui permet de faciliter les requêtes dans la base de données par une syntaxe voulue plus éloquente que du simple SQL. Il supporte nativement plusieurs SGBD : MySQL, PostgreSQL, Sqlite3 et SQLServer. Eloquent est typiquement utilisé dans les modèles, situés dans le dossier app > Http. Depuis Laravel 4, il n'est toutefois plus obligatoire pour gérer les requêtes au sein du framework. Il peut être par ailleurs remplacé par d'autres ORM qui correspondraient mieux aux attentes du développeur.

Conventions de nommage

  • Les tables des bases de données doivent figurer au pluriel.
  • Les colonnes de la base de données doivent normalement figurer en snake_case.
  • Les noms de classes doivent être déclarées UpperCamelCase.
  • Le nom des méthodes et des fonctions est prévu en lowerCamelCase.
  • Les constantes sont toutes déclarées en UPPERCASE_AVEC_UNDERSCORES.
  • Le nom des modèles, rappelant celui des tables doit figurer au singulier.
  • Les contrôleurs n'imposent rien quant au genre (singulier ou pluriel).

Précautions

Contrairement à d'autres frameworks, Laravel propose une upgrade (et non une update !) à chaque sous version, et ce, de manière extrêmement rapide ((Laravel a proposé sa version 5.0 en février 2015, sa version 5.1 en juin 2015 et sa version 5.2 en décembre 2015 !)). En procédant à l'upgrade d'un projet sur lequel vous avez déjà bien avancé, vous risqueriez de ne plus pouvoir exécuter celui-ci comme avant en raison des changements opérés au sein du noyau même de l'outil en passant, par exemple, de la version 5.1 à la version 5.2 du framework. Je vous recommande donc de conserver la version avec laquelle vous avez entamé votre site/application. Toutefois, pas de panique : les différentes versions du framework sont supposées être maintenues assez durablement, et leurs documentations rester disponibles tant que les versions précédentes "vivront".

laravel-releases.png

Dans l'article suivant, nous nous pencherons sur une utilisation basique du framework – sans base de données – pour appréhender les interactions entre les routes, les contrôleurs et les vues Blade. Enregistrer

Contrer les robots spammeurs

 

captha.gifDès lors que votre site est référencé sur le web et comporte un formulaire (destiné à envoyer un mail, à commenter un article, à s'inscrire sur un site...), il s'offre telle une proie aux vautours que sont les spambots. Les robots spammeurs prennent en effet d'assaut de nombreux sites en complétant frénétiquement les champs de saisie qui se présentent devant eux. Ici, vous trouverez une liste de solutions en vue de contrer ce phénomène.

  • Ne pas écrire son adresse mail en clair sur un site ! Voici des solutions pour cacher un e-mail.
  • Placer un champ invisible dans le formulaire (display:none ou visibility:hidden en CSS) : les spambots tentent de tous les remplir. Si ce champ est rempli, vous êtes à peu près sûr de ne pas avoir affaire à un humain ((Attention, les lecteurs d'écran des malvoyants peuvent parcourir ce genre de champ. À vous de mettre en garde les utilisateurs pour qu'ils ne le remplissent.)). Toutefois, veillez à ce que le champ ait l'air le plus normal possible pour que les robots ne l'ignorent pas (évitez les name='leaveBlank', 'detectSpam' ou 'honeypot').
  • Vérifier l'email : l'envoi d'un lien pour confirmer la transaction est une option pertinente dans le cadre de l'inscription sur un site. Elle est plus rébarbative s'il s'agit simplement de publier un commentaire sur un blog.
  • Permettre aux utilisateurs de s'inscrire par l'intermédiaire des réseaux sociaux (Oauth) est aussi une solution pour ne pas se confronter aux robots. Mais il serait déplaisant de n'offrir que cette solution aux utilisateurs, car nombre d'entre eux préfèrent une inscription classique.
  • Poser une question telle que "Quatre plus six ?" ou "Quelle est la couleur de l'herbe ?" : il s'agit d'une solution accessible pour vérifier si vous avez affaire à un robot. Toutefois, elle est souvent dissuasive pour les utilisateurs qui n'en saisissent pas l'utilité.
  • Imposer un CAPTCHA visuel (image résistant aux dispositifs OCR) est une possibilité. Mais les CAPTCHAs sont rébarbatifs pour les utilisateurs et surtout non accessibles aux personnes souffrant de troubles visuels sévères ((Les aveugles et malvoyants ne sont capables de prendre connaissance du contenu d'une image que par l'attribut "alt" de l'élément HTML "img". En l'occurrence, les CAPTCHAS ne renseignent pas ce genre d'attribut, sous peine de prêter main forte aux robots spammeurs.)), donc à éviter dans la mesure du possible.
  • Imposer un CAPTCHA audio est une option intéressante, mais pas meilleure que la précédente. Le problème de l'accessibilité se pose en effet non seulement pour les sourds et malentendants, mais aussi pour les utilisateurs dont la carte son serait dysfonctionnelle...
  • Imposer un reCAPTCHA (Google) semble une option partiellement fonctionnelle en termes d'accessibilité. Certains lecteurs d'écran sont en mesure d'y accéder, d'autres non. Dans ce cas-ci, Google analyse si l'utilisateur est un robot ou non sur base des mouvements de la souris et de la manière dont les réponses sont saisies. Toutefois, cet outil est controversé, parce qu'il semble au passage se saisir des données privées de l'utilisateur à des fins publicitaires.
  • Vérifier si l'IP n'appartient pas à une liste noire via des outils tels que Project HoneyPot, Stop forum spam ou Botscout.
  • Bloquer les IP selon le lieu d'origine de "l'utilisateur" : la plupart des robots spammeurs émanent de Chine, Inde, Indonésie, Pakistan, Russie et Ukraine. Si votre site n'est pas destiné à un public international, envisagez de bloquer ce type d'IP d'emblée.
  • Bloquer une liste de mots-clés : si les contenus postés comprennent des termes inappropriés ou que, par exemple, 5 consonnes se suivent dans une chaîne de caractères, bloquez l'IP.
  • Dénombrer le nombre de tentatives d'écriture/d'inscription émanant d'une même adresse IP et prévenir le flood ou les attaques en rejetant l'IP pour une durée établie au bout de X essais.
  • Détecter la rapidité de complétion : les robots remplissent un formulaire en une maigre poignée de secondes après l'ouverture de la page. Des outils jQuery sont en mesure de calculer ce genre de délai, à vous de bloquer les faux-utilisateurs potentiels qui prennent moins de 5 secondes pour compléter et valider un formulaire.
  • Demander aux utilisateurs de fournir leurs motivations pour rejoindre le site et soumettre les réponses à l'appréciation d'un modérateur pour l'activation des comptes. C'est ultra ingrat et fastidieux tant pour les utilisateurs que pour les gestionnaires du site, mais c'est très sûr...
  • [CMS] Utiliser des solutions anti-spams telles qu'Akismet sous Wordpress ou Mollom sous Drupal.

Malgré toutes ces solutions, aucune ne garantit à 100% que vous soyez à l'abri d'attaques qui portent leurs fruits. L'évolution des robots est grandissante, il convient de veiller sans cesse pour adapter la sécurité de son site en conséquence.


Informations complémentaires

Sources

Enregistrer

- page 1 de 7