blocked onebox domains
are ignored in 2.9.0beta2 (c6265eec6b).
We have:
Those domains are behind OAuth walls and the onebox is trying to preview the domains and getting the OAuth login URL instead.
blocked onebox domains
are ignored in 2.9.0beta2 (c6265eec6b).
We have:
Those domains are behind OAuth walls and the onebox is trying to preview the domains and getting the OAuth login URL instead.
That setting only takes effect on the server — your browser will still attempt to do a onebox for the preview.
I can see how this might be unexpected.
If you submit the post, does it show the onebox after the server renders it, or does it show the bare URL as you expect?
Yes, this doesn’t seem to be working properly…
Can you try adding “auth.pi-hole.net” in your blocked onebox domains setting?
We’ve made this setting such that it follows redirects but only blocks the specified domain if it’s the final destination.
Just tried and it still oneboxes it. I think because the auth.pi-hole.net endpoint is a uri-redirect from the OAuth endpoint on github.com. And we’d prefer not to block github.com from oneboxing.
Let me check and see if blocking github does anything…No, blocking github.com doesn’t preven oneboxing either. Is there a cache that onebox may be using that needs to be cleared so a new lookup is done for tricorder
?
Yes I can understand why.
There’s a cache for one day for fetched onebox URLs, so rebaking the post manually (post.rebake!
) after one day would prevent the oneboxing with github.com blocked.
We have some work backlogged to be smarter about auth redirects, but that’s scoped to auth for Discourse forums only. I’m thinking perhaps expanding the setting to also allow subdirectories would help us with this case for github: https://github.com/login/oauth/authorize … Will discuss internally about this.
It’s probably also good to have the hint text be specific on what is actually blocked, perhaps an additional: “Onebox will follow redirects and block only if the final destination matches this setting”.
Wild idea… should we support:
cache-control: no-store
The
no-store
response directive indicates that any caches of any kind (private or shared) should not store this response.
GitHub is specifically saying … please … don’t store me …
Maybe onebox should respect it … and not store it.
We could always make this an experimental setting to start and see what impact it has.
The preview would have to explain why we are not oneboxing.
Note… we do use no-store
in quite a few places, but I think we redirect in those cases, yet there is this slight complexity.
We do link to a lot of PRs and Issues from our various repositories and having those oneboxed with the previews helps newer users see what the topic is about without having to get in to GitHub.
Yes totally get that, we are working on a solution, a day later I think looking at the no store header may be the best way forward
Sorry to bump this but it’s really affecting our support site. People post links to the tricorder URL that are troubleshooting logs for credentialed staff to look over. We get a number of these posts a day and we have to manually go in and change the URL to a non-link for now.
Any ideas on a timeframe to resolution or is it “soon™”
We will get this sorted, I would say some time in the next 4 weeks or so
How to do it in Discourse Docker?
I recommend waiting on our fix to land, we have a PR in progress:
It amends the behavior so:
This will resolve @dschaper issue and give us more flexibility in future.
Unfortunately going with no store
would cast a way too wide net and catch too many false positives.
The PR has been merged and it’s in the tests-passed
branch. Can you upgrade @dschaper and see if it fixes the problem? URLs with the tricorder.pi-hole.net
domain should no longer onebox on your site.
Looks all good here!
Thanks for the fix everyone.