Internal links stopped oneboxing in login-required instance

(Felix Freiberger) #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?

(Jeff Atwood) #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.

(Felix Freiberger) #3

I just testet curling from both 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?

(Rafael dos Santos Silva) #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.

(Felix Freiberger) #5

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

(Jeff Atwood) #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.

(Felix Freiberger) #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.

(Jeff Atwood) #8

What does this mean?

(Felix Freiberger) #9

The working instance is running on, the broken one is – so it’s a subdomain of a subdomain.

(Rafael dos Santos Silva) #10

I have an instance on (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.

(Felix Freiberger) #11

Here is the log entry for this corresponding call:

Started GET "/onebox?" for at 2016-06-18 09:35:52 +0000
Processing by OneboxController#show as HTML
  Parameters: {"url"=>"", "refresh"=>"false"}
  Rendered text template (0.0ms)
Completed 200 OK in 53ms (Views: 12.6ms | ActiveRecord: 17.3ms)

That looks fine, I think :confused:

(Felix Freiberger) #12

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

I ran into this exact problem.

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

(Régis Hanol) #13