Si, redis persiste bien ses données sur le disque dur. Il n'offre pas les mêmes garanties qu'une base de données SQL, mais ça reste suffisant pour ce cas d'usage. Au pire, on aurait régénérer les entrées de redis en reparcourant tous les contenus et commentaires.
Est-ce que vous avez envisagé une solution à base de signature des URLs ?
Si linuxfr signe les URLs des images avec HMAC par exemple, le proxy peut vérifier que l'URL a bien été générée par linuxfr, et autoriser la requête. Et du coup pas besoin de stocker une liste d'URLs.
Il y a d'autres problématiques que je n'ai pas abordées dans la dépêche, dont une importante est l'aspect modération.
Par exemple, si une personne affiche une image nazie sur le site, on saura l'enlever des contenus et commentaires, mais l'URL de cette image sur img.linuxfr.org resterait valide. Du coup, cette même personne pourrait poster cette URL sur d'autres forums, ce qui pourrait potentiellement nous causer des ennuis avec la justice. J'ai donc implémenté un système pour bloquer les images.
Plus vicieux, cette même personne pourrait utiliser la prévisualisation des commentaires pour récupérer cette URL sans poster le contenu. L'équipe de modération du site ne verrait alors pas passer l'image et ne pourrait donc la bloquer. Nous avons donc également une galerie des dernières images utilisées sur le site dans la partie modération.
D'autre part, img.linuxfr.org garde en cache pour une durée assez courte les erreurs qu'il rencontre lorsqu'il va chercher une image distante (pour éviter de bourriner le serveur en question). Du coup, redis s'est trouvé être la solution la plus simple pour développer ce composant.
[^] # Re: redis vs signature
Posté par Bruno Michel (site web personnel) . En réponse à la dépêche Un nouveau reverse-proxy cache pour les images externes sur LinuxFr.org. Évalué à 10.
Si, redis persiste bien ses données sur le disque dur. Il n'offre pas les mêmes garanties qu'une base de données SQL, mais ça reste suffisant pour ce cas d'usage. Au pire, on aurait régénérer les entrées de redis en reparcourant tous les contenus et commentaires.
Oui, j'ai même fait plus que l'envisagée, je l'ai codée. En remontant un peu dans le temps, on peut voir https://github.com/nono/img-LinuxFr.org/blob/aa39a39d240797a44d34cf2d61b3c8984157b03b/img.go. D'un point de vue conceptuel, c'est une idée assez séduisante.
Il y a d'autres problématiques que je n'ai pas abordées dans la dépêche, dont une importante est l'aspect modération.
Par exemple, si une personne affiche une image nazie sur le site, on saura l'enlever des contenus et commentaires, mais l'URL de cette image sur img.linuxfr.org resterait valide. Du coup, cette même personne pourrait poster cette URL sur d'autres forums, ce qui pourrait potentiellement nous causer des ennuis avec la justice. J'ai donc implémenté un système pour bloquer les images.
Plus vicieux, cette même personne pourrait utiliser la prévisualisation des commentaires pour récupérer cette URL sans poster le contenu. L'équipe de modération du site ne verrait alors pas passer l'image et ne pourrait donc la bloquer. Nous avons donc également une galerie des dernières images utilisées sur le site dans la partie modération.
D'autre part, img.linuxfr.org garde en cache pour une durée assez courte les erreurs qu'il rencontre lorsqu'il va chercher une image distante (pour éviter de bourriner le serveur en question). Du coup, redis s'est trouvé être la solution la plus simple pour développer ce composant.