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.)
Je suis tombé sur ce comportement aujourd’hui et je soutiens un changement dans l’UX.
Le cas où vous ne voulez pas lier vers l’emplacement final est lorsque vous vous attendez à ce que les personnes avec qui vous partagez votre lien soient authentifiées ou puissent s’authentifier sur le site vers lequel vous pointez.
Il y a aussi l’aspect visuel : j’ai partagé un lien vers un fil de discussion Discourse dans une autre communauté, et le lien a été modifié pour pointer vers la page de connexion. Des gens m’ont demandé si j’avais posté le mauvais lien, car il est étrange de lier intentionnellement à une page de connexion. En fin de compte, cela modifie ce que l’utilisateur voulait publier.
La solution de contournement est valide, mais pas idéale. Nous devrions avoir des paramètres par défaut plus intelligents, surtout si nous voulons éviter une mauvaise expérience utilisateur pour l’auteur du message et pour l’utilisateur qui clique sur le lien.
Je ne vois pas d’autre moyen de gérer cela que de coder en dur la gestion de « se connecter » avec une correspondance de chaînes, et je n’aime vraiment pas cette solution car elle serait extrêmement fragile.
Pourquoi auriez-vous besoin de quelque chose comme ça ?
Désolé si cela est à l’origine de la confusion, mais peut-être que ma demande initiale n’était pas claire. Laissez-moi préciser :
Supposons que l’utilisateur fasse un lien vers https://example.org/a, mais que cela redirige vers https://example.org/login sauf si l’utilisateur est connecté. Le comportement actuel :
Discourse demande https://example.org/a et suit la redirection.
Discourse demande https://example.org/login et récupère le titre, l’image, …
Discourse affiche une Onebox montrant les informations récupérées depuis https://example.org/login, et lie vers https://example.org/login. La Onebox générée ne lie nulle part vers https://example.org/a.
Seule la partie en gras me pose problème. Oui, suivez le lien et récupérez les informations de là, mais la Onebox devrait toujours pointer vers l’URL que j’ai saisie.
Il ne s’agit pas du fait que la Onebox affiche des informations provenant de la page de connexion (Que devrait-elle afficher d’autre ?), mais simplement du fait que la création de la Onebox masque complètement la cible du lien original.
Si cela était mis en œuvre, la Onebox dans mon message original resterait identique, mais pointerait vers https://dgit.cs.uni-saarland.de/fefrei/my-top-secret-project/.
Cela a du sens qu’une boîte pointe vers l’élément auquel vous avez fait référence plutôt que vers sa redirection. Cela résout ce problème sans rien casser, à ma connaissance.
Si tout est redirigé, il est d’autant plus raisonnable de conserver le lien original.
Je ne suis pas d’accord — vous voulez connaître la destination finale, pas le fait que vous ayez cliqué sur un service général de raccourcissement de liens. J’ai exactement le point de vue inverse ici.
Mais nous parlons ici des Oneboxes. Vous ne faites pas cela pour les non-Oneboxes de toute façon.
Par ailleurs, en fait, je n’ai rien contre l’affichage de l’URL finale. Mais ne pas lier vers l’URL d’origine casse simplement les liens dans les scénarios nécessitant une connexion
Je ne suis absolument pas en désaccord avec toi sur ce point, mais tu dois essayer cela toi-même avec un exemple de page de connexion. Y a-t-il des exemples de catégories privées dans Meta ? Imaginons qu’il y en ait une et que je poste un lien dans cette réponse. En raison du fonctionnement des boîtes d’aperçu, tu ne pourrais jamais savoir où ce lien était censé mener ni y accéder.
Je n’ai aucun problème à ce que la boîte d’aperçu affiche le contenu de la page finale, mais ne pas conserver l’URL d’origine rend impossible le bon fonctionnement de la redirection dans ce scénario. Cela supprime également toutes les balises d’attribution présentes dans le lien original, au passage.
