Permet le rendu des fichiers html dans le navigateur #1

Melcore · 2023-05-11T21:14:34Z

Melcore commented

2023-05-11 21:14:34 +00:00

Afin d'ajouter réellement des fonctionnalités de blog, on peut rendre les fichiers html, css, js normalement sans pygments.

J'ai pas les moyens de tester si y a pas de bug, et je voulais soumettre l'idée rapidement.

Afin d'ajouter réellement des fonctionnalités de blog, on peut rendre les fichiers html, css, js normalement sans pygments. J'ai pas les moyens de tester si y a pas de bug, et je voulais soumettre l'idée rapidement.

Melcore added 1 commit 2023-05-11 21:14:35 +00:00

00a2df14ff Permet le rendu des fichiers html dans le navigateur

Afin d'ajouter réellement des fonctionnalités de blog, on peut rendre les fichiers html, css, js normalement sans pygments.

J'ai pas les moyens de tester si y a pas de bug, et je voulais soumettre l'idée rapidement.

mdk commented

2023-05-12 14:23:20 +00:00

À première vue, tel que c'est implémenté, ça ne fonctionne pas car paste_to_html n'est appelée que si 'html' est dans l'entête Accept, ce qui n'est pas le cas lorsque le navigateur demande un CSS ou un JS.

Côté coloration syntaxique, on pourrait s'en sortir pour le CSS et le JS :

On a toujours 'html' dans le Accept quand le navigateur veut afficher la page donc peut le présenter joliment avec la coloration syntaxique.
On a jamais 'html' dans l'entête Accept quand le navigateur veut un fichier JS ou CSS donc on peur le fournir "brut".

Et vu que le test actuel (sans cette PR) est "html" in headers.get("Accept") alors le comportement est déjà le bon, pas besoin de toucher au code pour délivrer du JS et du CSS proprement.

Par contre pour le HTML c'est foutu on a aucun moyen de savoir si l'utilisateur veut la version "brute" (pour faire faire le rendu HTML a son navigateur), ou "coloriée" (pour partager du HTML a ses amis).

Bon pour le HTML on a une solution : il suffit de mettre du HTML inline dans le Markdown, ça aussi ça fonctionne déjà, démo :

https://p.afpy.org/summary.md

Donc la seule chose qui manque pour faire ce que tu veux c'est juste d'enlever bleach.

Comme ça dans du Markdown on pourrait rajouter des balises <script, <meta, <form, etc, etc...

Il reste à réfléchir à l'aspect sécu d'enlever Bleach.

Sans Bleach on permet d'exécuter du JS sur le domaine afpy.org (en changeant l'origine de p.afpy.org à afpy.org, ce qui est autorisé.

Est-ce que ça ouvre des attaques CSRF contre afpy.org, peut-être, mais est-ce qu'on s'en fout vu que ça sera bientôt un site static ? Peut-être.

Est-ce que ça ouvre des attaques CSRF contre git.afpy.org, discuss.afpy.org, ... ? Je pense mais ça mérite de creuser.

À première vue, tel que c'est implémenté, ça ne fonctionne pas car paste_to_html n'est appelée que si `'html'` est dans l'entête `Accept`, ce qui n'est pas le cas lorsque le navigateur demande un CSS ou un JS. Côté coloration syntaxique, on pourrait s'en sortir pour le CSS et le JS : - On a toujours 'html' dans le Accept quand le navigateur veut afficher la page donc peut le présenter joliment avec la coloration syntaxique. - On a jamais 'html' dans l'entête Accept quand le navigateur veut un fichier JS ou CSS donc on peur le fournir "brut". Et vu que le test actuel (sans cette PR) est `"html" in headers.get("Accept")` alors le comportement est déjà le bon, pas besoin de toucher au code pour délivrer du JS et du CSS proprement. Par contre pour le HTML c'est foutu on a aucun moyen de savoir si l'utilisateur veut la version "brute" (pour faire faire le rendu HTML a son navigateur), ou "coloriée" (pour partager du HTML a ses amis). Bon pour le HTML on a une solution : il suffit de mettre du HTML inline dans le Markdown, ça aussi ça fonctionne déjà, démo : https://p.afpy.org/summary.md Donc la seule chose qui manque pour faire ce que tu veux c'est juste d'enlever bleach. Comme ça dans du Markdown on pourrait rajouter des balises `<script`, `<meta`, `<form`, etc, etc... Il reste à réfléchir à l'aspect sécu d'enlever Bleach. Sans Bleach on permet d'exécuter du JS sur le domaine `afpy.org` (en changeant l'origine de p.afpy.org à afpy.org, [ce qui est autorisé](https://developer.mozilla.org/fr/docs/Web/Security/Same-origin_policy#changer_lorigine). Est-ce que ça ouvre des attaques CSRF contre `afpy.org`, peut-être, mais est-ce qu'on s'en fout vu que ça sera bientôt un site static ? Peut-être. Est-ce que ça ouvre des attaques CSRF contre `git.afpy.org`, `discuss.afpy.org`, ... ? Je pense mais ça mérite de creuser.

mdk commented

2023-05-25 13:41:40 +00:00

Par contre, on pourrait autoriser l'upload d'image, le rendu d'une image ... c'est l'image pas modifiée.

Ça permettrai d'utiliser des images (![]()) côté Markdown.

Par contre, on pourrait autoriser l'upload d'image, le rendu d'une image ... c'est l'image pas modifiée. Ça permettrai d'utiliser des images (`![]()`) côté Markdown.

This pull request can be merged automatically.

This branch is out-of-date with the base branch

You are not authorized to merge this pull request.

You can also view command line instructions.

Step 1:

From your project repository, check out a new branch and test the changes.

git checkout -b html_render main

git pull origin html_render

Step 2:

Merge the changes and update on Gitea.

git checkout main

git merge --no-ff html_render

git push origin main

Sign in to join this conversation.

No reviewers

No Label

No Milestone

No project

No Assignees

2 Participants

Notifications

Due Date

The due date is invalid or out of range. Please use the format 'yyyy-mm-dd'.

No due date set.

Dependencies

No dependencies set.

Reference: AFPy/pasteque#1