Openid Configuration Http/Https

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

Hi pringi ,

I deployed squidex 7.3.0 on my k8s cluster , i have exact the same issue as you reported , but i still can not fix it .

Hi Sebastian,
will you fix this issue and release a new version ?

Can you just describe the problem again? Because from reading this post it seems it was a misconfigration.

Hi ,Sebastian

For the configration : ASPNETCORE_URLS=http://+:5000 , do i need to change it to ASPNETCORE_URLS=https://+:5000 if the baseurl is https .

after change ASPNETCORE_URLS=https://+:5000 .
I got this error :

Unhandled exception. System.InvalidOperationException: Unable to configure HTTPS endpoint. No server certificate was specified, and the default developer certificate could not be found or is out of date.
To generate a developer certificate run ‘dotnet dev-certs https’. To trust the certificate (Windows and macOS only) run ‘dotnet dev-certs https --trust’.
For more information on configuring HTTPS see https://go.microsoft.com/fwlink/?linkid=848054.
at Microsoft.AspNetCore.Hosting.ListenOptionsHttpsExtensions.UseHttps(ListenOptions listenOptions, Action1 configureOptions) at Microsoft.AspNetCore.Server.Kestrel.Core.Internal.AddressBinder.AddressesStrategy.BindAsync(AddressBindContext context, CancellationToken cancellationToken) at Microsoft.AspNetCore.Server.Kestrel.Core.Internal.AddressBinder.BindAsync(IEnumerable1 listenOptions, AddressBindContext context, CancellationToken cancellationToken)
at Microsoft.AspNetCore.Server.Kestrel.Core.KestrelServerImpl.BindAsync(CancellationToken cancellationToken)
at Microsoft.AspNetCore.Server.Kestrel.Core.KestrelServerImpl.StartAsync[TContext](IHttpApplication`1 application, CancellationToken cancellationToken)
at Microsoft.AspNetCore.Hosting.GenericWebHostService.StartAsync(CancellationToken cancellationToken)
at Microsoft.Extensions.Hosting.Internal.Host.StartAsync(CancellationToken cancellationToken)
at Microsoft.Extensions.Hosting.HostingAbstractionsHostExtensions.RunAsync(IHost host, CancellationToken token)
at Microsoft.Extensions.Hosting.HostingAbstractionsHostExtensions.RunAsync(IHost host, CancellationToken token)
at Microsoft.Extensions.Hosting.HostingAbstractionsHostExtensions.Run(IHost host)
at Squidex.Program.Main(String[] args) in /src/src/Squidex/Program.cs:line 17

These are two different things:

  • ASPNETCORE_URLS tells the web server (kestrel) on which URL to listen. If you use https, you need to specify a certificate. But I recommend to let the reverse proxy handle that for you.
  • URLS__BASEURL is the the public facing URL that is used. When you have Squidex behind 3 layers of proxies and load balancers this URL can get lost and therefore you have to configure it. It is needed to generate some URLs, e.g. for authentication.