Proxy issues when running Squidex noproxy docker image behind an Apache proxy that is located on another server

Support
#1

I have…

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

  1. Downloaded docker-compose-noproxy.yml as well as the .env file, according to the documented steps for running Squidex out of docker containers.

  2. 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.

  3. built/ran containers with docker compose up -d

  4. Inserted the following proxy directives into apache’s httpd.conf:

Note that I’m using plaintext http for the Squidex backend and not https.

```# Proxy settings to proxy to Squidex backend

ProxyPass / http://mysquidexdomain.com/
ProxyPassReverse / http://mysquidexdomain.com/
```
5) Restarted httpd (apache)

  1. 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]

Browser:

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

Others:

#2

I would check, if …

  1. All URLS are configured properly: https://cloud.squidex.io/identity-server/.well-known/openid-configuration
  2. The host name is passed through properly via X-Forwarded-Proto
#3

Thanks for your your swift reply!

Actually, I can see that the identity-server path is not recognized on the public domain url (that is, the domain name on the apache proxy server).

When entering:
Not Found - Squidex Headless CMS (uio.no).

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?

#4

Update on this case:

Was able to use the proxypreservehost on directive in apache, so that the proxy apache config is now:

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/

Now at least the path that lists the other url endpoint works:
dev2.kapteinmorf.uvapps.uio.no/identity-server/.well-known/openid-configuration

Also, the path of the well known key seems to be working through https proxy now:
https://cms2.engagelab.uiocloud.no/identity-server/.well-known/jwks

Current behaviour is that the login popup window is now at least shown without closing immediatly, so I’ve gotten one step further.

However, the text “I am sorry that something went wrong” shows instead of the login input fields.
The URL/Query in that pop up box was:

Error - Squidex Headless CMS (uio.no)

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:

error:invalid_request
error_description:The specified ‘redirect_uri’ is not valid for this client application.
error_uri:https://documentation.openiddict.com/errors/ID2043

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.

#5

Another update from my side: After reading even more about the use of base url, I did the following:

  1. Stopped the containers with “docker compose down” on the Squidex application host.

  2. Deleted /etc/squidex to start afresh.

  3. 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

Visited the Squidex installation on the public URL https://dev2.kapteinmorf.uvapps.uio.no/ - which correctly redirects to the initial setup page on https://dev2.kapteinmorf.uvapps.uio.no/identity-server/setup.

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:

fresh-squidex-after-docker-compose
fresh-squidex-after-docker-compose600×970 47.2 KB

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?

#6

The BASE__URL setting is basically used to create URLs outside of http requests.

But to work properly, the request also needs to point to the current host name. These 2 headers are important:

  • X-Forwarded-Host (For host name)
  • X-Forwared-Proto (For protocol, e.g. http, https)

The first 2 warnings in the checklist should not be critical. The creation of the initial user has nothing to do with the authentication process.

#7

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:

  1. Log out of squidex admin dashboard
  2. Click login button again, correctly shows the login popup window
  3. I authenticate with my admin user.
  4. 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.
  5. 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:

(https://dev2.kapteinmorf.uvapps.uio.no/identity-server/account/login?returnurl=%2Fidentity-server%2Fconnect%2Fauthorize%3Fclient_id%3Dsquidex-frontend%26redirect_uri%3Dhttps%3A%2F%2Fdev2.kapteinmorf.uvapps.uio.no%2Fclient-callback-popup.html%26response_type%3Dcode%26scope%3Dsquidex-api%20openid%20profile%20email%20permissions%26state%3Df840e7a81dbd4c0aba31d4b9cdc47d88%26code_challenge%3DS7fEqaznnJC_m3s92X-3krU7w9_LA26InZYOVlyl-Ow%26code_challenge_method%3DS256%26display%3Dpopup%26response_mode%3Dquery)

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.

#8

I also don’t know. Sorry.

#9

Yeah, hard to debug, thanks anyway.

Seeing that the userinfo endpoint is not working actually, it simply throws a “HTTP ERROR 401”

https://dev2.kapteinmorf.uvapps.uio.no/identity-server/connect/userinfo

Browser (Edge) network debugger shows:

Request URL:

https://dev2.kapteinmorf.uvapps.uio.no/identity-server/connect/userinfo

Request Method:

GET

Status Code:

401 Unauthorized

Remote Address:

129.240.121.74:443

Referrer Policy:

strict-origin-when-cross-origin

So 1st attempt logon failure might be connected to that somehow…