Onebox follows redirects, which is usually a good thing, I guess.
This becomes a problem, however, when you share a link to a page requiring sign-in that simply redirects to a sign-in page when an anonymous user visits it.
For example, if I want to share my top secret project hosted at https://dgit.cs.uni-saarland.de/fefrei/my-top-secret-project/ in the internal category of our Discourse instance, this is what I get by default:
Note that all links in the Onebox go to https://dgit.cs.uni-saarland.de/users/sign_in, which is not helpful.
Of course, as a post author, I can prevent that by using any alternative markup that prevents the Onebox (which can’t show relevant content anyways); but if some other user does this and doesn’t notice, it’s pretty hard to retrieve the actual link.
As staff, I can edit the post to get the raw markup, but as a non-staff user, I think the only feasible workaround is to remember the magic /raw/ URL scheme.
Why does the Onebox link to the final location, not the original URL? Can we do something to improve this?
I typed https://dgit.cs.uni-saarland.de/fefrei/my-top-secret-project/, why should it link somewhere else?
When I’m redirected to the sign in page, this is fine, because I’m in a session – I can actually log in, and will be redirected back to the target URL.
When Discourse follows the redirect, forgets the original URL and just outputs the sign in URL, the reader has no (easy) way to get to the URL the author linked to.
I know that’s the current behavior, and already mentioned the workaround above:
I stumbled about this because another user fell for this trap, and I had to fish the actual link out of the raw view.
I’m not saying that this is terribad and needs to be fixed now or else; I’m just reporting that I find it sad that a user who simply pasted a link into his post got a Onebox that obfuscates the link in a way that makes it impossible for the average user to understand where to go. (There’s a reason I posted this in feature.)
Me encontré con este comportamiento hoy y apoyo un cambio en la UX.
El caso en el que no quieres enlazar a la ubicación final es cuando esperas que las personas con las que compartes tu enlace estén autenticadas o puedan autenticarse en el sitio al que estás enlazando.
También está la cuestión de la percepción: publiqué un enlace a un hilo de Discourse en otra comunidad y el enlace se modificó para apuntar a la página de inicio de sesión. La gente me preguntaba si había publicado el enlace incorrecto, porque es extraño enlazar a propósito a una página de inicio de sesión. En última instancia, se está alterando lo que el usuario pretendía publicar.
La solución alternativa es válida, pero no es buena; deberíamos tener configuraciones predeterminadas más inteligentes, especialmente si queremos evitar una mala experiencia de usuario tanto para quien publica como para quien hace clic en el enlace.
No se me ocurre ninguna otra forma de manejar esto que no sea codificar manualmente el manejo de “iniciar sesión” mediante coincidencia de cadenas, y realmente no me gusta esa solución, ya que sería increíblemente frágil.
Disculpa si esto es la fuente de confusión, pero tal vez mi solicitud inicial no fue clara. Permíteme aclarar:
Supongamos que el usuario enlaza a https://example.org/a, pero esto redirige a https://example.org/login a menos que haya iniciado sesión. El comportamiento actual:
Discourse solicita https://example.org/a y sigue la redirección.
Discourse solicita https://example.org/login y recupera el título, la imagen, etc.
Discourse muestra un Onebox con la información recuperada de https://example.org/login, y enlaza a https://example.org/login. El Onebox generado no enlaza a https://example.org/a en ningún lugar.
Solo la parte en negrita es lo que encuentro problemático. Sí, sigue el enlace y recupera la información de allí, pero el Onebox siempre debe enlazar a la URL que ingresé.
Esto no se trata de que el Onebox muestre información de la página de inicio de sesión (¿qué más debería mostrar?), sino de que la creación del Onebox oculta completamente el destino original del enlace.
Si esto se implementara, el Onebox en mi publicación original seguiría viéndose idéntico, pero enlazaría a https://dgit.cs.uni-saarland.de/fefrei/my-top-secret-project/.
Tiene sentido que un cuadro enlace directamente a lo que tú enlazaste, en lugar de a donde redirige. Esto soluciona el problema y no rompe nada que se me ocurra.
Si todo redirige, es aún más razonable mantener el enlace original.
No estoy de acuerdo: quieres saber el destino final, no el hecho de que hayas hecho clic en un servicio general de acortamiento de enlaces. Yo tengo exactamente el punto de vista contrario.
Pero estamos hablando de Oneboxes aquí. De todos modos, no se hace esto para los que no son Oneboxes.
Además, de hecho, no tengo nada en contra de mostrar la URL final. Pero no enlazar a la URL original simplemente rompe los enlaces en escenarios que requieren inicio de sesión
No discrepo para nada contigo en este punto, pero necesitas probarlo tú mismo con un ejemplo de una página de inicio de sesión. ¿Hay ejemplos de categorías privadas en Meta? Imagina que tuviéramos una y yo publicara un enlace en esta respuesta. Debido a cómo funcionan las cajas de resumen, nunca podrías saber a dónde iba dirigido ese enlace ni acceder a él.
No tengo problema en que la caja de resumen muestre el contenido de la página final, pero no conservar la URL original arruina cualquier posibilidad de que la redirección funcione como se pretende en este escenario. Además, también elimina cualquier etiqueta de atribución presente en el enlace original.
