Squidex Docker - behind Traefik

Support
1

I have…

  • [ x] Checked the logs and have provided the logs if I found something suspicious there

I’m submitting a…

  • [ x] Documentation issue or request

Current behavior

I am running the Standalone (no proxy) docker-compose image behind a Traefik reverse proxy. Docker is running on a self-hosted Ubuntu server.

Note that the domain is a subdomain - so subdomain.real-domain.io. However, I have tried it with the base domain and the issue persists.

The site is accessible via the https URL. When I try to login, I get the IDX20803: Unable to obtain configuration error in the logs. This is the case with username/password and Google login.

When I manually go to the link in the address specified in the error message, I am able to access the configuration data.

When I set the SQUIDEX_PROTOCOL to HTTP and remove the https redirection of Traefik, it works. However, I don’t want the page to be unsecure.

Minimal reproduction of the problem

Here is the error:

IDX20803: Unable to obtain configuration from: \u0027https://url-of-website/identity-server/.well-known/openid-configuration\u0027."

Here is the docker-compose file I use for setup:
version: ‘2.1’
services:
squidex_mongo:
image: mongo:latest
volumes:
- mongo:/data/db
networks:
- internal
restart: unless-stopped

  squidex_squidex:
image: "squidex/squidex"
hostname: ${SQUIDEX_DOMAIN}
environment:
  - URLS__BASEURL=${SQUIDEX_PROTOCOL}://${SQUIDEX_DOMAIN}/
  - URLS__ENFORCEHTTPS=${SQUIDEX_FORCE_HTTPS}
  - EVENTSTORE__MONGODB__CONFIGURATION=mongodb://squidex_mongo
  - STORE__MONGODB__CONFIGURATION=mongodb://squidex_mongo
  - IDENTITY__ADMINEMAIL=${SQUIDEX_ADMINEMAIL}
  - IDENTITY__ADMINPASSWORD=${SQUIDEX_ADMINPASSWORD}
  - IDENTITY__GOOGLECLIENT=${SQUIDEX_GOOGLECLIENT}
  - IDENTITY__GOOGLESECRET=${SQUIDEX_GOOGLESECRET}
  - IDENTITY__GITHUBCLIENT=${SQUIDEX_GITHUBCLIENT}
  - IDENTITY__GITHUBSECRET=${SQUIDEX_GITHUBSECRET}
  - IDENTITY__MICROSOFTCLIENT=${SQUIDEX_MICROSOFTCLIENT}
  - IDENTITY__MICROSOFTSECRET=${SQUIDEX_MICROSOFTSECRET}
  - IDENTITY__SHOWPII=true
  - IDENTITY__PRIVACYURL=http://research.squidex.com/privacy.html
  - REBUILD_APPS=true
depends_on:
  - squidex_mongo
volumes:
  - squidex_assets:/app/Assets
networks:
  - internal
  - external-network
restart: unless-stopped
labels:
  - "traefik.enable=true"
  - "traefik.http.routers.headless-secured.entrypoints=websecure"
  - "traefik.http.routers.headless-secured.rule=Host(`url-of-website`)"
  - "traefik.http.routers.headless-secured.tls.certresolver=challenge"
  - "traefik.http.routers.headless-secured.tls=true"
  - "traefik.http.routers.headless.entrypoints=web"
  - "traefik.http.routers.headless.rule=Host(`url-of-website`)"
  - "traefik.http.middlewares.compress.compress=true"
  - "traefik.http.middlewares.redirect.redirectscheme.scheme=https"
  - "traefik.http.routers.headless.middlewares=compress,redirect"
  - "traefik.http.routers.headless-secured.middlewares=compress"

networks:
  external-network:
external: true
  internal:
driver: bridge

volumes:
  mongo:
  squidex_assets:

Here is the env file:
SQUIDEX_PROTOCOL=https
SQUIDEX_FORCE_HTTPS=False
SQUIDEX_DOMAIN=url-of-website
SQUIDEX_ADMINEMAIL=example-email
SQUIDEX_ADMINPASSWORD=example-password2009!!
SQUIDEX_GITHUBCLIENT=
SQUIDEX_GITHUBSECRET=
SQUIDEX_GOOGLECLIENT=
SQUIDEX_GOOGLESECRET=
SQUIDEX_MICROSOFTCLIENT=
SQUIDEX_MICROSOFTSECRET=

Environment

  • [ x] Self hosted with docker
  • [ ] Self hosted with IIS
  • [ ] Self hosted with other version
  • [ ] Cloud version

Version: [VERSION]

Browser:

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

Others:

2

Hi, the only idea I have right now: https://docs.squidex.io/01-getting-started/installation/install-docker#i-cannot-login-and-see-a-idx20803-error-code-in-my-logs

3

Hi,

Yeah I had a look at that, but doesn’t seem to be the issue from what I can see.

I’ve tried forwarded on the X-FORWARDED-PROTO/HOST headers and that doesn’t work either.

Is there any reason why it would work over http, but not over https? All I’m changing to make it work is base_url https to http (also disabling force_https). Then identity server seems to work.

Additionally, I’m assuming the quotemarks in the URL (escaped in the log) are meant to be there.

4

Sorry, I have not seen the problem with http. Is the cert valid?

5

Hi,

I think the cert must be valid, as it’s letting me access the site from https. It’s just the .well-known issue that’s occurring.

6

Yes, the well known issue happens when either the cert is not valid for the server (e.g. you could have the installed on your machine, but not on the server) or it cannot reach the url.

7

Ah I see. I think Traefik sets everything up automatically via LetsEncrypt. Is there a way to tell the difference between whether it cannot reach the url or its an invalid certificate?

8

I don’t think so. You could try to use bash on the container and try to reach the url with curl or so…not sure what is installed

9

Ah good idea.

I’ve tried to CURL from within the container and it says that the connection is refused. I can access the URL from a browser however.

It can access the HTTP version okay.

Is there a way to use just the HTTP version for the .well-known?

10

I’m thinking this may not be an issue directly with Squidex. My only thoughts are maybe a PR allowing customised Identity Server URLs??

I’ve posted on the Traefik forum. I’ll repost here if any useful conclusions from there.

1 Like
11

Your PR is also a good idea. As you can see in the docs, I have also faced this issue before. In general reaching “localhost” seems to be an issue in docker and kubernetes. In another scenario we had a issue where a deployment script that was deployed on the same pod was not able to invoke the API, sometimes the connection was dropped with the first request, sometimes 5 secs later.