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.)
Encontrei esse comportamento hoje e apoio uma mudança na UX.
O caso em que você não deseja linkar para o local final é quando espera que as pessoas com quem está compartilhando seu link estejam autenticadas ou possam se autenticar no site ao qual está linkando.
Também há a questão da percepção: publiquei um link para um tópico do Discourse em outra comunidade e o link foi alterado para apontar para a página de login. As pessoas me perguntaram se eu havia postado o link errado, pois é estranho linkar propositalmente para uma página de login. No final, isso altera o que o usuário pretendia postar.
A solução alternativa é válida, mas não é boa. Devemos ter padrões mais inteligentes, especialmente se queremos evitar uma má experiência de usuário tanto para quem posta quanto para quem clica no link.
Não consigo pensar em nenhuma outra forma de lidar com isso além de codificar manualmente o tratamento de “sign in” com correspondência de strings, e eu realmente não gosto dessa solução, pois seria extremamente frágil.
Peço desculpas se essa foi a fonte da confusão, mas talvez minha solicitação inicial não tenha ficado clara. Deixe-me esclarecer:
Suponha que o usuário faça um link para https://example.org/a, mas que isso redirecione para https://example.org/login a menos que o usuário esteja logado. O comportamento atual:
O Discourse solicita https://example.org/a e segue o redirecionamento.
O Discourse solicita https://example.org/login e recupera o título, a imagem, etc.
O Discourse exibe um Onebox mostrando as informações recuperadas de https://example.org/login, e cria um link para https://example.org/login. O Onebox gerado não contém nenhum link para https://example.org/a em lugar algum.
Apenas a parte em negrito é o que considero problemático. Sim, siga o link e recupere as informações de lá, mas o Onebox deve sempre linkar para a URL que eu inseri.
Isso não tem a ver com o Onebox mostrar informações da página de login (O que mais ele deveria mostrar?), mas sim com o fato de que a criação do Onebox obscurece completamente o destino original do link.
Se isso fosse implementado, o Onebox em minha postagem original continuaria com a mesma aparência, mas linkaria para https://dgit.cs.uni-saarland.de/fefrei/my-top-secret-project/.
Faz sentido que uma caixa link para o item ao qual você linkou, em vez de para onde ele redireciona. Isso resolve esse problema e não quebra nada que eu possa imaginar.
Se tudo redirecionar, torna-se ainda mais razoável manter o link original.
Não concordo — você quer saber o destino final, não o fato de ter clicado em um serviço genérico de encurtamento de links. Tenho exatamente o ponto de vista oposto aqui.
Mas estamos falando de Oneboxes aqui. Você não faz isso para não-Oneboxes de qualquer forma.
Além disso, na verdade, não tenho nada contra mostrar a URL final. Mas não vincular à URL original apenas quebra os links em cenários que exigem login
Não discordo de você em nada aqui, mas você precisa testar isso você mesmo com um exemplo de página de login. Existem exemplos de categorias privadas no Meta? Imagine que tivéssemos uma e eu publicasse um link nesta resposta. Por causa do funcionamento dos one boxes, você nunca conseguiria descobrir para onde aquele link deveria levar ou acessá-lo.
Não tenho problema algum em fazer o one box exibir o conteúdo da página final, mas não preservar a URL original destrói qualquer chance de o redirecionamento funcionar como pretendido neste cenário. Além disso, isso também elimina qualquer tag de atribuição presente no link original.
