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.)
Oggi ho riscontrato questo comportamento e sostengo un cambiamento nell’UX.
Il caso in cui non si desidera collegarsi alla destinazione finale è quando ci si aspetta che le persone con cui si condivide il link siano autenticate o in grado di autenticarsi sul sito a cui si fa riferimento.
C’è anche l’aspetto visivo: ho pubblicato un link a un thread di Discourse in un’altra community e il link è stato modificato per puntare alla pagina di accesso. Le persone mi chiedevano se avessi postato il link sbagliato, perché è strano collegare intenzionalmente a una pagina di accesso. In definitiva, si sta modificando ciò che l’utente intendeva pubblicare.
La soluzione alternativa è valida ma non ottimale; dovremmo avere impostazioni predefinite più intelligenti, specialmente se vogliamo evitare una cattiva UX sia per chi pubblica il link sia per l’utente che lo clicca.
Non riesco a pensare a nessun altro modo per gestire questa situazione se non codificando a mano la gestione di “sign in” tramite corrispondenza di stringhe, e mi dispiace davvero molto come soluzione; sarebbe incredibilmente fragile.
Scusa se questo è la fonte della confusione, ma forse la mia richiesta iniziale non era chiara. Chiarisco:
Supponiamo che l’utente colleghi a https://example.org/a, ma che questo reindirizzi a https://example.org/login a meno che non si sia effettuato l’accesso. Il comportamento attuale:
Discourse richiede https://example.org/a e segue il reindirizzamento.
Discourse richiede https://example.org/login e recupera titolo, immagine, …
Discourse mostra un Onebox con le informazioni recuperate da https://example.org/login, e collega a https://example.org/login. L’Onebox generato non collega in alcun modo a https://example.org/a.
Solo la parte in grassetto è ciò che trovo problematico. Sì, pure, segui il link e recupera le informazioni da lì, ma l’Onebox dovrebbe sempre collegare all’URL che ho inserito.
Non si tratta del fatto che l’Onebox mostri informazioni dalla pagina di accesso (Cosa altro dovrebbe mostrare?), ma solo del fatto che la creazione dell’Onebox nasconda completamente l’obiettivo originale del link.
Se ciò venisse implementato, l’Onebox nel mio post originale apparirebbe identico, ma collegherebbe a https://dgit.cs.uni-saarland.de/fefrei/my-top-secret-project/.
Ha senso che una casella colleghi all’oggetto a cui hai collegato tu, piuttosto che alla destinazione di reindirizzamento. Questo risolve il problema senza rompere nulla, per quanto mi risulta.
Se tutto viene reindirizzato, è ancora più ragionevole mantenere il link originale.
Non sono d’accordo: vuoi sapere la destinazione finale, non il fatto che tu abbia cliccato su un servizio di accorciamento link generico. Ho un punto di vista esattamente opposto.
Ma qui stiamo parlando di Onebox. Del resto, per i contenuti non Onebox non si fa mai questo.
Inoltre, in realtà, non ho nulla contro la visualizzazione dell’URL finale. Ma non collegare all’URL originale semplicemente rompe i link in scenari che richiedono l’accesso
Non sono affatto in disaccordo con te, ma devi provarlo tu stesso con un esempio di pagina di accesso. Esistono esempi di categorie private in Meta? Immagina che ne avessimo una e io pubblicassi un link in questa risposta. A causa del funzionamento delle one box, non potresti mai scoprire dove quel link doveva portare o raggiungerlo.
Non ho problemi a far sì che la one box mostri il contenuto della pagina finale, ma non conservare l’URL originale distrugge qualsiasi possibilità che il reindirizzamento funzioni come previsto in questo scenario. Inoltre, distrugge anche tutti i tag di attribuzione presenti nel link originale.
