Pour un forum entièrement privé (sans accès anonyme), l’absence d’une option de média sécurisé dans la configuration de stockage local par défaut me semble être une énorme omission. Je ne serais pas surpris que beaucoup de personnes gérant des forums privés ne réalisent pas que toutes les pièces jointes de leurs publications sont accessibles publiquement (si l’on connaît l’URL). Si le texte de ma publication ne peut pas être consulté anonymement, j’aurais intuitivement pensé que les pièces jointes de cette publication ne le pouvaient pas non plus.
Vaut-il la peine de soumettre un ticket demandant cette fonctionnalité pour voir quel type de soutien elle obtiendrait ? Existe-t-il déjà un tel ticket ? Ce problème est actuellement un obstacle majeur pour notre petit groupe à budget limité qui tente de déployer Discourse dans un environnement où nous possédons déjà le matériel d’hébergement et ne voulons pas payer pour un stockage cloud (en particulier aux tarifs d’AWS S3) simplement pour nous assurer que nos médias ne sont pas consultables anonymement.
Par ailleurs, veuillez excuser la possible naïveté de cette question. Mais il existe déjà une prise en charge de buckets distincts pour les téléversements et les sauvegardes, n’est-ce pas ? Serait-il difficile de prendre en charge un troisième bucket pour les téléversements sécurisés ? Les téléversements publics iraient dans le bucket public, les téléversements sécurisés dans le bucket sécurisé, et aucune ACL individuelle sur les objets ne serait nécessaire. Et si le statut de sécurité d’un objet changeait, il pourrait simplement être déplacé d’un bucket à l’autre ?
Je pense que c’est assez de travail. Au moins une journée de travail, mais peut-être une semaine ?
L’hébergement Cdck, qui finance le développement, utilise S3 pour les uploads, donc seuls les sites auto-hébergés sans budget pour S3 sont intéressés, à condition qu’ils n’exigent qu’une connexion.
Si vos utilisateurs voient des liens de partage vers vos ressources, ils pourraient tout aussi bien les télécharger pour les partager. Cela ne semble pas être un gros problème.
Je ne suis pas fou à lier de penser qu’il est étrange que le texte des messages soit protégé mais pas les pièces jointes, non ?
Il y a une grande différence entre le partage intentionnel et le partage accidentel. Évidemment, il n’existe aucun moyen réel d’empêcher le premier. Mais le second peut se produire dès maintenant simplement parce que les gens ne comprennent pas la technologie sous-jacente. Pensez aux notifications par e-mail pour les messages contenant des liens vers des images jointes, qui sont involontairement transférées à des non-membres. Une option pour supprimer les pièces jointes dans les e-mails, qui ne soit pas liée à la fonctionnalité de média sécurisé, pourrait être une bonne alternative dans ce cas.
Même lorsque les gens partagent intentionnellement des liens vers des pièces jointes, ils ont peut-être simplement oublié qu’ils provenaient d’une catégorie protégée. Mais dans un monde idéal, le lien vers une pièce jointe devrait être inutile pour quiconque n’a pas accès à cette catégorie.
Un bug actuel ou futur dans l’une des implémentations S3 pourrait également permettre l’énumération anonyme des ressources dans un bucket ou la possibilité de deviner et de forcer les URL des objets par force brute. Dans un monde idéal, je voudrais que mon interface S3 locale soit isolée par un pare-feu d’Internet, de sorte que seul le serveur Discourse puisse y accéder directement.
Pas fou du tout. Mettre en place des téléversements sécurisés pour les configurations non S3 n’est certainement pas quelque chose que je m’oppose à développer. C’est juste que nous n’avons aucune urgence ou pression pour créer cette fonctionnalité et le changement n’est pas trivial.
Nous avons occasionnellement des stagiaires et des projets d’audition ; c’est certainement le type de projet qui pourrait s’intégrer dans l’une de ces catégories.
Avez-vous des réflexions sur la faisabilité de cette approche comme une solution plus simple pour les médias sécurisés sur un stockage autre qu’AWS S3 ?
J’ai une petite astuce qui, je pense, permettrait d’assurer des uploads sécurisés pour les sites nécessitant une connexion.
En gros, vous configurez Authentication Based on Subrequest Result | NGINX Documentation pour les uploads. Le seul problème est que je ne trouve pas d’URL qui renvoie un 403/401 lorsque l’option « connexion requise » est activée ; ainsi, tenter d’accéder à un upload sans être connecté provoque une erreur 500. Cela ne se produirait que si quelqu’un possédait une URL d’upload et tentait d’y accéder sans être connecté, donc cela ne semble pas si grave.
Cela ressemble à ceci :
# JP
location = /auth {
internal;
proxy_pass http://discourse/categories;
proxy_pass_request_body off;
proxy_set_header Content-Length "";
proxy_set_header X-Original-URI $request_uri;
}
# END JP
location ~ ^/uploads/ {
auth_request /auth; #$JP
# NOTE: il est vraiment agaçant de ne pas pouvoir simplement définir les en-têtes
# au niveau supérieur et les hériter.
#
Nous n’avons aucun projet de créer une fonctionnalité de bucket distincte pour les téléversements sécurisés, ni de rendre les téléversements sécurisés compatibles avec des configurations autres que S3 ou des configurations sans ACL. Nous pourrions envisager de le faire à l’avenir si la demande est suffisamment forte pour justifier que nous consacrions du temps et des ressources à cet effort.
Pourquoi utilise-t-il https://hashhackersforum.s3.us-east-2.amazonaws.com/optimized/2X/3/3204e85df407adfce19e105308248aee8b3b3f57_2_690x424.png?X-Amz-Algorithm=AWS4-HMAC-SHA256&X-Amz-Credential=AKIAU5WBGG5Z7FNHQEIS%2F20210415%2Fus-east-2%2Fs3%2Faws4_request&X-Amz-Date=20210415T025617Z&X-Amz-Expires=300&X-Amz-SignedHeaders=host&X-Amz-Signature=15c9118929ccd9c24a9594ab02a47e900269b9d921d41679a317e29d6174c2bc au lieu de https://forum.cdn.hashhackers.com/optimized/2X/3/3204e85df407adfce19e105308248aee8b3b3f57_2_690x424.png?X-Amz-Algorithm=AWS4-HMAC-SHA256&X-Amz-Credential=AKIAU5WBGG5Z7FNHQEIS%2F20210415%2Fus-east-2%2Fs3%2Faws4_request&X-Amz-Date=20210415T025617Z&X-Amz-Expires=300&X-Amz-SignedHeaders=host&X-Amz-Signature=15c9118929ccd9c24a9594ab02a47e900269b9d921d41679a317e29d6174c2bc alors que j’ai bien saisi l’URL du CDN ?
Je n’ai rien contre ignorer ce message, mais nous avons activé les médias sécurisés, ce qui rend impossible l’utilisation d’un CDN. Ce message ne devrait probablement pas s’afficher sur les sites où l’option secure_media est activée.
Un CDN peut tout de même être utilisé pour tous les actifs JS, ce qui rend votre site beaucoup plus rapide à afficher pour les utilisateurs du monde entier.
C’est cool. Ce n’était pas clair pour moi que Discourse traiterait les fichiers statiques différemment. Je pense que je dois relire tous les fils de discussion ici.
Après la mise à niveau vers la version 2.8.0.beta1, mes badges utilisant des URLs S3 authentifiées ne fonctionnent plus. Tout fonctionnait correctement avant la mise à niveau.
J’ai vérifié la table uploads et la valeur de la colonne secure est true.
Ah… encore un endroit qui rend les téléchargements sécurisés alors qu’ils ne devraient pas l’être. Les badges ne devraient pas être marqués comme sécurisés car ce sont essentiellement des images publiques, comme les avatars, les logos de catégories et autres éléments similaires. Je devrai apporter une correction pour m’assurer que les images de badges ne sont pas marquées comme sécurisées, ainsi qu’un script de migration pour corriger celles qui le sont déjà.
Je suis surpris que cela ait fonctionné pour vous, rien dans la version 2.8.0 n’aurait dû affecter cela.
Merci pour votre réponse. C’est la première fois que j’utilise Ruby et je suis ravi de la clarté de ce langage. Après quelques heures de débogage, je pense avoir identifié où regarder. Je suppose que j’ai fait l’inverse de ce que vous avez dit J’ai ajouté quelques lignes dans le modèle Badge et maintenant il peut charger les images. Je vois aussi qu’il y a un indicateur for_site_setting là-bas. Je crois qu’il s’appuie sur cette information pour ajuster la ACL des objets sur S3, et mettre false pour cette colonne.
app/models/badge.rb
def image_url
if image_upload_id.present?
return upload_cdn_path(image_upload.url) if !image_upload.url.include?(SiteSetting.Upload.absolute_base_url)
uri = URI.parse(image_upload.url)
Rails.application.routes.url_for(
controller: "uploads",
action: "show_secure",
path: uri.path[1..-1],
only_path: true
)
end
end
Je vais examiner ce qui changera lors de la prochaine mise à niveau pour en savoir plus à ce sujet.
Pourriez-vous me dire quelle est la meilleure version à utiliser en production ?
Merci !
J’espère pouvoir contribuer davantage à la base de code à l’avenir.
Le changement que tu as apporté au modèle de badge fonctionnera certainement, et c’est formidable que tu aies réussi à le mettre en place dès ta première utilisation de Ruby ! Cependant, je vais quand même corriger le problème principal : les badges ne devraient pas être marqués comme sécurisés.
Notre branche tests-passed est la meilleure version à utiliser en production, car elle intègre toutes les dernières corrections dès qu’elles sont disponibles. Cependant, certaines personnes préfèrent peut-être rester sur la branche bêta, qui reçoit des correctifs et des modifications toutes les quelques semaines environ.
Je te tiendrai informé dès que la correction concernant le marquage des badges comme sécurisés sera terminée.
…mais je me demande si le problème est lié à votre commentaire ici ?
Est-il pris en charge que les utilisateurs téléversent des avatars lorsque le téléversement sécurisé des médias est activé ? Pour l’instant, je rencontre une erreur, mais je me demande si cela est dû au fait que les avatars sont téléversés dans le même bucket où l’accès public n’est pas autorisé…
1 « J'aime »
Canapin
(Coin-coin le Canapin)
A scindé ce sujet ()
126
J’ai récemment renommé « médias sécurisés » et les paramètres associés en « uploads sécurisés » car cela ne s’applique pas seulement aux images/vidéos, etc., et tout le monde y fait généralement référence comme à des uploads sécurisés de toute façon. Le commit principal pertinent est ici :
L’OP de ce sujet a maintenant été mis à jour pour refléter cela.
J’ai ajouté quelques lignes dans le modèle Badge et maintenant il peut charger les images. Je vois aussi qu’il y a un indicateur for_site_setting là-bas. Je crois qu’il s’appuie sur cette information pour ajuster la ACL des objets sur S3, et mettre false pour cette colonne.