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.)
I ran into this behaviour today and support a change in the UX.
The case where you don’t want to link to the final location is if you expect the people you are sharing your link with to be authenticated or be able to authenticate to the site you are linking to.
There’s also the optics of it, I posted a link to a discourse thread in another community and the link was changed to point to the sign in page. People were asking me if I posted the wrong link because it’s odd to link to a sign in page on purpose. Ultimately, it is changing what the user meant to post.
Workaround is valid but not good, we should have smarter defaults especially if we want to avoid bad UX for the poster and the user clicking the link.
I can’t think of any way to handle this other than hard-coding handling of “sign in” with string matching and I really don’t like that as a solution, it would be incredibly brittle.
Sorry if this is the source of confusion, but maybe my initial request was unclear. Let me clarify:
Assume the user links to https://example.org/a, but that redirects to https://example.org/login unless signed in. The current behavior:
Discourse requests https://example.org/a and follows the redirect.
Discourse requests https://example.org/login and retrieves title, image, …
Discourse shows a Onebox showing the information retrieved from https://example.org/login, and links to https://example.org/login. The generated Onebox doesn’t link to https://example.org/a anywhere.
Only the bold part is what I find problematic. Yes, by all means, follow the link and retrieve information from there, but the Onebox should always link to the URL I entered.
This is not about the Onebox showing info from the sign-in page (What else should it show?), just about the Onebox creation completely obscuring the original link target.
If this were implemented, the Onebox in my original post would still look identical, but link to https://dgit.cs.uni-saarland.de/fefrei/my-top-secret-project/.
It does make sense for one box to link to the thing that you linked to rather than where it redirects. It fixes this problem and doesn’t break anything that I can think of.
If everything redirects then it’s all the more reasonable to maintain the original link.
I don’t agree – you want to know the final target destination, not the fact that you clicked on a general link shortening service. I have the exact opposite viewpoint here.
But we’re talking about Oneboxes here. You don’t do this for non-Oneboxes anyway.
Also, in fact, I have nothing against showing the final URL. But not linking to the original URL just breaks links in login-required scenarios
I don’t disagree with you here at all, but you need to try this out yourself with an example of a login page. Are there any examples of private categories in meta? Imagine we had one and I posted a link in this reply. Because of how the one boxes work you’d never be able to find out where that link was supposed to go or get to it.
I have no problem with making the one box show the content of the final page, but not keeping the original URL destroys any chance of the redirect working as intended in this scenario. It also destroys any attribution tags in the original link by the way.
