miniatures GD

1 files changed, 47 insertions, 0 deletions

diff --git a/à faire après livraison.txt b/à faire après livraison.txt
new file mode 100644
index 0000000..db20759
--- /dev/null
+++ b/à faire après livraison.txt
@@ -0,0 +1,47 @@
+Le reste du site
+
+Miniatures avec imagemagick
+
+possibilité de regarder une image en grand dans une fenêtre javascript
+OU au moins dans une "page" dotée d'un bouton pur sortir (avec GD? avec imagemagick?)
+
+
+Protection contre les falsifications de requête inter-site - CSRF
+
+ici une explication simple avec un exemple simpliste
+(les GET servent à la navigation, les POST à l'action)
+https://www.ibm.com/docs/fr/order-management?topic=ssgtjf-com-ibm-help-sfs-cpqsolution-doc-customization-c-wcc-crosssiterequestforgery-html
+
+notre site est-il concerné? le navigateur peut toujours enregistrer les identifiants (cookie ou pas), la session sur le serveur sera donc maintenue
+protection: on ajoute un formulaire caché avec une valeur aléatoire cryptée utilisable une seule fois (=jeton)
+
+"Vous pouvez rendre chaque jeton utilisable une seule fois et ainsi éviter de rejouer plusieurs fois la même requête.
+Les jetons sont stockés dans le back-office.
+Une rotation des jetons est effectuée quand le nombre maximum a été atteint, les plus vieux en premier.
+Chaque jeton peut être lié à une URL spécifique.
+Si un jeton est intercepté, il ne peut pas être utilisé dans un autre contexte.
+Si besoin, les jetons peuvent être attachés à une adresse IP spécifique.
+Depuis la version v2.1, les jetons peuvent être réutilisés (par exemple pour les requêtes AJAX).
+Si vous n’utilisez pas un framework qui gère la protection CSRF pour vous, jetez un oeil à Anti-CSRF."
+
+une bibli qui fait ça: https://github.com/paragonie/anti-csrf
+
+"sessions, penser aux attaques CSRF (cross-site request forgery):
+ça consite à faire qu'un utilisateur connecté avec une session envoie malgré lui une requête GET ou POST qu'un hacker aura cachée par exemple dans une fausse image clicable
+- solution: faire qu'un GET seul dans une session ne suffise pas à effectuer une action (les GET ne doivent servir qu'à afficher la bonne page), une attaque sur un POST est possible aussi mais plus difficile et nécessite d'injecter du javascript
+- on peut demander à l'utilisateur une vérification supplémentaire avant chaque action, mais c'est plutôt chiant
+- il y a la méthode des jetons, "nonces" et horodatage
+- vérifier le "référent", c'est à dire l'URL de la page d'où vient normallement la requête"
+infos: https://fr.wikipedia.org/wiki/Cross-site_request_forgery
+
+
+Upload de musique/vidéo
+Ajout de liens youtube, spotify, etc
+
+Version avec base de données
+
+Site bilingue (nécessite la base de données)
+
+Editeur tout AJAX (pas juste les images)
+
+Utilisation de l'éditeur sans recharger la page