La configuración "blocked onebox domains" no se respeta

Se ignoran los blocked onebox domains en 2.9.0beta2 (c6265eec6b).

Tenemos:

Esos dominios están detrás de muros de OAuth y el onebox intenta previsualizar los dominios y obtiene la URL de inicio de sesión de OAuth en su lugar.

4 Me gusta

Esa configuración solo tiene efecto en el servidor; tu navegador seguirá intentando hacer una “onebox” para la vista previa.

Puedo ver cómo esto podría ser inesperado.

Si envías la publicación, ¿muestra la “onebox” después de que el servidor la procesa, o muestra la URL sin formato como esperas?

3 Me gusta

Se muestra como un onebox cuando se publica el comentario:

4 Me gusta

Sí, esto no parece estar funcionando correctamente… :confused:

1 me gusta

¿Puedes intentar añadir “auth.pi-hole.net” en tu configuración de dominios de onebox bloqueados?

Hemos hecho que esta configuración siga las redirecciones como se indica aquí pero solo bloquea el dominio especificado si es el destino final.

4 Me gusta

Lo acabo de probar y sigue funcionando. Creo que es porque el endpoint auth.pi-hole.net es una redirección URI desde el endpoint OAuth en github.com. Y preferiríamos no bloquear github.com para que no funcione.

Déjame comprobar si bloquear github hace algo… No, bloquear github.com tampoco evita que funcione. ¿Hay alguna caché que pueda estar usando que necesite ser borrada para que se realice una nueva búsqueda de tricorder?

3 Me gusta

Sí, puedo entender por qué.

Hay una caché de un día para las URL de onebox obtenidas, por lo que volver a hornear la publicación manualmente (post.rebake!) después de un día evitaría el oneboxing con github.com bloqueado.


Tenemos algo de trabajo pendiente para ser más inteligentes con las redirecciones de autenticación, pero eso está limitado a la autenticación solo para foros de Discourse. Estoy pensando que quizás expandir la configuración para permitir también subdirectorios nos ayudaría en este caso para github: \u003chttps://github.com/login/oauth/authorize\u003e … Lo discutiremos internamente al respecto.

Probablemente también sea bueno que el texto de ayuda sea específico sobre lo que realmente se bloquea, quizás un adicional: “Onebox seguirá las redirecciones y solo bloqueará si el destino final coincide con esta configuración”.

4 Me gusta

Idea descabellada… ¿deberíamos admitir:

cache-control: no-store

La directiva de respuesta no-store indica que ninguna caché de ningún tipo (privada o compartida) debe almacenar esta respuesta.

GitHub está diciendo específicamente… por favor… no me almacenes…

Quizás onebox debería respetarlo… y no almacenarlo.

Siempre podríamos hacer de esto una configuración experimental para empezar y ver qué impacto tiene.

La vista previa tendría que explicar por qué no estamos haciendo onebox.


Nota… usamos no-store en bastantes lugares, pero creo que en esos casos redirigimos, sin embargo, existe esta ligera complejidad.

6 Me gusta

Nos enlazamos a muchas PRs y Issues desde nuestros diversos repositorios y tenerlos previsualizados ayuda a los usuarios más nuevos a ver de qué trata el tema sin tener que entrar en GitHub.

1 me gusta

Sí, lo entiendo totalmente, estamos trabajando en una solución, creo que un día después, mirando la cabecera “no store” puede ser la mejor manera de avanzar.

3 Me gusta

Lamento revivir este tema, pero está afectando realmente a nuestro sitio de soporte. La gente publica enlaces a la URL de tricorder que son registros de solución de problemas para que el personal con credenciales los revise. Recibimos varias de estas publicaciones al día y tenemos que entrar manualmente y cambiar la URL a una que no sea un enlace por ahora.

¿Alguna idea sobre un plazo de resolución o es “pronto™” :slight_smile:

3 Me gusta

Lo resolveremos, diría que en las próximas 4 semanas aproximadamente.

4 Me gusta

¿Cómo hacerlo en Discourse Docker? :pleading_face:

Recomiendo esperar a que llegue nuestra solución, tenemos una PR en progreso:

Modifica el comportamiento para que:

  1. Realicemos la verificación de la lista de bloqueo en cada salto de una cadena de redirección.
  2. Introduzcamos una nueva función para que cualquier sitio pueda optar por no participar en oneboxing estableciendo una cabecera personalizada.

Esto resolverá el problema de @dschaper y nos dará más flexibilidad en el futuro.

Desafortunadamente, optar por no store abarcaría una red demasiado amplia y atraparía demasiados falsos positivos.

6 Me gusta

Se ha fusionado la PR y está en la rama tests-passed. ¿Puedes actualizar @dschaper y ver si soluciona el problema? Las URL con el dominio tricorder.pi-hole.net ya no deberían aparecer como “onebox” en tu sitio.

7 Me gusta

¡Todo parece bien aquí!

Gracias por la corrección a todos.

4 Me gusta