Internal links stopped oneboxing in login-required instance

Support
1

I’m operating two Discourse instances with login required, both running on the beta channel, both are up-to-date.

In one of these instances, local links to posts no longer onebox (they don’t produce a broken onebox, they just do not onebox at all). No log entries are produced.

Does anyone have an idea what could be causing this?

2

We have had intermittent reports of this but we can never repro it.

Best guess is outgoing server DNS problems, when we have been able to diagnose it.

3

I just testet curling from both google.de and my domain itself from within the container, and the domain was resolved correctly. But Oneboxes are still not working (even for new links that are not in the cache)…

Any more ideas? Could I help you diagnose that in any way?

4

There was a bug involving local onebox, login required and subdomain, but this got fixed.

When I was debugging it I had to use a dev environment, and it was easy from there, but it was easy to reproduce.

If you can find some difference between the working instance and the other we can hunt it down.

5

I cannot really think of any meaningful difference…
Both are non-subfolder, Docker, login required, SSO-enabled instances with almost the same plugins.

6

That’s why this is so hard to diagnose. You have two “identical” sites and… one is different. We’ve never been able to repro this problem, but it has been reported a fair number of times.

1 Like
7

Okay, I thought a bit more about the possible differences…

  • Both sites ran the same version of Discourse.
  • Both sites temporarily ran the exact same set of plugins for testing.
  • The site settings in the Onebox category are identical.
  • The site settings in the Basic Setup category are identical.
  • The remaining site settings are not identical, but no difference seems related to oneboxing.
  • The language settings in app.yml are identical.
  • Both sites run under a nginx proxy handling SSL.
  • Both sites are non-subfolder-installs.
  • Of course, both sites are supported Docker installs.
  • Both sites are running on Ubuntu 14.

Some differences:

  • The site with the broken Oneboxes failed the automatic upgrade to Postgres 9.5.
  • The site with the broken Oneboxes is running on a fourth-level domain; the other one is running on a third-level domain.

I’m not sure whether local oneboxes have ever been working in the broken instance.

1 Like
8

What does this mean?

1 Like
9

The working instance is running on discourse.example.com, the broken one is project-discourse.department.example.com – so it’s a subdomain of a subdomain.

1 Like
10

I have an instance on forum.intranet.company.com.br (5 level domain) that works fine.

With SSO enabled too.

Can you try to peek at /var/discourse/shared/standalone/rails/production.log at the one boxing time?

Remember to use a new url, since discourse caches results, and there will be a stack trace there.

3 Likes
11

Here is the log entry for this corresponding call:

Started GET "/onebox?url=https%3A%2F%2Fvorkurs-discourse.cs.uni-saarland.de%2Ft%2Fbijektivitaet%2F547&refresh=false" for 188.210.56.176 at 2016-06-18 09:35:52 +0000
Processing by OneboxController#show as HTML
  Parameters: {"url"=>"https://vorkurs-discourse.cs.uni-saarland.de/t/bijektivitaet/547", "refresh"=>"false"}
  Rendered text template (0.0ms)
Completed 200 OK in 53ms (Views: 12.6ms | ActiveRecord: 17.3ms)

That looks fine, I think :confused:

12

I found the problem – and it is a rather stupid one :blush:

https://meta.discourse.org/t/internal-oneboxing-does-not-work-on-topics-in-private-categories/24917/13?u=fefrei

I ran into this exact problem.

Sorry for wasting your time, @codinghorror and @Falco :worried:

5 Likes