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.)
Я столкнулся с таким поведением сегодня и поддерживаю изменение в UX.
Случай, когда вы не хотите вести на конечное место, возникает, если вы ожидаете, что люди, с которыми вы делитесь ссылкой, будут аутентифицированы или смогут аутентифицироваться на сайте, на который вы ссылаетесь.
Также есть вопрос восприятия: я опубликовал ссылку на тему в Discourse в другом сообществе, и ссылка изменилась, указывая на страницу входа. Люди спрашивали меня, не ошибся ли я ссылкой, потому что намеренно вести на страницу входа — это странно. В конечном итоге это меняет то, что пользователь хотел опубликовать.
Обходной путь допустим, но не хорош. Нам нужны более умные настройки по умолчанию, особенно если мы хотим избежать плохого UX как для автора, так и для пользователя, переходящего по ссылке.
Я не могу придумать другого способа обработать это, кроме как жестко прописать обработку «sign in» с помощью сопоставления строк, и мне это очень не нравится как решение, так как оно будет невероятно хрупким.
Извините, если это вызвало путаницу, но, возможно, мой первоначальный запрос был сформулирован неясно. Давайте проясним:
Предположим, пользователь ссылается на https://example.org/a, но этот адрес перенаправляет на https://example.org/login, если пользователь не авторизован. Текущее поведение:
Discourse запрашивает https://example.org/a и следует за перенаправлением.
Discourse запрашивает https://example.org/login и получает заголовок, изображение и т. д.
Discourse отображает Onebox с информацией, полученной из https://example.org/login, и ссылается на https://example.org/login. В сгенерированном Oneboxе нет ни одной ссылки на https://example.org/a.
Проблематичным для меня является только выделенное жирным шрифтом. Да, безусловно, следуйте по ссылке и получайте информацию оттуда, но Onebox всегда должен вести на URL, который я ввёл.
Речь не о том, что Onebox показывает информацию со страницы входа (Что ещё он должен показывать?), а о том, что создание Onebox полностью скрывает исходную цель ссылки.
Если бы это было реализовано, Onebox в моём первоначальном посте выглядел бы точно так же, но ссылался бы на https://dgit.cs.uni-saarland.de/fefrei/my-top-secret-project/.
Но в чём проблема? Редирект будет работать и в том случае, если пользователь нажмёт на него, точно так же, как если бы ссылка не была превращена в превью…
Имеет смысл, чтобы один блок ссылался на то, на что вы ссылаетесь, а не на то, куда происходит перенаправление. Это решает проблему и, насколько я могу судить, ничего не ломает.
Если всё перенаправляется, то тем более разумно сохранять исходную ссылку.
Я не согласен — вы хотите узнать конечный пункт назначения, а не то, что вы перешли по общей ссылке-укорачивателю. У меня здесь прямо противоположная точка зрения.
Сообщение
эй, вы собираетесь перейти по ссылке link.is/ghwk4fe3
Но речь здесь идет об Oneboxes. Для не-Oneboxes так вообще не делают.
Кроме того, на самом деле, я не против отображения конечного URL. Но отсутствие ссылки на исходный URL просто ломает ссылки в сценариях, требующих входа
Я совершенно с вами согласен, но вам стоит попробовать это на практике на примере страницы входа. Есть ли примеры приватных категорий в Meta? Представьте, что такая категория существует, и я оставлю ссылку на неё в этом ответе. Из-за особенностей работы «одностраничных блоков» вы никогда не сможете узнать, куда должна вести эта ссылка, и не сможете перейти по ней.
У меня нет возражений против того, чтобы «одностраничный блок» отображал содержимое конечной страницы, но удаление исходного URL лишает всякой возможности корректной работы перенаправления в данном сценарии. К тому же, при этом теряются все теги атрибуции, присутствовавшие в исходной ссылке.
