Can't display help page on self-hosted Redash sidebar about website

[lucydodo]

Hi @kiwi-26, Thank you for reporting this.
Since we are deploying our website through Netlify, I think we can fix it by changing the Netlify headers settings.

However, I don't have access to our Netlify account, so I'll reach out to someone who does and see if they can resolve the issue and get back to you. In the meantime, Thank you for your patience. :)

[eradman]

Sidebar works for me again! Nice work @lucydodo

[eradman]

This appears to be a recent change in Netlify:

https://answers.netlify.com/t/breaking-change-x-frame-options-set-to-deny/102220

Which we can override by setting custom headers

https://www.gatsbyjs.com/docs/how-to/previews-deploys-hosting/headers/

[eradman]

I created a free Netlify account and a Gasby demo site and could not find a way to disable this header.

The problems caused by the injected X-Frame-Options header has been discussed many times on the forums, and othersare still searching for a valid workaround

https://answers.netlify.com/t/remove-inherited-header-applied-by-splat-path-in-headers/26263

[lucydodo]

Cool, I think I found a workaround.

[lucydodo]

Hi @kiwi-26,
This issue will be resolved by the 7f2e8bc commit. Could you please check it out and let us know? :)

[lucydodo]

@eradman Glad to hear that. I'll close this issue once I get a response from the author :)

[kiwi-26]

@lucydodo Thank you for your work! I can now view the help in the sidebar again.

[eradman]

When we look at gatsby-config.js it appears that we already try to prevent Netlify from adding security headers

    {
      resolve: 'gatsby-plugin-netlify',
      options: {
        mergeSecurityHeaders: false,
        mergeCachingHeaders: true,
      },
    },

[lucydodo]

I'm thinking that maybe after the recent "update all outdated packages" PR(#703) was merged, that plugin might have been conflicting with Gatsby5. I'm on mobile so it's hard to tell right now, but I'll check it out on desktop in the morning.

[lucydodo]

No, from reading the link @eradman posted, it appears that Netlfiy automatically injects the adapter and ignores the configuration we setted. Let's wait for a response from @arikfr .

[justinclift]

Hmmm. Just to ask the dumb question... "but it was working before yeah?". 😄

If that's the case, then it sounds like there must be something under our control that can be change the behaviour.

[justinclift]

Hmmm, since this is affecting everyone - including existing users in production - we'll need to figure out a solution.

If we can't get it working through Netlify, then we could potentially host it elsewhere instead. It's a static website so it's not going to be difficult hosting wise. Can easily add a new virtual host to one of the existing sqlitebrowser.org servers without breaking a sweat.

Arik could probably change the IP addresses (both IPv4 and IPv6) to point at the newer thing if that's the direction to take. 😄

[justinclift]

k. Sounds like we should probably roll back the big website update temporarily to get things working for now, and probably deploy the production website to new hosting when @arikfr is around. Dev previewing on Netlify seems like it'll keep working fine, so no need to change that.

New hosting wise, it'll be trivially easy to add an extra virtual host to the existing sqlitebrowser.org server. @lucydodo already has an ssh login for that server, and I'm happy to add accounts for @eradman and @arikfr as well if that'd be useful?

When new hosting is sorted out, then we could re-apply the big website update.

Thoughts?

[eradman]

k. Sounds like we should probably roll back the big update temporarily to get things working for now, and probably deploy the production website to new hosting when @arikfr is around. Dev previewing on Netlify seems like it'll keep working fine, so no need to change that.

@lucydodo do you know if rolling back fix this? I have not been able to figure out what caused Netlify to switch to the new policy.

[lucydodo]

If we can't get it working through Netlify, then we could potentially host it elsewhere instead.

@justinclift Our web relies heavily on Netlify, so it's harder than we might think. :(
I deployed it through AWS so we could test our last #703 PR, and I ran into a lot of issues.

@eradman To be honest, I'm not sure.
It used to be that the 'X-Frame-Options' header value could be controlled bvy the 'gatsby-plugin-netlify' plugin, but that plugin was disabled when Netlify provides its own adapter, and that's what's causing the problem.

However, according to Netlify's official blog post(*), starting with version [email protected], we can use the new adapter provided by Netlify instead of the 'gatsby-plugin-netlify' plugin, but it's not clear if this means that older versions of Gatsby can disable the new adapter and use the old plugin again.

For now, I'll create some experimental RPs to test it out and hopefully figure it out in the next few hours.

*: https://www.netlify.com/blog/gatsby-adapters-realize-the-full-potential-of-gatsby-on-your-platform/