Si entiendo correctamente, Discourse está utilizando GitHub - markdown-it/linkify-it: Links recognition library with full unicode support para proporcionar un enlace agradable con un título. Por ejemplo, el enlace anterior proporciona un título agradable GitHub - markdown-it/linkify-it: Links recognition library with full unicode support.
Sin embargo, tengo el siguiente problema: para acceder a algunos de los enlaces publicados, debes estar autenticado en otra herramienta (por ejemplo, Jira, Google…). Por lo tanto, lo que sucede es que todos los enlaces (y bloques para algunas de las URL transformadas) simplemente mostrarán Iniciar sesión para obtener soporte o Conoce Google Drive: un solo lugar para todos tus archivos [...], lo cual no es muy agradable.
¿Ya existe alguna característica o componente/plugin que permita pre-probar la URL y, en caso de que haya una redirección, no asignar un título a la URL?
Sí, nuestra solución general aquí es usar la configuración del sitio blocked onebox domains (dominios de onebox bloqueados).
Agrega todas las URL internas de “requiere inicio de sesión” a esa lista.
Me pregunto @nat/@codinghorror si deberíamos agregar una configuración contundente aquí.
block onebox on redirect (bloquear onebox en redirección): esa configuración puede bloquear completamente cualquier onebox si se involucra una redirección. Proporciona una palanca muy simple para controlar este comportamiento incondicionalmente en múltiples dominios.
Gracias por la pista para los enlaces internos.
La función más genérica con block onebox on redirect sería muy apreciada ya que no conocemos de antemano la lista completa que los usuarios podrían publicar.
Esto parece no funcionar para los enlaces enlazados que no se actualizan en “onebox” sino que simplemente se convierten en un título (por ejemplo, nuestro enlace interno https://support.sqills.com/browse/SCQI-934 se convierte en Log in - Sqills Jira, pero la URL base solo da https://support.sqills.com como título del enlace).
Ciertamente hay un error confuso aquí que deberíamos solucionar.
Acabo de bloquear support.sqills.com y confirmo que está haciendo lo que se supone que debe hacer para https://support.sqills.com/browse/SCQI-934?1https://support.sqills.com/browse/SCQI-934?1, pero lamentablemente https://support.sqills.com/browse/SCQI-934 está en caché del lado del servidor durante 24 horas y la reconstrucción del HTML no está rompiendo la caché.
Solucionaremos esta pequeña molestia esta semana para reducir el soporte en torno a esto. Bloquear la redirección como opción me parece genial, puede que podamos incluirla. Quizás bloquear onebox en redirección de dominio cruzado sea mejor, o quizás eso sea demasiado detalle… no estoy seguro.
Ahora, cuando se reconstruye una publicación, las entradas de caché de todos los enlaces de la publicación se eliminan antes de realizar la reconstrucción.
Y aquí hay una PR para agregar una configuración del sitio block_onebox_on_redirect:
Cuando block_onebox_on_redirect está habilitado, Discourse nunca hará un onebox de las URL que redirigen. La única excepción es si una URL es http y redirige a la versión https de la URL. Esto se hace porque es muy común que los sitios que admiten TLS redirijan el tráfico http a https y, por lo tanto, el onebox aún debería funcionar si un usuario, por ejemplo, escribe un enlace con http y el sitio redirige a https.