[x] Used code blocks with ``` to format my code examples like JSON or logs properly.
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
Squidex Login sreen disappears quickly when using the noproxy dockerized version of Squidex behind apache proxy. Apache proxy is running on “mydomain.com” while Squidex is running on “mysquidexdomain.com”
Expected behavior
Login route and all other authenticated route would work properly behind an apache proxy when using the noproxy dockerized version of Squidex
Minimal reproduction of the problem
Downloaded docker-compose-noproxy.yml as well as the .env file, according to the documented steps for running Squidex out of docker containers.
Configured .env withSQUIDEX_DOMAIN=mydomain.com. This domain name is the public facing domain name of the intended apache proxy server, not the Squidex server.
built/ran containers with docker compose up -d
Inserted the following proxy directives into apache’s httpd.conf:
Note that I’m using plaintext http for the Squidex backend and not https.
Visited “mydomain.com”. The site loaded and the landing/front page of Squidex was visible, but upon pressing the login button, it quickly disappeared.
I suspect this fault occurs due to an insufficient Apache proxy setup towards the Squidex backend, so any help/guide to valid apache proxy directives for Squidex would be greatly appreciated.
To isolate the issue, also rebuilt and reran the noproxy docker image of Squidex with mysquidexdomain.com as baseurl in the .env file directly, to check if the noproxy version worked without using any proxy. That seemingly worked well, so I guess the question is whether there’s some documentation on how to use Squidex behind an apache Proxy that’s located on a separate server than Squidex itself.
Many thanks in advance!
Environment
App Name:
[x] Self hosted with docker
[ ] Self hosted with IIS
[ ] Self hosted with other version
[ ] Cloud version
Version: [7.8.1 latest through docker noproxy image]
Squidex simply shows the 404 page (not found). I’ll try to set the X-Forwarded-Proto, although the domain name of the apache proxy seems to be passed on to the backend considering the first landing page (that’s showing the login button) actually works on: Squidex Headless CMS (uio.no). Also, the openid configuration page (That’s shown upon first use for a fresh containerized installation) also seemingly worked as I was seemingly able to set an admin e-mail user and an associated password using the https proxy domain name. The failure happened during the subsequent attemt to login using the login button that prompts the login popup window.
By “host name” via X-Forwarded-Proto, you are referring to the domain name of the publicly available proxy server, correct?
Edit: The above response was served from the Squidex backend as plaintext http, so I added a https redirect for all requests to https://cms2.engagelab.uiocloud.no. Now the error message on the client and (in browser) is:
Guess I’m looking for answers on how to configure the correct openid endpoint so that the Squidex backend (that’s stilling using http) can server them back through the proxy that’s using https.
Another update from my side: After reading even more about the use of base url, I did the following:
Stopped the containers with “docker compose down” on the Squidex application host.
Deleted /etc/squidex to start afresh.
Edited docker-compose.yml (That is, the noproxy version that I’ve simply renamed to docker-compose.yml so that the docker command recognizes the default YML file) where I added an “s” to the base URL to configure it for https, so that the line in docker-compose.yml now is:
URLS__BASEURL=https://${SQUIDEX_DOMAIN}
Ran docker compose up -d to rebuild and run a fresh installation
However, as the attached imaged shows, Squidex clearly doesn’t regognize the https proxy, and it’s also an error message related to https versus http confusion regarding the baseURL:
After completing the initial setup regardless by adding an initial admin user, it seemingly stores the user and I’m redirected corretly to the first landing page again. However, upon pressing the Login button, it’s back to quickly disappearing. Another symptom is that the path to the well-known openid configuration is once again not working.
In essence, It’s closer to a solution when baseURL in docker-compose.yml remains http only.
Is there somewhere else that the baseURL should be set to https other than that in docker-compose.yml perhaps?
Hurra. Seems a bit step forward, added the X-Forwarded-Host and X-Forwarded-proto to httpd.conf, so that the entire proxypass/proxypassreverse setup in the https virtual host is as follows:
Proxy settings (if you are using Apache as a reverse proxy)
ProxyPreserveHost on
ProxyPass / http://cms3.engagelab.uiocloud.no/
ProxyPassReverse / http://cms3.engagelab.uiocloud.no/
RequestHeader set X-Forwarded-Proto "https"
RequestHeader set X-Forwarded-Host "dev2.kapteinmorf.uvapps.uio.no"
Also stopped the containers by docker compose down again, as well as removing /etc/squidex to start fresh once again.
After this, dev2.kapteinmorf.uvapps.uio.no now shows the initial config page correctly, and the two first checks for https and canonical URL now are greenlighted correctly, so they seem ok. I’m then able to create a new admin user, and it redirects me correctly to the admin authenticated dashboard afterwards. Yay!
However, seems like a slight bug somewhere…Upon logging out and logging in again, I tried the following:
Log out of squidex admin dashboard
Click login button again, correctly shows the login popup window
I authenticate with my admin user.
I get a “” This page isn’t working right now
If the problem continues, contact the site owner.
HTTP ERROR 400"" that is shown within the popup window.
A workaround is simply to try to login again by clicking the login button, authenticate with my admin user, and then it works. Seems to be fairly consistent to be working on the 2nd attempt, so not sure if this is something with our setup or a bug within Squidex though.
The URL in the popup window during the 1st attempt when it fails, is:
By inspecting the above url it is indeed using https now, so to the best of my knowledge authentication with openid now runs correctly and consumer friendly through proxy with ssh/tls on the client facing url…
So not sure what’s exactly happening here, considering it does work at 2nd attempt.
