[IMPLEMENTED] Hosting in a restricted environment

maxisam · July 14, 2021, 4:42pm

I’m submitting a…

[ ] Regression (a behavior that stopped working in a new release)
[ ] Bug report
[ ] Performance issue
[X] Documentation issue or request

Current behavior

If it is hosted in a restricted environment, the cluster monitor (/app/administration/cluster) won’t work.

Expected behavior

It should work

Minimal reproduction of the problem

Enable firewall on the host of Squidex

I think it is because it somehow uses port 80 for certain cloudflare CDN calls.
However, I am still trying to track down where they are but there are 2 calls for sure.

Can we avoid this behavior?
Can we at least make all calls as https?

Environment

[X] Self hosted with docker
[ ] Self hosted with IIS
[ ] Self hosted with other version
[ ] Cloud version

Version: [dev-6140]

Browser:

[X] Chrome (desktop)
[ ] Chrome (Android)
[ ] Chrome (iOS)
[ ] Firefox
[ ] Safari (desktop)
[ ] Safari (iOS)
[ ] IE
[ ] Edge

Others:

Sebastian · July 14, 2021, 5:11pm

A lot of effort has been put into this case before. But not all cases might have been found.

E.g. this is the reason why all external libraries (that are loaded on demand) are copied over:

github.com

Squidex/squidex/blob/master/frontend/app-config/webpack.config.js#L252


 */
new plugins.CircularDependencyPlugin({
    exclude: /([\\\/]node_modules[\\\/])|(ngfactory\.js$)/,
    // Add errors to webpack instead of warnings
    failOnError: true,
}),

/*
 * Copy lazy loaded libraries to output.
 */
new plugins.CopyPlugin({
    patterns: [
        { from: './node_modules/simplemde/dist', to: 'dependencies/simplemde' },

        { from: './node_modules/tinymce/icons/default/icons.min.js', to: 'dependencies/tinymce/icons/default' },
        { from: './node_modules/tinymce/plugins/advlist', to: 'dependencies/tinymce/plugins/advlist' },
        { from: './node_modules/tinymce/plugins/code', to: 'dependencies/tinymce/plugins/code' },
        { from: './node_modules/tinymce/plugins/image', to: 'dependencies/tinymce/plugins/image' },
        { from: './node_modules/tinymce/plugins/link', to: 'dependencies/tinymce/plugins/link' },
        { from: './node_modules/tinymce/plugins/lists', to: 'dependencies/tinymce/plugins/lists' },
        { from: './node_modules/tinymce/plugins/media', to: 'dependencies/tinymce/plugins/media' },

It would help if you would just post the URLs you have seen.

Sebastian · July 14, 2021, 5:15pm

Sorry, I have not seen first, that it is about Orleans Dashboard.

I have contributed a lot to the project, but it is nothing I can change in Squidex.

There are a few calls to CDN, though. So I recommend to provide a PR there:

github.com

OrleansContrib/OrleansDashboard/blob/90ad92eac2b94336aba4db4962cf5d98e9f5efa6/OrleansDashboard/Index.html

<!DOCTYPE html>
<html>
  <head>
    <meta charset="utf-8" />
    <meta http-equiv="X-UA-Compatible" content="IE=edge" />
    <base href="{{BASE}}" />
    <title>Orleans Dashboard</title>
    <meta
      content="width=device-width, initial-scale=1, maximum-scale=1, user-scalable=no"
      name="viewport"
    />
    <link
      rel="stylesheet"
      href="//maxcdn.bootstrapcdn.com/bootstrap/3.3.7/css/bootstrap.min.css"
    />
    <link
      rel="stylesheet"
      href="//cdnjs.cloudflare.com/ajax/libs/font-awesome/5.15.2/css/all.min.css"
    />
    <link

This file has been truncated. show original

Sebastian · July 14, 2021, 5:27pm

I created an issue for it to track it there:

maxisam · July 14, 2021, 5:28pm

Well, the index.html in Orleans dashboard that was my first suspect but after putting more thought, I think it is irreverent.

It is a page that is loaded in client browser.

I think it has something to do with authentication.

Because I can see it was trying to load /identity-server/.well-known/openid-configuration but failed.

Sebastian · July 14, 2021, 5:30pm

Yes, sure. But html is always loaded in the client browser.

This would only a problem if you would issues like redirect loops or something like this. But I cannot test it for you.

maxisam · July 14, 2021, 5:35pm

no, I don’t think it is redirect loop.

Because my setup works fine after my network admin allowed 2 calls from port 80 to cloudflair

I think it is something from spuidex trying to reach cloudflair but I can’t pin point the request.

However, I think it is safe to exclude the request from client side

Sebastian · July 14, 2021, 5:54pm

I am pretty sure that cloud flare is not involve in the authentication flow.

But I need the URLs.

maxisam · July 14, 2021, 6:16pm

I know. I went through the code and I couldn’t find anything either.

And the weird thing is we remove the rules on firewall (killed the pod and ran it again) and it is still working fine.

I honestly don’t know what is going on at this point. I will update if I find anything.

maxisam · July 14, 2021, 6:43pm

ok, it only happens when I have a brand new database. Need to dig deeper but the problem becomes less severe, because it is more like a one time thing

Sebastian · July 14, 2021, 7:12pm

Is it on the setup page?

maxisam · July 14, 2021, 7:18pm

I think I found the root of the issue. It is from the authentication flow, but it also has something to do with our certificate.

We use DigiCert. And the server sends out a request to cdn.digicertcdn.com to verify it during authentication flow. (because of /identity-server/.well-known/openid-configuration)

And I think that was the reason.

maxisam · July 14, 2021, 7:22pm

I think one thing we can do is don’t use .well-known doc. We use the configuration file directly from environment settings.
But again, it is not very severe now, so you can deal it whatever you like.

Sebastian · July 14, 2021, 7:23pm

I see. This makes sense.

Sebastian · July 14, 2021, 7:24pm

But I also found two other cases where CDN was used:

maxisam · July 14, 2021, 7:28pm

those are fine I think. They are in the frontend, so they are client browsers’ issue. Unless users are trying to access from a restricted environment, it should be fine.

The one I am talking about is from the server side, because the server need to verify the token before serving the dashboard.

Sebastian · July 14, 2021, 7:29pm

I have fixed both cases. Only orleans dashboard is left afaik.

maxisam · July 14, 2021, 7:33pm

That is good for the long run, so you don’t need to worry about users might not be able to browse the site behind the firewall.

Sebastian · July 15, 2021, 10:27am

3 changes have been implemented:

Do not use CDN for Orleans Dashboard
Do not use CDN for outdated-browser
Do not use CDN for leaflet.js (for geolocation fields)

I do not see more CDN calls.

system · July 17, 2021, 10:26am

This topic was automatically closed after 2 days. New replies are no longer allowed.