[IMPLEMENTED] Hosting in a restricted environment

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.

  1. Can we avoid this behavior?
  2. 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:

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:

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

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:

I created an issue for it to track it there:

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.

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.

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

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

But I need the URLs.

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.

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

Is it on the setup page?

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.

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.

I see. This makes sense.

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

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.

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

1 Like

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.

3 changes have been implemented:

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

I do not see more CDN calls.

1 Like

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