The discussion revolves around preventing Discourse from linkifying URLs that redirect to authentication pages, resulting in unhelpful titles like “Login to support”. Jonathan_Poyer initially requested a feature to pre-test URLs and avoid giving titles if a redirect is detected.
SAM suggested using the “blocked onebox domains” site setting for internal links that require login. However, this doesn’t address the issue for unknown external links. SAM also proposed adding a setting called “block onebox on redirect” to control this behavior across multiple domains.
Jonathan_Poyer appreciated the suggestion but noted that the proposed setting wouldn’t work for linkified links that aren’t updated into “onebox” but just turned into a title.
SAM acknowledged the bug and confirmed that blocking the domain does work, but there’s a caching issue. Osama reported that the caching issue has been fixed in a recent commit. A pull request has also been submitted to add the block_onebox_on_redirect site setting, which will prevent Discourse from oneboxing URLs that redirect, with an exception for http to https redirects.
I have however the following issue: to access some of the links posted, you must be authenticated in some other tool (e.g. Jira, Google…). So what happen is that all the links (and blocs for some of the transformed URLs) will just show Login to support or Meet Google Drive – One place for all your files[...] which is not really nice.
Is there already an existing feature or component/plugin allowing to pre-test the URL and in case there is a redirect, to not give a title to the URL?
Yes, our general solution here is using the blocked onebox domains site setting.
Add all the internal “requires login” URLs into that list.
I do wonder @nat/@codinghorror if we should add a sledghammer setting here.
block onebox on redirect - that setting can completely block any oneboxes if a redirect gets involved. It gives a very simple lever to control this behavior unconditionally across multiple domains.
Thank you for the hint for the internal links.
The more generic feature with block onebox on redirect would be greatly appreciated as we do not know ahead the full list that users might post.
This seems to not work for the linkified link that are not updated into “onebox” but just being turned into a title (e.g our internal link https://support.sqills.com/browse/SCQI-934 turns into Log in - Sqills Jira but the base URL just gives https://support.sqills.com as title of the link).
We will get this small niggle sorted out this week so we reduce support around this. Blocking redirect as an option sounds great to me, we may be able to squeeze this in. Maybe block onebox on cross domain redirect is better, or maybe that is too much fidelity… not sure.
When block_onebox_on_redirect is enabled, Discourse will never onebox URLs that redirect. The only exception to this is if a URL is http and redirects to the https version of the URL. This is done because it’s very common for sites that support TLS to redirect http traffic to https and so the onebox should still work if a user e.g. types out a link with http and the site redirects to https.