#Assets

Le dossier assets/ contient les fichiers statiques d’un thème : sa feuille de style, ses éventuelles icônes vectorielles. Deux extensions sont admises, .css et .svg, et la liste est fermée.

Cette page explique comment un asset reçoit son adresse, comment il est réellement servi — par une route, et non depuis un disque — et pourquoi il n’y a pas de JavaScript.

#Obtenir l’adresse d’un fichier

Un seul chemin : le filtre asset_url, qui prend le nom du fichier.

{{ 'theme.css' | asset_url | stylesheet_tag }}

<link rel="stylesheet" href="/theme-assets/8f2c…/theme.css">

asset_url colle le nom derrière theme_base, qui vaut /theme-assets/<id-du-thème>. stylesheet_tag enveloppe le résultat dans une balise link, en échappant l’adresse.

Pour une image :

<img src="{{ 'motif.svg' | asset_url }}" alt="">

#Comment un asset est servi

Pas depuis le disque. La route /theme-assets/<theme>/<fichier> lit le contenu en base, dans la table des fichiers du thème.

Content-Type: text/css; charset=utf-8
Cache-Control: private, max-age=60
Vary: Cookie, Host
X-Content-Type-Options: nosniff
Content-Security-Policy: default-src 'none'; style-src 'unsafe-inline'; img-src data:; sandbox
Content-Disposition: inline

Not found

#Pourquoi une route, et pas un fichier statique

Parce que les assets sont modifiables. L’éditeur de code du CMS et le CLI les réécrivent ; un fichier posé sur le disque au moment de l’installation ne suivrait pas. Un thème vit en base une fois installé — voir Anatomie.

#Les quatre gardes de la route

1. L’extension décide du type servi

   .css devient text/css, .svg devient image/svg+xml. Toute autre extension répond 404 avant la moindre requête en base. Renvoyer le type déclaré par le fichier lui-même permettrait de servir du HTML sous le domaine d’un client — donc du script, avec ses cookies.

2. Le nom est revalidé

   Même expression régulière qu’à l’écriture. Le nom est recomposé, jamais concaténé depuis l’URL : ..%2F et autres échappements ne peuvent pas sortir du dossier assets.

3. Le thème doit être publié

   Un brouillon en cours de refonte reste invisible même si l’on devine son identifiant. La lecture publique est ouverte — les visiteurs d’un site n’ont évidemment aucun compte — mais uniquement pour ce qui est en ligne.

4. Le thème doit appartenir au site de l’hôte

   Sans ce test, l’identifiant d’un thème publié suffisait à le faire servir sous le domaine de n’importe quel autre client. C’est l’un des trois défauts qui, composés, ouvraient une exécution de script sous l’origine de n’importe quel site.

#Le cache

Cache-Control: private, max-age=60, avec Vary: Cookie, Host.

private et non public, parce que la réponse dépend de deux choses invisibles dans l’URL : l’hôte appelant, et la session — le propriétaire d’un site en brouillon voit ce qu’un anonyme ne voit pas, et c’est ce qui fait marcher l’aperçu. Un cache partagé pouvait mémoriser la réponse servie au propriétaire et la redistribuer.

Soixante secondes, et c’est court exprès : qui retouche son CSS dans l’éditeur doit voir l’effet en rechargeant, pas dans une heure. Le cache du navigateur reste en place, et c’est lui qui portait l’essentiel du gain — une page vitrine recharge la même feuille de style à chaque écran.

#La feuille de style n’est pas un template

C’est pour cela que les quatre thèmes posent leurs réglages en variables CSS dans la coquille, et nulle part ailleurs :

<style>
  :root {
    --accent: {{ settings.accent }};
    --accent-sombre: {{ settings.accent | teinte: -18 }};
    --largeur: {{ settings.largeur }}px;
  }
</style>

.bouton {
  background: var(--accent);
  border-radius: var(--bouton-rayon);
}

.enveloppe {
  max-width: var(--largeur);
  margin-inline: auto;
}

L’avantage n’est pas seulement de faire marcher les réglages : la feuille de style reste un fichier CSS ordinaire, que l’éditeur colore, que le navigateur met en cache, et qu’on peut relire sans démêler du Liquid.

Les quatre thèmes n’ont chacun qu’un seul asset — theme.css, entre 11 et 23 Ko. Rien n’interdit d’en découper plusieurs : une @import relative depuis theme.css résout bien vers le même dossier servi.

#Ce que la page peut charger d’ailleurs

Un site public est servi avec une politique de sécurité de contenu, et elle borne ce qu’une feuille de style peut aller chercher :

#Les SVG

Admis, et servis avec trois protections qui vont ensemble.

Un SVG est un document scriptable : ouvert dans un onglet, image/svg+xml exécute ses balises script, et nosniff n’y change rien. D’où :

• une CSP sandbox posée par la route elle-même, et non par le proxy — le proxy exclut les chemins finissant par une extension d’image, il ne passe donc jamais sur cette réponse ;
• un Content-Disposition: inline; filename="…", qui laisse le fichier se rendre comme une image dans un img ou en CSS — le seul usage prévu — mais empêche son ouverture directe d’être interprétée comme une page ;
• le nosniff, qui interdit au navigateur de deviner un autre type.

#Pourquoi il n’y a pas de JavaScript

Le blocage est double, et c’est voulu. La liste d’extensions arrête le fichier à l’écriture ; la CSP du site public arrête le script au navigateur, puisque script-src n’admet que l’origine et un nonce que le thème n’a aucun moyen de connaître.

#Ce qu’on fait à la place

Le CSS moderne couvre l’essentiel de ce pour quoi un thème vitrine ouvrait un fichier JavaScript :

Ce dernier mérite un mot : le formulaire de contact des quatre thèmes poste vers /api/contacts, la route redirige, et la page se rend à nouveau avec page.demande valant merci ou erreur. Un message de remerciement sans une ligne de script. Voir Objets.

#Les erreurs fréquentes

#Pages voisines