L'abeille comme révélateur des problématiques environnementales

Des sujets très vastes portés par ce merveilleux insecte.

En attendant la création du prochain site web www.abeille-infos.com en cours de réalisation, sans doute pour un certain nombre de semaines, j'ai défini également son identité avec un logo évocateur en ce qui concerne son objectif.
Bien que ce logo ne soit pas encore définitif, notamment au niveau des couleurs choisies, je considère qu'il me convient déjà en l'état, car il illustre bien la volonté d'informer et traiter l'actualité autour de l'abeille, comme témoin des évolutions.

Il sera aussi question d'aborder les causes et conséquences de l'activité de l'homme sur la planète avec l'abeille comme sentinelle involontaire et aux avant-postes.

D'autres thématiques seront abordées comme bien sûr l'apiculture responsable et davantage respectueuse de l'insecte, les menaces qui pèse sur sa disparition et les effets constatés, quelques bonnes adresses pour trouver du miel de qualité directement auprès du producteur, des annuaires spécifiques ...
Mais aussi des articles proposeront de s'initier à l'apiculture en tant que débutant, de manière simple et sans prétention, pour contribuer à son niveau, au maintien de l'existence des abeilles. La mise en avant d'actions associatives ou autres en faveur de l'abeille feront l'objet de toute mon attention.

Bref, des mauvaises nouvelles en guise de prise de conscience, mais aussi surtout des approches positives mises en exergue qui veulent donner un avenir à l'abeille et à la planète !

Le futur site web est actuellement développé sous Drupal 9+, ceci afin de joindre ma formation technique et mes convictions.

Cet article www.abeille-infos.com, les premières fondations du site sous Drupal ! est apparu en premier sur DOTPROGS.

L'idée, ici, est de présenter l'usage d'un "token" (jeton) pour se prémunir d'une attaque CSRF (Cross Site Request Forgery) en utilisant le framework Symfony 4+ (doit pouvoir fonctionner en Sf 3 également à peu de chose près) mais sans s'appuyer sur un formulaire.

En effet les tokens CSRF sont proposés pour la sécurité d'un formulaire Symfony, donc l'objectif de ma démarche avec ce "bout de code" est de mettre en place la même sécurité, en utilisant un simple lien ou un bouton HTML par exemple avec une requête "DELETE" en AJAX pour appeler l'action dédiée "DeleteMemberAction" ci-dessous.
Note : utiliser une requête en "GET" pour une suppression de ressource est une mauvaise pratique d'un point de vue HTTP.

Cet exemple tient compte du fait que l'utilisateur à l'origine de l'action est normalement authentifié sur un espace sécurisé, ce qui fait le danger par principe d'une attaque CSRF.
Un compte "membre" doit être supprimé, ce que l'on peut considérer comme une opération sensible !

<?php

declare(strict_types = 1);

namespace App\Action;

use App\Responder\DeleteMemberResponder; 
use Symfony\Component\HttpFoundation\Request;
use Symfony\Component\Routing\Annotation\Route;
use Symfony\Component\Security\Core\Exception\InvalidCsrfTokenException;
use Symfony\Component\Security\Csrf\CsrfToken;
use Symfony\Component\Security\Csrf\CsrfTokenManagerInterface;

/**
 * Class DeleteMemberAction.
 *
 * Delete a member account.
 */
class DeleteMemberAction
{
    /**
     *  Manage member deletion.
     *
     * @Route({
     *     "en": "/user/{id}/delete/{token}"
     * }, name="delete_member", methods={"DELETE"})
     *
     * @param CsrfTokenManagerInterface $csrfTokenManager
     * @param DeleteMemberResponder     $responder
     * @param Request                   $request
     * 
     * @return Response
     *
     * @throws InvalidCsrfTokenException
     */ 
    public function __invoke(CsrfTokenManagerInterface $csrfTokenManager, DeleteMemberResponder $responder, Request $request): Response
    {
        // "delete_member" must be a unique token id for session storage inside application
        $token = new CsrfToken('delete_member', $request->attributes->get('token'));

        // Action is stopped since token is not allowed!
        if (!$csrfTokenManager->isTokenValid($token)) {
            throw new InvalidCsrfTokenException('CSRF Token is not valid.');
        }

        // Handle request and proceed to parameters validation and member deletion
        // ...
        // Return expected response (e.g. JSON, HTML...)
    }
}

Note : cette action est auto-configurée en tant que "controller" au sein du framework pour être appelée correctement via la route précisée.
Ce "controller" va en outre enclencher la vérification de la validité du token par l'intermédiaire d'un service "CsrfTokenManager" implémentant une interface. Vous trouverez ici le détail de cette classe concrète.

Cet objet "CsrfTokenManager" vérifie la validité d'un autre objet "CsrfToken" associant un identifiant et une valeur de token.

Mais à ce propos comment le token est généré ?
Généralement, il est créé dans un template via une fonction Twig avec "csrf_token('delete_member')" qui permet d'avoir le retour de la valeur du token CSRF en passant l'identifiant correspondant attendu.
Voici ce que cela peut donner sur un simple lien HTML côté Twig (l'allié fidèle de Symfony) :

{# "id" parameter can also be a uuid value! #}
<a href="{{ path('delete_member', {'id': 450, 'token': csrf_token('delete_member')}) }}" title="Validate deletion">Delete account</a>

Bien entendu, il est préférable par exemple de demander une confirmation avant suppression, afin d'être plus user friendly !

Le token CSRF peut être généré aussi simplement dans un service, toujours grâce à l'instance "CsrfTokenManager" et sa méthode "getToken('delete_member')" qui retourne un objet "CsrfToken" et va générer/stocker le token s'il n'existe pas déjà.
L'objet "CsrfToken" a quant à lui une méthode "getValue()" afin de récupérer en définitive la valeur du token.

{# Strange getter which can also generate a token! #}
$token = $csrfTokenManager->getToken('delete_member')->getValue();

Ce manager fait appel à d'autres instances pour générer le token et le stocker en session notamment via les classes concrètes "UriSafeTokenGenerator" et "NativeSessionTokenStorage" ou des implémentations similaires.

J'espère que ces quelques lignes pourront vous rendre service, sans mauvais jeu de mot !

Cet article Exemple d’utilisation d’un « token CSRF » sans formulaire avec Symfony est apparu en premier sur DOTPROGS.

Partons du principe que l'on souhaite lister les erreurs de validation lors de l'utilisation d'un formulaire avec Symfony 4.
Ça ne sert pas à grand chose mais cet exemple permet de récupérer "l'équivalent" simplifié des données qui remontent dans le profiler de Symfony pour les violations de contraintes sur les champs de ce formulaire.

Pour faire du "debug" rapide, j'utilise simplement un dump() des erreurs directement côté Twig pour m'assurer que les contraintes s'appliquent bien en testant visuellement le formulaire.

J'ai donc déclaré une fonction "macro" utilisée de façon récursive et exécutée pour boucler sur les objets FormErrorsIterator de chaque champ enfant (et enfant(s) d'enfant ...).

Note: "_self" désigne le template courant et permet une utilisation immédiate.

Pour Symfony, tout type de champ de formulaire est également un formulaire, il existe donc la notion de formulaire parent et enfant.

La récursivité pour cet exemple provient simplement du fait que j'ai décidé d'afficher l'ensemble des violations de contraintes présentes au sein du root form ici appelé "myRootForm" (variable déclarée pour le formulaire global) :

{% macro form_errors(forms) %}
  {% for form in forms %}
    {% for formError in form.vars.errors %}
      {{ dump(formError.cause.propertyPath, formError.cause.constraint, formError.cause.message) }}
    {% endfor %}
    {% if form.children is not empty %}
      {# Use macro recursively #}
      {{ _self.form_errors(form.children) }}
    {% endif %}
  {% endfor %}
{% endmacro %}

{# Use macro immediately after declaration in the same template #}
{{ _self.form_errors(myRootForm.children) }}

Ce "dump" affiche le propertyPath (le champ concerné), le type de contrainte objet, et le message d'erreur personnalisé ou proposé par défaut.
Les contraintes personnalisées (custom constraints) proposées par Symfony, éventuellement mises en place sur un projet, remontent également dans les boucles.

Pour utiliser votre macro où vous le souhaitez, il suffit de la déclarer dans un template dédié aux déclarations des fonctions macros et ensuite de faire un import de ce template dans un autre template pour pouvoir l'utiliser :

{# Import macro in another template #}
{% from 'macros.html.twig' import form_errors %}

{# Use macro #}
{{ form_errors(myRootForm.children) }}

{# ------------------------------------------- #}

{# Or import macro like this #} 
{% import "macros.html.twig" as macros %}

{# Use macro in the same way #}
{{ macros.form_errors(myRootForm.children) }}

Vous pouvez consulter la documentation concernant les macros Twig.

Voilà, c'est déjà fini !

Cet article Exemple d’utilisation d’une fonction « macro » Twig récursive est apparu en premier sur DOTPROGS.

Dans le cadre de la création d'un blog, je me suis documenté sur quelques approches basiques pour réaliser une pagination en PHP - MySQL afin de lister des articles.
une fois le principe de base compris, j'ai décidé par la suite de "personnaliser" un tantinet cette pagination et l'afficher avec Twig dans un autre projet utilisant le framework Symfony.

- J'utilise par exemple un "entity service layer" qui est une classe PHP qui sert ici de passerelle entre un Repository Doctrine et une Action/Controller.
Je prends en compte également un affichage descendant ou ascendant "$order" qui est bien sûr facultatif car on peut faire plus simple !
L'objectif est de faire une requête SQL en utilisant les paramètres OFFSET ET LIMIT - ici grâce au Repository avec findByLimitOffsetWithOrder(...) dans la méthode getFilteredList(...) - pour obtenir les posts (articles) propres à la page courante "currentPage" définie dans getPaginationParameters(...).
Les principales méthodes personnelles nécessaires de cet "entity service layer" que j'utilisent sont présentées ci-dessous :

<?php 
 
declare(strict_types = 1); 
 
namespace App\Service; 
 
// Used classes are not declared to simplify code demo! 
// use ... 
// use ... 
 
class PostServiceLayer 
{ 
    // Traits, properties and constructor with dependency injection and other previous methods 
    // ...
 
    /** 
    * Count all posts without filter. 
    * 
    * @return int 
    * 
    * @throws \Doctrine\ORM\NonUniqueResultException 
    * @throws \UnexpectedValueException 
    */ 
    public function countAll() : int 
    { 
        $result = $this->repository->countAll();
        if (\is_null($result)) {
            throw new \UnexpectedValueException('Post total count error: list can not be generated!');
        }
        return $result;
    }
 
    /**
     * Get filtered post list depending on parameters.
     *
     * @param int|null $offset
     * @param int      $limit
     * @param string   $order
     *
     * @return array
     *
     * @throws \Doctrine\ORM\NonUniqueResultException
     */
    public function getFilteredList(
        int $offset = null,
        int $limit = Post::POST_NUMBER_PER_LOADING,
        string $order = Post::POST_LOADING_MODE
    ) : array {
        // Init value to define starting rank
        $init = ('DESC' === $order) ? $this->countAll() : -1;
        // Offset starts at 0 (i.e. the 15th Post rank has a value of 14)
        $start = $offset;
        $end = $offset + $limit;
        return $this->repository->findByLimitOffsetWithOrder($order, $init, $start, $end);
    }
 
    /**
     * Get default parameters to show a post list.
     *
     * (e.g. sort direction, post number for "load more", ...)
     *
     * @return array
     */
    public function getListDefaultParameters() : array
    {
        return [
            'loadingMode'      => Post::POST_LOADING_MODE,
            'numberPerLoading' => Post::POST_NUMBER_PER_LOADING,
            'numberPerPage'    => Post::POST_NUMBER_PER_PAGE
        ];
    }
 
    /**
     * Get pagination parameters to manage page links.
     *
     * This is used on complete post list accessible on "posts" page.
     *
     * @param int $pageIndex
     *
     * @return array|null
     *
     * @throws \Doctrine\ORM\NonUniqueResultException
     */
    public function getPaginationParameters(int $pageIndex) : ?array
    {
        $countAll = $this->countAll();
        $listDefaultParameters = $this->getListDefaultParameters();
        $postNumberPerPage = $listDefaultParameters['numberPerPage'];
        $pageCount = $countAll % $postNumberPerPage == 0
            ? $countAll / $postNumberPerPage
            : (int) floor($countAll / $postNumberPerPage) + 1;
        $loadingMode = $listDefaultParameters['loadingMode'];
        if ($pageIndex <= 0 || $pageIndex > $pageCount) {
            return null;
        }
        if ('DESC' === $loadingMode) {
            $offset = $countAll - $pageIndex * $postNumberPerPage < 0
                ? 0 : $countAll - $pageIndex * $postNumberPerPage;
            $limit = $offset === 0
                ? $countAll % $postNumberPerPage : $postNumberPerPage;
 
        } else {
            $offset = $pageIndex === 1
                ? 0 : ($pageIndex - 1) * $postNumberPerPage;
            $limit = $offset + $postNumberPerPage > $countAll - 1
                ? $countAll % $postNumberPerPage : $postNumberPerPage;
        }
        return [
            'currentPage'   => $pageIndex,
            'currentOffset' => $offset,
            'currentLimit'  => $limit,
            'pageCount'     => $pageCount,
            'loadingMode'   => $loadingMode,
            'postCount'     => $countAll
        ];
    }
 
    // Other following methods
    // ...
 
}

- Voici la partie Twig à intégrer dans un template (les commentaires sont en anglais, c'est une habitude personnelle !) :
Les deux variables importantes à transmettre à la vue depuis une "Action" ou un "Controller" (non détaillé ici) sont le nombre de page total "pageCount" et la page courante "currentPage" pour sa mise en exergue et structurer les comportements autour d'elle.
Dans une deuxième temps, il s'agit d'initialiser des variables en fonction des conditions induites par la personnalisation que l'on souhaite obtenir.
Je décide par exemple d'afficher les 2 pages précédentes et suivantes (libre à vous d'en afficher plus!) autour de la page courante : si cela n'est pas possible, j'évalue la possibilité d'afficher 1 page, ou aucune, avant ou après la page courante, ce qui explique les conditions initialisées au préalable.
Je substitue les autres numéros de page par "..." pour les matérialiser, à l'exception de la première et la dernière pour conserver les bornes extrêmes, et ainsi gérer un nombre conséquent de page à afficher le cas échéant.

<!-- Generate pagination block if there is at least more than 1 page! -->
    {% if pageCount > 1 %}
        <!-- Pagination -->
        {# Page quantity to show around current page is 2 or a calculated minimum value #}
        {% set defaultPageQuantityAround = 2 %}
        {# Mininum value #}
        {% set minimumPageQuantityAround = min(currentPage - 1, pageCount - currentPage) %}
        {# Condition to show the right page numbers before current page: default or minimum value #}
        {% set conditionBefore = currentPage != 1 and minimumPageQuantityAround <= currentPage - 1 %}
        {# Condition to show the right page numbers after current page: default or minimum value #}
        {% set conditionAfter = currentPage != pageCount and minimumPageQuantityAround <= pageCount - currentPage %}
        {# Define page numbers before, other pages will be replaced by "..." #}
        {% set PageQuantityAroundBefore = conditionBefore ? defaultPageQuantityAround : minimumPageQuantityAround %}
        {# Define page numbers after, other pages will be replaced by "..." #}
        {% set PageQuantityAroundAfter = conditionAfter ? defaultPageQuantityAround : minimumPageQuantityAround %}
        <div class="uk-flex uk-flex-center">
            <ul class="uk-pagination uk-text-bold uk-text-uppercase">
                {# Previous link #}
                {% if currentPage - 1 != 0 %}
                <li><a class="st-color-yellow" href="{{ path('posts', { 'page': currentPage - 1 }) }}" title="Previous"><span class="uk-margin-small-right" uk-pagination-previous></span> Previous</a></li>
                {% endif %}
                {% for i in 1..pageCount %}
                {# Current page to show #}
                {% if currentPage == i %}
                <li class="st-color-red">{{ i }}</li>
                {# Show "..." before current page depending on page numbers to show before #}
                {% elseif (i < currentPage and 1 != i) and (i == currentPage - PageQuantityAroundBefore - 1) %}
                <li class="uk-disabled">...</li>
                {# Show "..." after current page depending on page numbers to show after #}
                {% elseif (i > currentPage and pageCount != i) and (i == currentPage + PageQuantityAroundAfter + 1) %}
                <li class="uk-disabled">...</li>
                {# Hide pages under current page and before "..." excepted page 1 #}
                {% elseif (1 != i) and (i < currentPage - PageQuantityAroundBefore - 1) %}
                <li class="uk-hidden"><a href="{{ path('posts', { 'page': i }) }}" title="Page {{ i }}">{{ i }}</a></li>
                {# Hide pages over current page and after "..." excepted page with number "pageCount" (last) #}
                {% elseif (pageCount != i) and (i > currentPage + PageQuantityAroundAfter + 1) %}
                <li class="uk-hidden"><a href="{{ path('posts', { 'page': i }) }}" title="Page {{ i }}">{{ i }}</a></li>
                {# Apply particular style for lowest link corresponding to fisrt page 1, and Highest link corresponding to page total count #}
                {% elseif i == 1 or i == pageCount %}
                <li><a class="st-color-blue" href="{{ path('posts', { 'page': i }) }}" title="Page {{ i }}">{{ i }}</a></li>
                {# Normal links which are not concerned by conditions above #}
                {% else %}
                <li><a href="{{ path('posts', { 'page': i }) }}" title="Page {{ i }}">{{ i }}</a></li>
                {% endif %}
                {% endfor %}
                {# Next link #}
                {% if currentPage + 1 <= pageCount %}
                <li class="uk-margin-auto-left"><a class="st-color-yellow" href="{{ path('posts', { 'page': currentPage + 1 }) }}" title="Next">Next <span class="uk-margin-small-left" uk-pagination-next></span></a></li>
                {% endif %}
            </ul>
        </div>
    {% endif %}

Et voici le résultat visuel de la pagination :

Les classes CSS utilisées ici sont personnalisées (pour les couleurs) et issues du framework UIkit pour le comportement (lien désactivé, lien caché ...), donc rien de significatif pour ce qui est de l'aspect mise en forme.

Un tel système de pagination peut très facilement être adapté pour de l'AJAX et afficher les posts de la page courante (en renvoyant du contenu HTML avec un block Twig par exemple) en asynchrone afin d'être davantage "user friendly" !

Ces extraits de code sont issus d'un projet opérationnel, ceci-dit des "petites coquilles" peuvent s'être glissées entre les lignes.
N'hésitez pas à me contacter pour signaler des erreurs éventuelles ou pour partager des améliorations, car on peut souvent mieux faire ou faire plus pragmatique !

Cet article Mettre en place une pagination personnalisée avec Twig est apparu en premier sur DOTPROGS.