After upgrade to 6.6.0 version login no longer works

I have…

I’m submitting a…

  • [X] Regression (a behavior that stopped working in a new release)

Current behavior

When accessing the main base URL to login for the first time, it appears the login page with the “Login to Squidex” button. When clicking that button, an error is displayed in the popup window, said “Opss…”.

In squidex logs the following appear:

{
“logLevel”: “Error”,
“message”: “An unhandled exception has occurred while executing the request.”,
“eventId”: {
“id”: 1,
“name”: “UnhandledException”
},
“timestamp”: “2022-04-01T09:07:39Z”,
“app”: {
“name”: “Squidex”,
“version”: “6.6.0.0”,
“sessionId”: “f42cad75-121c-46ab-bbc3-3fe025fa3ee3”
},
“web”: {
“requestId”: “00-91c60c79fa22c63fa35c14afff07cd29-778346cc3b4e4fef-01”,
“requestPath”: “/identity-server/connect/authorize”,
“requestMethod”: “GET”
},
“category”: “Microsoft.AspNetCore.Diagnostics.ExceptionHandlerMiddleware”,
“exception”: {
“type”: “System.InvalidOperationException”,
“message”: “The OpenID Connect request cannot be retrieved.”,
“stackTrace”: " at Notifo.Areas.Account.Controllers.AuthorizationController.Authorize() in /src/src/Squidex/Areas/IdentityServer/Controllers/Connect/AuthorizationController.cs:line 119\n at Microsoft.AspNetCore.Mvc.Infrastructure.ActionMethodExecutor.TaskOfIActionResultExecutor.Execute(IActionResultTypeMapper mapper, ObjectMethodExecutor executor, Object controller, Object[] arguments)\n at Microsoft.AspNetCore.Mvc.Infrastructure.ControllerActionInvoker.\u003CInvokeActionMethodAsync\u003Eg__Logged|12_1(ControllerActionInvoker invoker)\n at Microsoft.AspNetCore.Mvc.Infrastructure.ControllerActionInvoker.\u003CInvokeNextActionFilterAsync\u003Eg__Awaited|10_0(ControllerActionInvoker invoker, Task lastTask, State next, Scope scope, Object state, Boolean isCompleted)\n at Microsoft.AspNetCore.Mvc.Infrastructure.ControllerActionInvoker.Rethrow(ActionExecutedContextSealed context)\n at Microsoft.AspNetCore.Mvc.Infrastructure.ControllerActionInvoker.Next(State\u0026 next, Scope\u0026 scope, Object\u0026 state, Boolean\u0026 isCompleted)\n at Microsoft.AspNetCore.Mvc.Infrastructure.ControllerActionInvoker.InvokeInnerFilterAsync()\n— End of stack trace from previous location —\n at Microsoft.AspNetCore.Mvc.Infrastructure.ResourceInvoker.\u003CInvokeNextResourceFilter\u003Eg__Awaited|25_0(ResourceInvoker invoker, Task lastTask, State next, Scope scope, Object state, Boolean isCompleted)\n at Microsoft.AspNetCore.Mvc.Infrastructure.ResourceInvoker.Rethrow(ResourceExecutedContextSealed context)\n at Microsoft.AspNetCore.Mvc.Infrastructure.ResourceInvoker.Next(State\u0026 next, Scope\u0026 scope, Object\u0026 state, Boolean\u0026 isCompleted)\n at Microsoft.AspNetCore.Mvc.Infrastructure.ResourceInvoker.InvokeFilterPipelineAsync()\n— End of stack trace from previous location —\n at Microsoft.AspNetCore.Mvc.Infrastructure.ResourceInvoker.\u003CInvokeAsync\u003Eg__Logged|17_1(ResourceInvoker invoker)\n at Microsoft.AspNetCore.Mvc.Infrastructure.ResourceInvoker.\u003CInvokeAsync\u003Eg__Logged|17_1(ResourceInvoker invoker)\n at Microsoft.AspNetCore.Routing.EndpointMiddleware.\u003CInvoke\u003Eg__AwaitRequestTask|6_0(Endpoint endpoint, Task requestTask, ILogger logger)\n at Microsoft.AspNetCore.Authorization.AuthorizationMiddleware.Invoke(HttpContext context)\n at Microsoft.AspNetCore.Authentication.AuthenticationMiddleware.Invoke(HttpContext context)\n at Microsoft.AspNetCore.Diagnostics.ExceptionHandlerMiddleware.\u003CInvoke\u003Eg__Awaited|6_0(ExceptionHandlerMiddleware middleware, HttpContext context, Task task)"
}
}

Expected behavior

The same behavior than on version 6.4.0. The login page to put the credentials should appear.

Minimal reproduction of the problem

services:
  mymongodb:
    image: mongo:5.0.5
    container_name: mymongodb
    networks:
      my-net:
        ipv4_address: 172.21.0.10

  mysquidex:
    image: "squidex/squidex:6.6.0"
    container_name: mysquidex
    environment:
      - URLS__BASEURL=https://${SQUIDEX_DOMAIN}
      - EVENTSTORE__TYPE=MongoDB
      - EVENTSTORE__MONGODB__CONFIGURATION=mongodb://mymongodb
      - STORE__MONGODB__CONFIGURATION=mongodb://mymongodb
      - 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}
      - ASPNETCORE_URLS=http://+:5000
    healthcheck:
      test: ["CMD", "curl", "-f", "http://localhost:5000/healthz"]
      start_period: 60s
    depends_on:
      - mymongodb
    networks:
      my-net:
        ipv4_address: 172.21.0.11

.env file:

SQUIDEX_DOMAIN=some.domain.com
SQUIDEX_ADMINEMAIL=a.valid.email@any.com
SQUIDEX_ADMINPASSWORD=some_password
SQUIDEX_GITHUBCLIENT=
SQUIDEX_GITHUBSECRET=
SQUIDEX_GOOGLECLIENT=
SQUIDEX_GOOGLESECRET=
SQUIDEX_MICROSOFTCLIENT=
SQUIDEX_MICROSOFTSECRET=

Environment

App Name: N/A

  • [X] Self hosted with docker

Version: 6.6.0

Browser:

  • [X] Chrome (desktop)
  • [X] Firefox

Others:

Even a fresh install, without doing the upgrade, has the same problem.

I think it is the same as this: Use squidex API endpoint with local network name inside docker

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.