I have…
I’m submitting a…
- [ ] Regression (a behavior that stopped working in a new release)
- [ ] Bug report
- [ ] Performance issue
- [ ] Documentation issue or request
Current behavior
Expected behavior
Minimal reproduction of the problem
Environment
App Name:
- [ ] Self hosted with docker
- [ ] Self hosted with IIS
- [ ] Self hosted with other version
- [ ] Cloud version
Version: [VERSION]
Browser:
- [ ] Chrome (desktop)
- [ ] Chrome (Android)
- [ ] Chrome (iOS)
- [ ] Firefox
- [ ] Safari (desktop)
- [ ] Safari (iOS)
- [ ] IE
- [ ] Edge
Others:
is it possible to remove base url setting ?
why a domain name must be given and bind to squidex ?
could squidex be a service listening on a port and you can resolve whatever domain name to that port ?
There are 2 reasons:
- Squidex needs to generate URLs from background processes.
- Squidex needs to generate URLs for authentication, e.g. something like this: https://cloud.squidex.io/identity-server/.well-known/openid-configuration
But why do we need the setting?
-
Sometimes Squidex is accessed from multiple URLs, e.g. a health check calls localhost and the end users call your-domain. If we store the URL for the background-processes somewhere it is hard to say which is the correct URL. I have used a library in the past, which was doing exactly that and in < 5% of the deployments the wrong URL was stored and nothing worked anymore.
-
Squidex is very often not hosted directly as frontend server. So, in my cases I have fastly -> cloudflare -> Google Load Balancer -> Kubernetes Ingress -> Squidex. And all these services need to transport the host correctly. There is a header for that, but it is not always supported: https://developer.mozilla.org/en-US/docs/Web/HTTP/Headers/X-Forwarded-Host
Thanks for your reply , i just wondering is there a better way to deal with this setting , because when i am doing a squidex migration , this setting just makes things more complex.
I don’t see one and it does not happen so often that Squidex is moved from one server to another.