Les blocked onebox domains sont ignorés dans la version 2.9.0beta2 (c6265eec6b).
Nous avons :
Ces domaines sont derrière des murs OAuth et le onebox essaie de prévisualiser les domaines et obtient l’URL de connexion OAuth à la place.
Les blocked onebox domains sont ignorés dans la version 2.9.0beta2 (c6265eec6b).
Nous avons :
Ces domaines sont derrière des murs OAuth et le onebox essaie de prévisualiser les domaines et obtient l’URL de connexion OAuth à la place.
Ce paramètre n’a d’effet que sur le serveur — votre navigateur tentera toujours de créer une prévisualisation onebox.
Je peux comprendre que cela puisse être inattendu.
Si vous soumettez le message, la prévisualisation onebox s’affiche-t-elle après le rendu par le serveur, ou affiche-t-elle l’URL brute comme vous vous y attendez ?
Oui, cela ne semble pas fonctionner correctement… ![]()
Pouvez-vous essayer d’ajouter « auth.pi-hole.net » dans votre paramètre de domaines onebox bloqués ?
Nous avons fait en sorte que ce paramètre suive les redirections mais ne bloque le domaine spécifié que s’il s’agit de la destination finale.
Je viens d’essayer et cela fonctionne toujours en une seule boîte. Je pense que c’est parce que le point de terminaison auth.pi-hole.net est une redirection d’URI à partir du point de terminaison OAuth sur github.com. Et nous préférerions ne pas bloquer github.com pour la fonction unebox.
Je vais vérifier et voir si bloquer github change quelque chose… Non, bloquer github.com n’empêche pas non plus la fonction unebox. Y a-t-il un cache que la fonction unebox pourrait utiliser et qui doit être vidé pour qu’une nouvelle recherche soit effectuée pour tricorder ?
Oui, je comprends pourquoi.
Il y a un cache d’un jour pour les URL de onebox récupérées, donc refaire la cuisson du message manuellement (post.rebake!) après un jour empêcherait le oneboxing avec github.com bloqué.
Nous avons du travail en attente pour être plus intelligents concernant les redirections d’authentification, mais cela est limité à l’authentification pour les forums Discourse uniquement. Je pense que l’élargissement du paramètre pour autoriser également les sous-répertoires pourrait nous aider dans ce cas pour github : \u003chttps://github.com/login/oauth/authorize\u003e … Nous en discuterons en interne.
Il serait probablement également bon que le texte d’aide soit spécifique sur ce qui est réellement bloqué, peut-être un ajout : « Onebox suivra les redirections et ne bloquera que si la destination finale correspond à ce paramètre ».
Idée folle… devrions-nous prendre en charge :
cache-control: no-store
La directive de réponse
no-storeindique que tous les caches, quels qu’ils soient (privés ou partagés), ne doivent pas stocker cette réponse.
GitHub dit spécifiquement… s’il vous plaît… ne me stockez pas…
Peut-être que onebox devrait le respecter… et ne pas le stocker.
Nous pourrions toujours en faire un réglage expérimental pour commencer et voir quel impact cela a.
L’aperçu devrait expliquer pourquoi nous ne faisons pas de onebox.
Note… nous utilisons no-store dans pas mal d’endroits, mais je pense que nous redirigeons dans ces cas, pourtant il y a cette légère complexité.
Nous faisons le lien vers de nombreuses PR et problèmes à partir de nos différents dépôts et le fait que ces derniers soient prévisualisés dans des boîtes aide les nouveaux utilisateurs à comprendre le sujet sans avoir à se connecter à GitHub.
Oui, je comprends tout à fait, nous travaillons sur une solution. Je pense que regarder l’en-tête « no store » un jour plus tard serait la meilleure approche.
Désolé de déterrer ce sujet, mais cela affecte vraiment notre site de support. Les gens publient des liens vers l’URL du tricorder qui contiennent des journaux de dépannage que le personnel accrédité doit examiner. Nous recevons un certain nombre de ces publications par jour et nous devons intervenir manuellement et modifier l’URL en une non-lien pour le moment.
Avez-vous une idée du délai de résolution ou est-ce que ce sera « bientôt™ » ![]()
Nous allons régler cela, je dirais dans les 4 prochaines semaines environ.
Comment faire cela dans Discourse Docker ? ![]()
Je recommande d’attendre notre correctif, nous avons une PR en cours :
Elle modifie le comportement afin que :
Cela résoudra le problème de @dschaper et nous donnera plus de flexibilité à l’avenir.
Malheureusement, opter pour « no store » serait trop général et entraînerait trop de faux positifs.
La PR a été fusionnée et se trouve dans la branche tests-passed. Pouvez-vous mettre à niveau @dschaper et voir si cela résout le problème ? Les URL avec le domaine tricorder.pi-hole.net ne devraient plus apparaître en un seul bloc sur votre site.
Tout semble bon ici !
Merci pour la correction à tous.