### Repris du résumé de Rosca:

# Dev Web

## 02 - Introduction aux frameworks

### Qu'est-ce que c'est

Le terme français est "cadriciel".

* Composant de haut-niveau (faible couplage)
* facilite le dev de projets complexes(test et gestion)
* utilisation intense de design pattern( IoC)
* comportement par défaut (Conventions over configurations)
* Extensible
* Contrairement à un simple bibliotèque, il permet de coller tous les composants ensemble et fournit donc un réel environnement de développement. Les bibliothèques sont quant à elles simplement "linker" au logiciel en cours de développement et ne servent qu'à fournir des objects, fonctions ou plus généralement des outils.

Pour toutes les raisons citées ci-dessus, l'utilisation de cadriciel permet de moins se soucier des problèmes de sécurité car la plupart sont évités automatiquement de part la structure du cadriciel et les bonnes pratiques qu'il implémente.

### Les designs pattern

* Inversion de contrôle: commun à tous les frameworks, le flôt de l'application est géré par ce dernier et non plus par l'application même. Résumé par le principe d'hollywood "Ne nous appelez pas, c'est nous qui vous appelons" ou encore par l'image de l'application "texte à trou" ou le programmeur rempli juste les trous là ou le cadriciel le lui demande pour spécifier les comportements souhaités.
* MVC:
* Model : logique métier, accès aux données
* View : template des pages à générer
* Controller : Orchestration, transfert des informations
* Front Controller : Controller qui gère toutes les requêtes pour un site web
* Object Relational Mapping : Relation entre les tables de données et les objets, utilise le DAO, gère les relations entre les différentes tables
* UI Patterns : tous les patterns graphiques d'une interface utilisateur

### Conventions

* Nommages des classes, des bases de données, de l'arborescence du projet (libre ou imposé par le framwork et pas de code sous la racine du site)
* Routes: app.com/controller/action/key/val

Elles ne sont pas forcément obligatoires mais recommandé (conventions over configurations)

### Les principes de developpement web

* **Heavy Model, Light Controller**
* **DRY** don't reapeat yourself
* **You Ain't Gonna Need It**
* **Convention Over Configuration**
* **KISS** Keep it simple and stupid (héhé je l'ai placé dans mes slides de p3, Gruni a rigolé)

### URLs

* Explicites
* manipulables par l'utilisateur
* utilisé pour le référencement
* utiliser la convention MVC (app.com/controller/action/key/val)
* Principe du routage (FrontContoller avec URL Rewritting et dispatch sur les autre controllers de l'application)

### Architecture de Laravel

Voir le slide [Exemple de d'architecture: Laravel](https://he-arc.github.io/slides-devweb/02-php-intro-framework.html#10.0)

### Performances

* Lent
* tout le code est traversé
* chaque requête recharge toute l'application
* plus de code
* plus de requêtes
* Solutions
* Caches, opcode
* Jointure ORM, vues, procédures stockées
* Outils d'optimisations

### Questions générales

* Faits : PHP parle HTTP et est un language de template
* Séparer métier & affichage
* **POLP** Principle Of Least Privilege : réduction des dépendances à une certaines technologies. Par exemple, pour les vues, on essaie de ne pas dépendre entièrement d'un moteur de template particulier.
* Sécurisation des champs d'un formulaire avant de les employer pour des requêtes dans la bdd
* Utiliser les ORM
* Utiliser la réécriture d'URL
* Routing : fait le liens entre les adresses(URI) et les actions dans le code
* Composer pour gérer les paquets php
* **Un framwork PHP est une collection de bibliothèque avec un peu de glue** [selon le slide](https://he-arc.github.io/slides-devweb/02-php-intro-framework.html#46.0)

## 03 - Laravel 5

### Généralités sur le framwork

* Bonne documentation
* Gratuit & opensource
* Basé sur des composants d'autres framwork
* dernière version (5.7) datant de septembre 2018

### Fonctionnalités

* RESTful
* ORM
* Migrations
* Blade (moteur de template)
* Pagination
* Authentification & sessions
* Mails
* Tests
* Extensible par paquets (composer)

### Front Controller

[Schéma du front controller](https://he-arc.github.io/slides-devweb/03-Laravel.html#5.0)

Rôle de manager de requête. Il crée la réponse puis la fait transiter dans les différents controllers qui complètent cette dernière. Une fois que ce procédé est fini, la réponse est envoyée au client.

### Architecture

[Schéma de l'architecture de Laravel](https://he-arc.github.io/slides-devweb/03-Laravel.html#6.0)

La requête passe en premier par le bloc "Routing". Elle est redirigé vers le bon controller. Ce dernier récupère les bonnes données en passant par le "QueryBuilder" et les modèles. Il appelle ensuite la vue en lui transmettant les données. Cette dernières est contruit par le moteur de template puis envoyée au client.

Deux autres blocs sont liés à la base de données :

* Migration : aide à créer les schémas de la base de données en utilisant un "schema builder"
* Seeding : permet de remplir la base de données à l'aide de données de test.

### MVC

Se trouve sur ce slide un lien vers le [cycle de vie des requêtes](https://laravel.com/docs/master/lifecycle).

Ce qu'il faut en retenir (en gros, car c'est certainement déjà trop détaillé):

* Les requêtes arrivent sur `index.php`
* Le framework démarre depuis `bootstrap/app.php`
* Laravel créer une instance de l'application / service container (chargment des différentes fichiers de l'application)
* Démarrage du HTTP kernel et console Kernel permettant la gestion des requêtes. Les éléments les plus importants qu'ils fournissent sont les **Services Providers** (permettent de démarrer tous les services du framework) et le **Dispatch Request** (fournit le router).
* Les services providers sont la clé du démarrage de Laravel. Ils peuvent être configurés pour chaque application.

_Je vous invite à lire le lien ci-dessus et potentiellement corriger les différents points._

### Pratique

_Plutôt ce qui était utile aux projets_

* Utilisation de la norme PSR-2(voir code ci-dessous) et de la PHPDoc

<?php
namespace Vendor\Package;

use FooInterface;
use BarClass as Bar;
use OtherVendor\OtherPackage\BazClass;

class Foo extends Bar implements FooInterface
{
    public function sampleMethod($a, $b = null)
    {
        if ($a === $b) {
            bar();
        } elseif ($a > $b) {
            $foo->bar($arg1);
        } else {
            BazClass::bar($arg2, $arg3);
        }
    }

    final public static function bar()
    {
        // method body
    }
}

Le [slide](https://he-arc.github.io/slides-devweb/03-Laravel.html#8.0) parle ensuite des éditeurs et IDE des tests, des outils de devs, de la doc et propose des tutoriels.

### Environnement de développement

* Local : AMP+Git, offline et WSL pour windowa
* VM: Vagrant ou conteneur (rapide, pré-configuré, env prévu pour le dev)
* Cloud : Cloud9 (rapide, pré-configuré, dans un navigateur, outils de syncho)

### Mise en place du projet

* Création avec composer
* Initialisation du git
* Configuration d'Apache (.htaccess)

### Artisan

// Liste les routes
$php artisan route:list

// Fais un migration
$php artisan migrate

// Créer un controller
$php artisan make:controller

// Liste les packages
$php artisan list

## 04 - HTML 5

_les slides de ce chapitre sont bourrés de liens divers et variés... Je vais donc essayer de décrire brièvement leurs contenus_

### [Slides de Google](http://web.archive.org/web/20150525080904/http://slides.html5rocks.com/)

* HTML5 ~= HTML5 + CSS3 + JS ES2015
* Offline storage (`window.localStorage.setItem(...)`, Web SQL Database, IndexedDB, Application Cache, Quota API)
* Realtime / Communication (Web Workers, WebSocket, Notifications)
* File / Hardware Access (Native Drag & Drop, Desktop Drag-In/Out, FileSystem APIs, Géolocalisation, Device Orientation, Speech Input)
* Semantics & Markup (des nouveaux tags plus explicites, **progress bar**, Descriptive link relations, Microdata, ARIA attributes pour la lecture d'écran, nouveau types pour les formulaires(required, min, max, placeholder), Form field types on mobile)
* Graphics / Multimedia (Audio & Video, Track Element (pour les sous-titres d'une vidéo par exemple), FullScreen API, Canevas 2D et 3D(WebG**obron**L), Inline SVG)
* CSS3 (plus de sélecteurs, webfonts, text wrapping, columns, etc.)
* Nuts & Bolts (`getElementByClassName(...)`, `querySelector(...)`, custom data-* attributes, History API)

### [CanIUse.com](https://caniuse.com/)

_Ils nous l'a tellement rabâché que je vais pas plus le décrire._

### Progressive Web Apps

C'est une méthodologie de développement qui place les fonctionnalités aux centres et voit complexifier au fur et à mesure l'application (Progressive enhancement). Le developpement est divisé en couches (HTML, CSS puis JS). On ajoute progressivement ces couches en partant de la simplicité à la complexité.

* Mettre l'expérience utilisateur au centre du developpement
* Plus performant qu'une app native
* Meilleure portabilité, rapidité, outils de dev spécialisé (voir [slide](https://he-arc.github.io/slides-devweb/04-html5.html#4.0))

Aussi, le [slide](https://he-arc.github.io/slides-devweb/04-html5.html#5.0) propose des exemples et tutoriels.

## 05 - Javascript & DOM

### Hier

* Page web exécuté par le client
* code interprété
* faiblement typé
* Orienté objet(prototype)

### Aujourd'hui

* Page web mais pas seulement
* compilation JIT
* One Page Apps
* plus seulement dans les navigateurs
* NodeJS
* Moteur JS comme SpiderMonkey et Rhino
* script d'application (Qt, Notepad++)
* Aussi en embarqué

### \*Script

Il existe plusieurs variantes de JS

* ECMAScript
* Typescript
* Coffescript

Javascript possède aussi une implémentation dans Firefox. _Je sais pas si j'ai bien compris ce qu'il veut dire dans son slide_

### Autres généralités

* Les implémentations dans les navigateurs varient
* Attention aux bonnes pratiques et à utiliser les design patterns car code pas maintenable sinon
* Permet de modifier le DOM, l'utilisation des bookmarklets, de créer de requêtes HTTP
* Développement d'applications entièrement JS possible
* Langage de script généraliste (paquets npm)

### Caractéristiques

* Objet -> prototype
* Syntaxe ~= C & Java
* Faiblement typé
* Types
* Primitifs : Boolean, Null, Undefined, Number, String, Symbol
* Objet: Object, Function
* Particularités
* Prototypes (correspond à l'objet. Pas possible de modifier une classe mais possible de modifier une instance au runtime)
* Fermetures ("A closure is a function having access to the parent scope, even after the parent function has closed.")
* Promesses (Représente le résultat d'une requête asynchrone avec les états "pending", "fulfilled" & "rejected")

### Fonctions

* Pas de type de retour
* Retour possible sinon retourne undefined dans tous les cas
* Pas de surcharge possible
* `function` est un type en JS
* les fonctions peuvent être imbriquées et anonymes

### [Unobstrusive JS](https://en.wikipedia.org/wiki/Unobtrusive_JavaScript)

Le principe est surtout de considérer le JS comme un plus pour une page web de sorte à ce que la page soit toujours fonctionnelle dans la cas où le JS n'est pas supporté.

* Séparation HTML / JS
* On conserve l'accessibilité et l'utilisabilité

### Node.js

* Implémentation hors navigateur
* fournit un env d'exécution + des bibliothèques
* basé sur les événements, non-bloquant
* moteur V8
* exécute des scripts
* npm pour la gestion des paquets
* et plus encode

Node.js est vraiment un gros truc. C'est fantastique. C'est top.

### DOM (Document Object Model)

Il représente une page web sous forme d'arborescence et son contenu est accessible et modifiable depuis JS.

* Action sur `Document` : `getElementById(...)`, `getElementByTagName(...)`, `getElementByClass(...)`, `createElement(...)` et `createTextNode(...)`
* Action sur `Node` : `insertBefore(child)`, `appendBefore(child)`, `removeChild(child)` et `replaceChild(newChild, oldChild)`

Pour ajouter un noeud, consulter le [slide](https://he-arc.github.io/slides-devweb/05-JSandDOM.html#14.0).

Pour supprimer un noeud, consulter le [slide](https://he-arc.github.io/slides-devweb/05-JSandDOM.html#15.0).

Pour insérer un noeud, consulter le [slide](https://he-arc.github.io/slides-devweb/05-JSandDOM.html#16.0).

### JQuery

JQuery simplifie beaucoup le procédé -> [slide](https://he-arc.github.io/slides-devweb/05-JSandDOM.html#17.0).

Pour plus d'infos sur JQuery, se référer à la section 07.

## 06 - HTTP & AJAX

### Les nouveautés des versions de HTTP

* 0.9 : connexion, GET, réponse et fermeture
* 1.0 : Ajout des entêtes
* 1.1 : Keep-alive, pipelining, cache mais aussi plus d'entête (Host devient obligatoire)
* 2.0 : Multiplexages de connexions, compressions d'entête, push mais est aussi supporté par tous\* les navigateurs et une grande majorité des serveurs

### Codes de réponses

* 1xx Information
* 2xx Succès
* 3xx Redirection
* 4xx Erreur client
* 5xx Erreur serveur

### Verbes HTTP

Il permet d'indiquer ce que l'on souhaite faire d'une ressource.

* GET: demande (s)
* POST: création
* PUT: remplacement total (id)
* PATCH: remplacement partiel
* DELETE: suppression (id)
* HEAD: demande de l'entête uniquement (s)
* TRACE: test le long du chemin d'accès à une ressource, utilisé pour le débug (s)
* OPTIONS: description des options de communication pour la ressource (s)
* CONNECT: création d'une bidirectionnel avec la ressource

_id pour idempotentes_
_s pour sûres_

### Echanges HTTP

_Je vous laisse observer le [slide](https://he-arc.github.io/slides-devweb/06-HTTPandAJAX.html#5.0)_

On y voit les différents champs d'une requête et d'un réponse.

// TODO détailler les champs parce qu'on oublie tous ce que sait et qu'un Gruni espiègle ou un Greut simple peuvent casser les couilles sur des détails de ce genre !

Le [slide](https://he-arc.github.io/slides-devweb/06-HTTPandAJAX.html#6.0) d'après indique encore quelques infos sur POST, sur des outils mais aussi sur le verbe PATCH.

### Asynchronous Javascript And XML

L'[article de Jesse James Garret](http://web.archive.org/web/20110102130434/http://www.adaptivepath.com/ideas/essays/archives/000385.php): décrit l'AJAX comme une ensemble de plusieurs technologies (XHTML, CSS, DOM, XML, XMLHttpRequest et Javascript). Il le considère d'ailleurs comme une couche intermédiaire entre l'UI du client et le serveur. L'article date de 2005 mais est tout de même intéressant.

AJAX permet la modification d'une page sans rechargement intégrale grâce au Remote Scripting(exécution d'un script qui échange avec un server à l'intérieur même d'une page) et du DOM. Le [slide](https://he-arc.github.io/slides-devweb/06-HTTPandAJAX.html#7.0) propose un historique des techniques de remote scripting.

### XMLHttpRequest (ou XHR)

XHR est une API fournissant des fonctionnalités clientes pour le transfert de données entre un client et un serveur. Le principe est le suivant:

1. Envoi d'une requête HTTP
2. Réponse déclanche un callback
3. MaJ du DOM

Cette **méthode** est considéré comme un **standard**.

XHR est utilisé notamment pour les single page application ou GUI complexes, pour la maj d'un formulaire, pour de l'autocomplétion, mais aussi pour de la validation.

Cet objet provient de Microsoft et consiste à faire des requêtes HTTP en JS. Contrairement au principe de fonctionnement, l'implémentation, elle, n'est pas standard. Son implémentation est variable d'un navigateur à l'autre mais est quand même supporté par la quasi totalité de ces derniers.

En suivant la méthodologie Progressive Web App, il est conseillé d'avoir une alternative dans le cas où le js est désactivé.

Le [slide](https://he-arc.github.io/slides-devweb/06-HTTPandAJAX.html#10.0) montre l'utilisation de XHS en JS et le [slide](https://he-arc.github.io/slides-devweb/06-HTTPandAJAX.html#11.0) montre son utilisation avec JQuery.

Les différentes propriétés sont:

* Etat: `readyState`, `status`, `onreadystatechange`
* Réponse: `responseText`, `responseXML`
* Initialisation: `open(method, url, async, usr, pswd)`
* `method`: verbe HTTP
* `url`: url à atteindre
* `async`: boolean (optionnel)
* `usr`: username si auth (optionnel)
* `pswd`: password si auth (optionnel)
* Envoie: `send()`
* Header: `setRequestHeader(header, value)`, `getResponseHeader(header)
* `header`: nom du champ
* `value`: valeur du champ
* Annulation: `abort()`

### Envoi de données

La méthode **GET** permet d'**obtenir des données** mais la longueur de l'URL est limité (2048 pour IE) et sont manipulables par l'utilisateur. Cependant, cette méthode permet l'utilisation du cache.

La méthode **POST** est utilisée pour **faire quelque chose**. On l'utilise aussi pour passer de données sensibles. La taille de données maximale est définie par le serveur. Pour créer une requête avec la méthode POST, on peut utiliser XHR ou deux requêtes AJAX en même temps (_si vous avez un exemple, c'est volontiers_).

Le [slide](https://he-arc.github.io/slides-devweb/06-HTTPandAJAX.html#15.0) propose un schéma sous forme d'arbre décisionnel indiquant s'il faut choisir plutôt GET ou POST.

L'utilisation du cache permet notamment d'améliorer les performances de l'appliction. Il permet de limiter le nombre de requêtes car on va stocker des informations dans le cache du navigateur. Toute information placée dans le cache possède une date d'expiration.

_J'ai pas des masse compris ce qu'il veut dire sur son [slide](https://he-arc.github.io/slides-devweb/06-HTTPandAJAX.html#14.0) concernant la construction d'URL et l'envoie d'entêtes avec interdiction_

### Réponse

* `readystate == 4 && status == 200`
* récupérable avec `responseText` ou `responseXML`

Mais en JSON, c'est mieux !

JSON signifie JavaScript Object Notation.

[
    {nom:"Berger",  prenom:"Laurent"},
    {nom:"Borgo",   prenom:"Sébastien"},
    {nom:"Bux",     prenom:"Rémy"}
]

Par exemple, les objets répartit dans des tableaux \[\] et un objet est ainsi que ces propriétés sont définis dans des {}. Les attributs sont des paires clé-valeur.

L'avantage du JSON est qu'il est facile à lire et écrire pour un humain. Son format est totalement indépendant du langage et permet donc son utilisation dans beaucoup d'autres langages !

Pour la lecture, on utilise le parser JSON:

var users = JSON.parse(myXHR.responseText);
var myString = JSON.stringify(users);

// avec JQuery
var obj = jQuery.parseJSON('{"nom":"Berger"}');
alert(obj.nom);

Attention à ne pas utiliser la fonction `eval()`. Cette fonction évalue et exécute la chaîne de caractère. Innocement, elle retournerait donc un tableau ou un objet à partir du contenu JSON. Or, l'[article](https://javascriptweblog.wordpress.com/2010/04/19/how-evil-is-eval/) cité dans le slide indique que son utilisation est lente(dû à la compilation), qu'elle est dangereuse car permet d'exécuter un script malveillant, qu'elle est syntaxiquement moche et qu'elle hérite du contexte d'exécution, donc qu'elle peut écraser le contexte existant.

### FetchAPI

Grand successeur de XHR est native et donc plus simple que l'utilisation de JQuery. Elle possède un polyfill(ou prothèse d'émulation) permettant de garantir la fonctionnalité dans le cas où le navigateur ne l'implémente pas. Elle repose sur le principes de [promesses](https://www.promisejs.org/).

fetch("fichier.json")
    .then(function(response) {
        return response.json()
    })
    .then(function(json) {
        console.log(json);
    })
    .catch(function(error) {
        console.error("erreur", error)
    })

### Traitement d'erreurs

Il est conseillé d'utiliser les entêtes HTTP pour la gestion d'erreur, que ce soit front ou back end ! Il faut regarder les champs status ainsi que les codes d'erreur.

### Utilisabilité

Le [slide](https://he-arc.github.io/slides-devweb/06-HTTPandAJAX.html#22.0) parle notamment des requêtes XHR qui ne sont pas "bookmarkable", qu'il est important de signaler à l'utilisateur ce qu'il se passe(loading à l'écran), qu'il est important de réaliser un bon code client si l'on souhaite avoir des performances raisonnables et **surtout** qu'il est important de tester ses pages ! (Autant pour l'ergonomie que la performance)

Le [slide](https://he-arc.github.io/slides-devweb/06-HTTPandAJAX.html#23.0) suivant propose une liste de bonnes pratiques qu'on peut résumé par:

"_Rester simple, suivre les conventions et être accessible(ARIA) pour que l'utilisateur soit confortable_"

## 07 - jQuery

JQuery est une bibliothèque JS gratuite mais licenciée. Elle offre des surtout une facilité au developpement JS concernant la manipulation du DOM, du CSS mais aussi concernant les événements navigateurs, l'animation et les effets visuels mais aussi pour l'AJAX.

### Utilisation

L'inclusion en CDN(Content Delivery Network): `<script src="https://code.jquery.com/jquery-3.1.1.min.js"></script>`

L'utilisation générale:

// $() est un raccourci pour jQuery()
$(selecteur).action();

// retourne le DOM
$(document);

// cache tous les éléments h3
$("h3").hide();

// sélectionne les éléments de classe "post"
$(".post");

// un nouveau noeud
var node = $('<p>New</p>');

// Vérification que le document soit prêt dans une fct interne anonyme
$(function() {
    console.log("prêt!")
});

### Sélection d'élements dans le DOM

Le [slide](https://he-arc.github.io/slides-devweb/07-jQuery.html#4.0) présente les différentes manières de sélectionner un élement dans le document.

### Parcours

On peut parler aussi ici de "Traversing" signifiant se déplacer au travers et permettant de trouver un élements. Le [slide](https://he-arc.github.io/slides-devweb/07-jQuery.html#5.0) montre quelle fonction utiliser pour naviguer dans l'arbre du document.

### Modifications

Le [slide](https://he-arc.github.io/slides-devweb/07-jQuery.html#6.0) présente les différentes manières d'accèder, d'ajouter ou supprimer du conteu

### Accès au CSS

Le [slide](https://he-arc.github.io/slides-devweb/07-jQuery.html#7.0) montre le code pour ajouter ou supprimer une classe CSS à un élement du document.

Pour modifier les attributs d'un style, il suffit d'utiliser simplement la fonction `css(string)` avec en paramètre soit le nouveau style, soit l'attribut dont on souhaite récupérer la valeur.

### Evénements

Je vous laisse aussi consulter le [slide](https://he-arc.github.io/slides-devweb/07-jQuery.html#8.0).

### AJAX

En jQuery, l'utilisation d'AJAX est encore plus simple:

// Pour récupérer n'importe quelle donnéed
$(selector).load(URL, data, callback)

// Envoi d'une requête GET
$.get(URL, callback)

// Envoi d'une requête POST
$.post(URL, data, callback)

### Effets visuel & animations

Je vous laisse aussi consulter le [slide](https://he-arc.github.io/slides-devweb/07-jQuery.html#10.0).

### Alternatives

Parce que le 28 octobre 2017, ce cher Greut a dit:

>jQuery aussi, ça fait vieux

Et donc, il est possible d'utiliser "bling.js" qui permet de profiter du "$" sans jQuery ou encore la fonction `querySelectorAll(cssSelector)` implémenté directement dans js.

## 08 - RSS

**Really Simple Syndication**

### Qu'est-ce que c'est

La syndication est le principe de vendre du contenu à plusieurs médias. Dans le 20minutes par exemple, on peut observer des bandes-dessinées qui se retrouvent dans plusieurs autres journaux.

Dans le cadre du web, on utilise les flux RSS ou Atom. Ces flux possèdent une source et des utilisateurs s'y abonnent. Ils peuvent porter sur l'actualité, le contenu de blogs, la publication de podcasts...

### Historique

Le contenu du flux présente les données au format XML. Il a été d'abord créé en 1999, a eu plusieurs autre versions jusqu'en 2005 où le projet a été renommé "Atom". Ce projet est dorénavant développé par la communauté.

### Applications

Le but premier est de récupérer de l'informations pour la lire et potentiellement la réutiliser sur un site. Comme cité précédemment, elle permet la diffusion d'actualités, de notifications, de podcasts. L'avantage est qu'on s'abonne directement à la source de l'information cependant cela a pour conséquence d'augmenter le traffic.

Il existe de nombreux moyens de convertir ces flux RSS. L'[article](http://www.makeuseof.com/tag/14-other-ways-to-use-rss-feeds/) cité dans le slide montre 14 applications des flux allant de l'envoi par mail à la conversion en pdf.

### Agrégateurs

Un aggrégateur est donc une entité regroupant plusieurs grands flux en un seul. Nativement, ce sont par exemple les navigateurs, les clients mails ou carrément des applications dédiées. Cependant, il y a maintenant des applications Web ou plus simplement encore des extensions pour les navigateurs.

Le slide fournit une [liste](https://en.wikipedia.org/wiki/Comparison_of_feed_aggregators) comparant les différents agrégateurs de flux.

### Génération

Un flux RSS est donc simplement un fichier XML sur le serveur. Il contient des canaux avec différents "items" pour l'implémentation RSS et des "entrées" pour l'implémentation Atom.

_Je suis pas hyper sûre de ça mais on tente_

Il suffit de créer une page sur le serveur qui génére donc le fichier xml.

Pour ensuite permettre à l'utilisateur de s'y abonner, il faut placer cette ligne sur les différents pages du site:

`<link rel="alternate" href="/feed/" title="My RSS feed" type="application/rss+xml" />`

C'est donc un lien redirigeant sur la route du flux et de type "rss+xml".

Pour plus de précision, ce [lien](https://www.carronmedia.com/create-an-rss-feed-with-php/) a l'air pas mal.

### Formats

Le [slide](https://he-arc.github.io/slides-devweb/08-RSS.html#7.0) montre les différentes versions des implémentations RSS et Atom.

### Signaler la présence du flux

1. Ajouter le lien sur le flux
2. Mettre l'icône du flux (pour l'utilisateur)
3. Valider son flux [W3C](http://validator.w3.org/feed/)(toujours là pour nous valider, c'est le gars sûr)
4. Utiliser le bon MIME type pour le lien
* `application/rss+xml`
* `application/atom+xml`

### Alternatives

* Facebook OpenGraph
* Twitter Cards
* Google Schema.org
* Microformats
* JSON-LD

_Je vous laisse consulter le [slide](https://he-arc.github.io/slides-devweb/08-RSS.html#13.0) pour avoir les différents liens._

## 09 - Services Web

### Applications distribuées

La motivation est de répartir l'éxécution sur plusieurs machines. Les différents composants ou services de l'architecture communiquent au travers du réseau. Il faut tout de même prêter attention à l'hétérogénéité du système en utilisant des protocles génériques ainsi que faire preuve de suffisament d'abstraction.

Pour se faire, on utilise donc les technologies du web comme HTTP et XML ou JSON !

On voit deux types d'applications distribuées:
* REST: orienté ressources
* RPC ou SOAP: orienté service

### Service Web

Il y a deux manières de voir un service web:
* Simplement pour développer une application distribué
* Accès d'une application à des informations externes

De ce fait, on peut réaliser deux types de pages:
* WebApp: accès à une ressources via le navigateur (standard)
* ServiceWeb: accès à une ressource inter-application (HTTP + XML/JSON)

On note tous de même que consommer un service web n'est de loin pas pareil que d'en créer un.

### SOAP

_Ce serait cool de refaire cette partie, je suis pas du tout sûre de ce que je dis... Il est vraiment bancal ce slide_

**Simple Object Access Protocol** est en réalité un abus de langage. Il est plus de parler en réalité de SOA(Service Oriented Application) qui englobe les web services et qui demande l'utilisation des protocoles SOAP, WSDL(Web Service Description Language) et UDDI(Universal Description, Discovery Integration). Ces deux derniers protocles permettent(dans l'ordre) de décrire les interfaces du services et de découvrir/inscrire le service.

Le web service doit être indépendant du langage et de la plateforme et donc communiquer des informations lisibles par tous.

Concernant le vieux SOAP, le [slide](https://he-arc.github.io/slides-devweb/09-webservices.html#5.0) présente un morceau de code xml décrivant la structure d'un message.

### REST

**REpresentational State Transfer**

C'est une philosophie de laquelle on s'inspire pour architecturer un site web. Comme dit précédement, c'est une architecture orienté ressource(ROA).

Pour que le site soit "RESTful" et donc qu'il respecte les principes de cette architecture, il doit respecter les contraintes suivantes:

* Indentification des ressources (Uniform Resource Identifier)
* Manipulations des ressources par représentations (forme données à la ressources donc page HTML en général)
* Messages autodescriptifs de ce qu'il se produit
* Hypermédia... _uhm je ne sais pas ce qu'il souhaite dire ici_

Les principes de REST, plus précisément:

* URI des ressources !
* Utilisation des verbes HTTP (donc CRUD)
* POST = CREATE
* GET = READ
* PUT, PATCH = UPDATE
* DELETE = DELETE
* Les liens sont représentatifs du contenu (navigation)
* La représentation de la ressoucre est déterminée par MIME

Concernant l'idempotence et la sureté de la ressource, je vous invite à relire le chapitre "06 - HTTP & AJAX" > "Verbes HTTP".

Concernant l'URI, on préfère donc ce dernier car il est logic alors que l'autre est considéré comme physique.

Laravel respecte donc le principe REST et propose l'implémentation des fonctions suivantes:

* `index`
* `show`
* `store/create`
* `update`
* `destroy`

### Niveaux de maturité de Richardson

L'[article](https://martinfowler.com/articles/richardsonMaturityModel.html) dans le titre du slide parle des différents niveaux pour définir si une application est plus ou moins avancé en matière de philosophie REST.


* Niveau 0: POX (Plain Old XML) utilisation d'HTTP pour faire du RPC(Remote Procedure Control) et donc pas du tout REST
* Niveau 1: Identification des ressources par URI
* Niveau 2: Les verbes HTTP sont respectés !
* Niveau 3: **Hypertext As The Engine Of Application State** ou HATEOS qui permet donc de n'utiliser que les liens pour gérer l'entier des ressources.

### SOAP vs REST

Vaut-il mieux faire du REST ou du SOAP(WebService-) ?

L'avantage de SAOP est qu'il est plus flexible et extensible mais nécessite beaucoup. Il demande plus de code pour la gestion et validation des requetes et des réponses, souvent fait avec une framework comme nuSOAP. C'est la manière "entreprise" de faire.

REST est quant à lui un principe hérité du web ou tout est plus facile, plus rapide, plus lisible et plus compacte. La maintenance est facile et la tolérence aux pannes est meilleure.

On peut donc en conclure que REST est beaucoup plus abordable que SOAP mais SOAP s'intègre certainement mieux à l'interne d'une entreprise que REST.

## 10 - Responsive Web Design

### Site adaptatif

Le Responsive Web Design est le fait de pouvoir visualiser un même site sur n'importe quelle taille d'écran. Le site s'adapte à la largeur d'écran disponible et modifie uniquement sa présentation (CSS3 > orientation, taille de caractère, mode d'interaction).

Avant l'apparition du CSS3 était souvent utilisé plusieurs sites différents pour réorienter l'uilisateur sur le "sous-site" correspondant à son appareil. Or, cela demandait beaucoup de travaille pour les maintenir. Il suffit donc, de nos jours, à simplement modifier le code de présentation.

### Techniques

Les différentes techniques utilisé sont les suivantes:

* Media queries: en fonction de l'écran, on applique un style css différent sur certains élements
* Utilisation des unités reltives:
* "font-size" en "em"
* [Fluid Grid](https://www.w3schools.com/w3css/w3css_grid.asp) sont en % (même principe d'appellation que bootstrap)
* [Flexible images](https://www.w3schools.com/css/css_rwd_images.asp) sont en %

Il existe d'autres manières de faire comme l'utilisation de [grilles fixes](https://he-arc.github.io/slides-devweb/10-rwd.html#3.0).

### Media Queries

Les média queries servent donc à appliquer un style en fonction de la largeur d'un écran. On définit des points de rupture au différentes limites des écrans. Suivant dans quelle zone l'écran se trouve, la disposition graphique est modifiée.

En ce qui concerne le code, je vous laisse consulter le [slide](https://he-arc.github.io/slides-devweb/10-rwd.html#4.0).

Ce qui est cependant important de retenir est:

* @media
* min-width
* orientation
* modification des marges
* le chargement d'une feuille de style particulière suivant la taille (donc dans le html)

### Meta Tag Viewport

Le tag "viewport" a été introduit par Apple pour l'iphone puis a été standardisé. Il représente la définition qui sera rendu à l'écran.

Le principe est qu'un écran possède une certaine définition. Dans le cas de l'iphone à l'époque, il possèdait une définition de 320px. Or, cette taille n'était pas agréable pour l'utilisateur lorsqu'il naviguait sur Internet. De ce fait, Apple a créer ce viewport représentant une résolution supérieure. Elle faisait croire au site qu'elle valait 960px. Cela permet donc de voir le site avec un "dézoom" et ainsi pouvoir mieux voir le contenu d'un page malgré la faible résolution de l'écran. Je vous invite à lire cet [article](https://www.alsacreations.com/article/lire/1490-comprendre-le-viewport-dans-le-web-mobile.html) contraitement à [celui](http://www.javierusobiaga.com/blog/stop-using-the-viewport-tag-until-you-know-ho/) du slide qui est en anglais.

Le viewport apporte donc un système de conversion utile dans **TOUTES** les sections suivantes:

$ Result[\%] = target[px] / context[px] $

Target étant la réelle résolution de l'écran et le viewport étant la taille souhaitée.

_Merci de vérifier_

### Texte

Pour le texte, on possède deux unités de taille:

* "rem": correspondant à la taille par défaut d'un élement html (16px)
* "em" : taille dans l'élement courant (si le parent à subit une modification de taille, l'enfant la subira aussi)

### Fluid Grids

Je vous laisse consulté le [slide](https://he-arc.github.io/slides-devweb/10-rwd.html#9.0).

### Responsive Images

HTML5 apporte les nouveaus éléments `<picture>` & `<source>` avec leurs attributs `srcset` & `sizes`. Le besoin est donc de varier l'image utilisé suivant la résolution de l'écran. On choisit telle ou telle image qu'on dimensionne à tellle taille pour des raisons de qualités de l'image mais aussi de performances. On ne prendra pas la peine de charger une image de 4k sur un mobile avec une résolution pourrave.

Pour mieux résumer cette idée:

<img srcset="large.jpg  1024w,
      medium.jpg 640w,
      small.jpg  320w"
   sizes="(min-width: 36em) 33.3vw,
      100vw"
   src="small.jpg"
   alt="A rad wolf" />

Selon l'[article](https://css-tricks.com/responsive-images-youre-just-changing-resolutions-use-srcset/), il serait préférable d'utiliser l'élément `picture` car il serait meilleure pour le navigateur. Je vous laisse le lire en détail si intéressé.

### Flexible Images

Ici, on parle de css et donc d'éviter que l'image ne déborde de son conteneur. Pour ce faire, on utilise les propriétés:

* overflow
* max-width

### Outils de dev

* les outils dev du navigateur _classic_
* les bookmarklets suivant cet [article](https://seesparkbox.com/foundry/media_query_bookmarklet)
* le test sur un vrai mobile !

Il existe aussi certaines philosophies de développement permettant de mieux développer un site adaptatif:

* Mobile First: développer pour les petits écrans en premiers
* Offline First: développer en pensant basses performances réseau
* Progressive Web Applications: voir sous-chapitre dans "04 - HTML 5"

## 11 - HTTPS

### Sécuriser un site web

Il faut veiller à assurer plusieurs choses:

* Authentifier que le serveur est bien celui qu'il prétend
* Assuer l'intégrité et potentiellement la confidentialités des données
* Authentifier le client si nécessaire

HTTPS fournit donc ces services au travers de l'utilisation des protocoles SSL/TLS, par défaut, sur le port 443.

### SSL over TLS

SSL signifie Secure Sockets Layer.
TLS signifie Transport Layer Security.

Ces deux protocoles se trouvent dans la couche **Application** de OSI. Ils offrent les services cités dans le sous-chapitre juste au dessus.

### Rôle d'un certificat

Un certificat permet de garantir le lien entre une entité physique et une entité numérique et assure donc les différents services cités précédement. Ils contiennent une identité et un signature.

Ils sont couramment utilisé dans HTTPS mais aussi dans les mails. Ils sont délivré par une autorité de certification. Les clients possèdent eux aussi des certificats.

### Autorité de certification

C'est une entité, entreprise, enregistrée et certifiée par des autorités publiques ou de gouvernances de l'Internet. Leurs rôles est donc de vérifier l'identité, de gérer les certifications, leurs période de validité et de maintenir à jour leur liste de certificats délivrés.

Il existe cependant des certificats auto-signés qui sont eux à usage interne principalement.

### Contenu

* Version
* numéro
* chiffrement utilisé
* qui l'a délivré et sa signature
* période de validité
* clé publique du propriétaire

Je vous laisse consulter le [slide](https://he-arc.github.io/slides-devweb/11-https.html#6.0) pour avoir la liste complète.

### Composants d'une "Private Key Infrastructure"

Schéma sur le [slide](https://he-arc.github.io/slides-devweb/11-https.html#7.0).

### Scénario en HTTPS

1. Client accède au site
2. Serveur donne sa clé publique et son certificat
3. Client valide le certificat du serveur
4. Les deux partis s'échange une clé symétrique
5. Les requêtes/réponses sont chiffrées avec cette clé

Les étapes sont aussi sur le [slide](https://he-arc.github.io/slides-devweb/11-https.html#8.0) ainsi que des liens sur d'autres slides.

### Déploiement

* OpenSSl
* Obtenir un certificat auprès d'une autorité
* Configurer son serveur

Altérnatives:
* Utilisation de [Let's encrypt](https://letsencrypt.org/)
* Serveur pré-configuré comme Caddy

## 12 - Risques applicatifs des applications web

### Risque

Un risque est un bug ou une faille permettant de modifier le fonctionnement de l'application ou de modifier ses données. Il peut être présent sur **n'importe quel niveau**. Il en va donc de la responsabilité du développeur de résoudre et anticiper ces bugs.

### Injection de code

Ce risque apparaît lors de la mauvaise validation des données. Cela peut être dans un formulaire, une requête,... Aussi n'importe quel code est injectable.

### Injection SQL

C'est donc la modification d'une requête envoyé au SGBD (Système de Gestion de Base de Données). Si on arrive à deviner la structure de la BDD, il devient facile, grâce à la puissance de SQL, de réaliser n'importe quelle action.

SELECT titre, num FROM livres WHERE num=2 UNION
SELECT login, password FROM user INTO DUMPFILE 'www/exploit.txt'

Pour les éviter, il faut donc bien valider tous les champs utilisateurs, que ce soit dans les formulaires ou dans les requêtes, être très strict dans cette validation, utiliser les entités HTML et éviter les noms de champs prévisibles.

### XSS ou Cross Site Scripting

C'est le fait d'injecter du code (HTML & Script) et de le faire éxéctuer par le navigateur client.

Durant le cours, Gruni a mentionné l'exemple du forum. Il est possible d'injecter un code dans le post ou le commentaire d'un post. Une fois qu'un autre client accède à la page, le code est exécuté et le XSS est réussi.

Le principal problème de ce genre d'attaques est qu'il est possible de **tout** faire ! Que ce soit de la redirection, de la lecture de cookie & sessions, d'envoyer n'importe quelle information à un serveur mais aussi de modifier la page.

Il existe trois types de XSS:

* Reflected XSS: affichage d'une partie de la requête
* Stored XSS: stockage dans la BDD et exécution dans lors de l'affichage (comme le forum)
* DOM based XSS: exécuté lors de la modification du DOM (affichage du cookie lors d'un clique sur un bouton par exemple)

### CSRF ou Cross Site Request Forgery

_Aussi nommé Sea Surf_

Le principe est de faire réaliser une action à l'insu de l'utilisateur avec ses propres informations et "credentials", donc identité(login, password, etc).

C'est par exemple l'envoi d'un mail proposant un lien sur une site ressemblant à un site officiel, lui demander de se connecter et ainsi récupérer ses informations.

### Phishing

_Hameçons ou filoutage_ est un technique pour obtenir des informations dans le but d'usurper une identité ou de vendre cette dernière. Cette attaque est difficile à contrer pour le développeur est c'est donc à l'utilisateur d'être sensible à cette dernière.

Cependant, il n'est pas toujours facile de bien lire les URLs ou de reconnaître si un site est officiel.

Dans les URLs il est de plus en plus difficile à lire car les personnes malveillantes vont chercher des caractères uniques peu connu et similairement rendu par les navigateurs.

### Risques non liés à l'application

Comme cité dans l'introduction de ce chapitre, les bugs et failles d'un système se trouvent partout, dans n'importe quelle couhce du système.

Les endroits où se trouvent fréquenement des bugs sont:

* Internet of Things (IoT): tous les petits périphériques commes les caméras, les télévisions, les montres connectés, etc
* Deny of Serice (DoS): but de rendre indisponible un service, notamment par une surcharge du traffic
* Spoofing d'IP, DNS ou ARP: usurpation d'identité
* Buffer Overflows: utilisé les failles du languages pour accèder à un emplacement mémoire spécifique
* Trojans ou Backdoors: Virus ou utilisation d'une entré non-sécurisé dans un système
* Découverte de mots de passe: utilisation de rainbow table ou de brutforce pour deviner un accès
* Social Engineering: Soutirer de l'information en se rendant physiquement vers l'entité visée

### Mots de passe

Il semblerait que 30% des utilisateurs utilisent un mot de passe du top 10'000 des mots de passe. On peut donc en conclure qu'un mot de passe est facilement devinable. De plus, les mots de passes choisis laisse transparaître certaines de nos habitudes. Lors du choix d'un mot de passe, pour pouvoir le retenir facilement, on s'inspire de ce qui nous entoure. Ils est donc difficile de demander à un utilisateur de choisir un mot de passe consiédéré comme fort puis de lui demander de constement le changer.

Suivant les études réalisés sur les mots de passes, de nouvelles recommandations sont sorties en 2017. Elles consitent en:

* La longueur est mieux que les caractères spéciaux
* Un mot de passe ne doit être changé qu'en cas de nécessité (s'il est connu ou si le système est corrompu)
* Autoriser et promouvoir l'utilisation de "passwords manager"
* Utiliser l'authentification à double facteurs (2FA)

### Collecte d'informations

Toutes informations est utile pour un attaquant car tout peut être utilisé comme une faille. Le développeur doit donc donner le minimum d'informations possible et ne laisser accès qu'au nécessaire.

### Bonnes pratiques

* Configuration stricte du serveur
* Validation de toutes les entrées (requêtes, formulaires)
* Filtrage et encodage des entrées
* Attention à l'affichage de donneés saisies (penser XSS)
* Tester ses formulaires comme si on souhaitait les attaquer
* Contrôler un maximum de paramètre (même si redondant)
* Utiliser un framework(car implémente déjà un bon nombre de bonnes pratiques)
* Utiliser des logiciels de tests sur l'application

### Top 10 de l'OWASP

1. Injection
2. Broken Authentification (Tout ce qui concerne les "credentials" donc identité, mots de passes, sessions, etc)
3. Sensitive Data Exposure (Exposition de données sensible)
4. XML External Entites (Balise XML permettant d'exécuter du code)

## Workshop de Manuel Schmalstieg

### Fonts & Typographie

Les interfaces sont réellement le texte. La police choisie doit donc être claire mais aussi bien représenter graphiquement l'entité qu'elle définit.

Au début était utilisé les fonts stack, c-à-d les polices fournit par l'OS.

En 2010 apparaît les webfonts permettant le chargement de police dans le navigateur.

En 2016, Wordpress retourne à l'utilisation des fonts stack notamment pour des questions de performances. (Chargement d'un fichier supplémentaire ralentit le rendu de la page)

### Couleurs

Les couleurs choisient pour une interface permettent de définir réellement l'entité. Les couleurs font partie intégrante de l'image de la marque ou du produit. Il est donc important de bien les choisir.

Sont souvent utilisé les palettes de couleurs. Elles permettent non seulement de définir les couleurs du site ou de l'application mais peuvent aussi être utilisé pour les marketing.

Lors qu'on réalise une palette de couleur et qu'on les attribue à différent composant (titre, paragraphe, lien, boutons, ...), on veille à ce que la lisibilité soit suffisante mais aussi que l'interface soit visible pour les personnes daltioniennes.

On utilise donc un [ratio de contraste](https://contrast-ratio.com) mais on vérifie aussi l'[accessibilité](https://24ways.org/2012/colour-accessibility/).

### CSS Layout

Dans cette partie a été présenté les aspects suivants:

* Media Queries et Breakpoint
* Vision "Mobile First"
* FlexBox
* Grid Layout

Je vous laisse donc consulter les chapitres correspondant. Rien de plus n'a été introduit durant cette présentation.

## Abréviations ❤❤❤

- **csrf**: cross site request forgery
- **xxe**: external xml entity
- **xss**: cross site scripting
- **uri**: uniform ressource identificator
- **url**: uniform ressource location
- **urn**: uniform ressource name
- **polp**: principle of least privilege
- **orm**: object relational mapping
- **mvc**: model view controller
- **ioc**: inversion of control
- **acl**: acces control list
- **yagni**: you ain't gonna need it
- **cli**: command line interface
- **html**: hypertext markup language
- **aria**: accessible rich internet applications
- **dom**: document object model
- **ajax**: asynchronous javascript and xml
- **http**: hypertext transfer protocol
- **xhr**: xml http request
- **api**: application programming interface
- **xml**: extensible markup language
- **json**: javascript object notation
- **cdn**: content delivery network
- **rss**: really simple syndication
- **ifttt**: if this than that
- **soap**: simple object acess protocol
- **wsdl**: web service description language
- **uddi**: universal discovery description and integration
- **rest**: representational state transfer
- **ssl**: secure socket layer
- **tls**: transport layer security
- **pki**: public key infrastructure
- **sop**: same origin policy
- **cors**: cross origin ressource sharing