Openid Configuration Http/Https

This is why I introduced the base URL, just set it to https and it should work fine. I have the same scenario with the cloud.

The baseURL is the publicly used URL, not the internal URL.

yes, I have configured the baseUrl that way, but it doesn’t work.
“/.well-known/openid-configuration” gets 404 when baseUrl: https.

With “/identity-server”?`

e.g. https://cloud.squidex.io/identity-server/.well-known/openid-configuration

yes with identity-server By the way, I’m using the current version from the master repo.

BaseUrl: https ;

BaseUrl: http ;

As a result of the ARR redirect, the user cannot login when different requests go to the background according to the baseUrl.

But the base URL does have nothing to do with the routing, afaik a wrong base URL cannot cause a 404.

@Sebastian I tried to explain in a top post but can you check?

Can you have a look to the logs, what URL is actually being received by Squidex?

{
   "Timestamp":"2022-09-20T16:23:50.3291418+03:00",
   "Level":"Information",
   "MessageTemplate":"{HostingRequestFinishedLog:l}",
   "Properties":{
      "ElapsedMilliseconds":29.3356,
      "StatusCode":200,
      "ContentType":"text/html",
      "ContentLength":null,
      "Protocol":"HTTP/2",
      "Method":"GET",
      "Scheme":"https",
      "Host":"localhost:5001",
      "PathBase":"",
      "Path":"/index.html",
      "QueryString":"",
      "HostingRequestFinishedLog":"Request finished HTTP/2 GET https://localhost:5001/identity-server/.well-known/openid-configuration - - - 200 - text/html 29.3356ms",
      "EventId":{
         "Id":2
      },
      "SourceContext":"Microsoft.AspNetCore.Hosting.Diagnostics",
      "RequestId":"0HMKR1DD077IF:00000007",
      "RequestPath":"/identity-server/.well-known/openid-configuration",
      "ConnectionId":"0HMKR1DD077IF",
      "MachineName":"DESKTOP-TGF5JPF",
      "ThreadId":17,
      "ProcessName":"Squidex",
      "application":"Squidex",
      "ClientIp":"::1",
      "ClientAgent":"Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/105.0.0.0 Safari/537.36"
   },
   "Renderings":{
      "HostingRequestFinishedLog":[
         {
            "Format":"l",
            "Rendering":"Request finished HTTP/2 GET https://localhost:5001/identity-server/.well-known/openid-configuration - - - 200 - text/html 29.3356ms"
         }
      ]
   }
}

but return not found page.emphasized text

Thats not from Squidex.

I added Serilog for more detailed logging. I think you can reach the same result by trying what I said in your own local.

I have not deployed the 7.X to the cloud yet, but I have a test instance there with https termination on cloudflare and it works fine there.

The default docker-compose setup also does https termination on caddy, also no problem.

Perhaps I do not understand your setup?

This is exactly the same problem as I’ve already reported here: After upgrade to 6.6.0 version login no longer works. Until 6.14.0 the behavior is the same.

On 7.x the problem is not solved also.

I have a test instance with docker compose running 6.8.0 and I do not have this issue.

With a reverse proxy?

Yes, it is this setup: https://github.com/Squidex/squidex-hosting/blob/master/docker-compose/docker-compose.yml

After some changes on the configuration I’ve found root cause for the login having problems.

We are redirecting all HTTP request to HTTPS.

So we access login page on

https://somedomain.com/

After clicking on login button, SQUIDEX sends the following URL (a new window pops up and the following URL is displayed):

http://somedomain.com/identity-server/account/login?ReturnUrl=%2Fidentity-server%2Fconnect%2Fauthorize%3Fclient_id%3Dsquidex-frontend%26redirect_uri%3Dhttps%3A%2F%somedomain.com%2Fclient-callback-popup.html%26response_type%3Dcode%26scope%3Dsquidex-api%20openid%20profile%20email%20permissions%26state%3Df943c76eebd0440e83b21f51764670bf%26code_challenge%3DXpyvXF50VF3jMaLPlv1FP1IiGOkmXnQyg3snaX0TEDg%26code_challenge_method%3DS256%26display%3Dpopup%26response_mode%3Dquery

So, even if we access SQUIDEX on https, somewhere after clicking the login button, a http url is given.

We are using version 7.1.0.

And on docker-compose:

  eticsquidex:
    image: "squidex/squidex:7.1.0"
    container_name: eticsquidex
    restart: unless-stopped  
    environment:
      - URLS__BASEURL=https://${SQUIDEX_DOMAIN}
      - ..
      - ASPNETCORE_URLS=http://+:5000
      - ...

The .env contains:

SQUIDEX_DOMAIN=somedomain.com

That’s normal. Usually the reverse proxy just makes a 30X redirect for all http requests.

On 6.4.0 the same configuration worked. From 6.6.0 onward it does not work.

We are using apache that also uses let’s encrypt to generate the SSL certificate.

We have an exception when forcing http to https due to the way letsencrypt works.
The exception is on “.well-known” request path. This request path does not force https.

The main problem is that the window popup (for login) opens and closes automatically and it is almost impossible to check what was being called.

A further investigation showed that the endpoint “https://somedomain.com/identity-server/.well-known/openid-configuration” was being called. Since 200 OK was returned it was not obvious that the response was not the OIDC standard response (the JSON with all open id connect endpoints and details).

The problem was not on Squidex. The redirect exception rule was rewritten ant the problem was solved.

1 Like

So changed http configuration to this:

  RewriteEngine On

  RewriteCond %{HTTPS} off
  RewriteCond %{REQUEST_URI} !^\/\.well-known\/acme-challenge\/.*$
  RewriteRule (.*) https://REPLACE_BY_PUBLIC_DOMAIN/$1 [R,L]

Also needed to add

`IDENTITY__MULTIPLEDOMAINS=true`

On docker-compose.yml for start working.

1 Like