Openid Configuration Http/Https

Support
1

Hi Sebastian,

I host Squidex on my own server.
I have a web server and application server. I have an ssl certificate installed on my web server. With the ARR configuration here, I transfer the incoming requests to the application server as http. Actually Squidex is running as http in the background. But when this happens, the user cannot login. The http and https confusion becomes a problem.

Since I can’t install an ssl certificate on the application server, I can’t run both sides as https.

Since the /openid-configuration part on the identity side serves over http, it does not come when called over https, or there is a conflict between the baseUrl and the background url when trying to login.

Can you advise me something to solve this?

2

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.

3

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

4

With “/identity-server”?`

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

5

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

6

BaseUrl: https ;

image
image1658×809 20.5 KB

BaseUrl: http ;

image
image1688×777 20.1 KB

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

7

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

8

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

9

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

10 
{
   "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

11

Thats not from Squidex.

12

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

image
image1751×760 20.4 KB

image
image1918×977 44.9 KB

13

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?

14

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.

15

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

16

With a reverse proxy?

17

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

18

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
19

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

image
image1535×462 43.8 KB

20

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