bug: use docker deploy logto v1.6 will always redirect to /unknown-session

[TheresaQWQ]

Describe the bug

bug: use docker deploy logto v1.6.0 will always redirect to /unknown-session

Expected behavior

not redirect

How to reproduce?

Just like in the screenshot above.

Context

• [ ] Logto Cloud
• [x] Self-hosted, Logto version = v1.6
  • [x] Container (Docker image)
  • [ ] Raw Node.js

Screenshots

[TheresaQWQ]

Some Logs:

[xiaoyijun]

Hi @TheresaQWQ , I'm quite curious about why you're using curl to access the auth endpoint. Authentication-related requests rely on the browser's session, and it's recommended to perform authentication using a web browser. Logto offers a variety of SDKs and guides that helps you integrating Logto into your application. https://docs.logto.io/docs/recipes/integrate-logto/

[TheresaQWQ]

Hi @TheresaQWQ , I'm quite curious about why you're using curl to access the auth endpoint. Authentication-related requests rely on the browser's session, and it's recommended to perform authentication using a web browser. Logto offers a variety of SDKs and guides that helps you integrating Logto into your application. https://docs.logto.io/docs/recipes/integrate-logto/

I got the same problem even with the browser

[github-actions[bot]]

This issue is stale because it has been open for 30 days with no activity. Remove stale label or comment or this will be closed in 5 days.

[leopku]

Same issue by logto 1.7 + docker compose + nginx proxy manager. ENV had set. as below

RUST_PROXY_HEADER=1
ENDPOINT=https://logto.local.dev
ADMIN_ENDPOINT=https://admin-logto.local.dev

[petarordanoski]

Same issue here. I've been trying to make this work all day long. I'm using latest logto + docker run + nginx proxy manager.

[vordan]

Oh, well, time to look for another authentication server... :(

[charIeszhao]

Same issue by logto 1.7 + docker compose + nginx proxy manager. ENV had set. as below

RUST_PROXY_HEADER=1
ENDPOINT=https://logto.local.dev
ADMIN_ENDPOINT=https://admin-logto.local.dev

The first env should be TRUST_PROXY_HEADER instead of RUST

[charIeszhao]

Same issue here. I've been trying to make this work all day long. I'm using latest logto + docker run + nginx proxy manager.

Can you share your nginx config with us?

[wangsijie]

Hi guys, as you are using "https" and reverse proxy, according to the offical doc, you should add X-Forwarded-Proto to your reverser proxy server.

proxy_set_header X-Forwarded-Proto https;

[TheresaQWQ]

Hi guys, as you are using "https" and reverse proxy, according to the offical doc, you should add X-Forwarded-Proto to your reverser proxy server.

proxy_set_header X-Forwarded-Proto https;

I have set all the headers mentioned in the documentation, and updated to latest version in dockerhub (1.9.0), I still got same error

[TheresaQWQ]

I tried requesting localhost:3002 in a Docker container using curl and it looks like it works fine, it seems to be a problem only when using docker port forwarding

[wangsijie]

Could you try a http domain?

[TheresaQWQ]

Could you try a http domain?

[wangsijie]

And it matches ADMIN_ENDPOINT?

[TheresaQWQ]

And it matches ADMIN_ENDPOINT?

yes, It matches ADMIN_ENDPOINT.

[wangsijie]

@TheresaQWQ Can you share your Logto's env config and nginx config? In the screenshot, it seems that Logto is configured to a https endpoint.

[TheresaQWQ]

@TheresaQWQ Can you share your Logto's env config and nginx config? In the screenshot, it seems that Logto is configured to a https endpoint.

I'm using Caddy, and my env config is above

env:

ADMIN_ENDPOINT=https://auth-admin.local.dev/
ADMIN_PORT=43002
DB_URL=postgres://logto:logto@127.0.0.1:45134/logto
ENDPOINT=https://auth.local.dev/
PORT=43001
TRUST_PROXY_HEADER=1

Caddyfile:

auth.local.dev {
  reverse_proxy http://127.0.0.1:43001 {
    trusted_proxies private_ranges
  }
}

auth-admin.local.dev {
  reverse_proxy http://127.0.0.1:43002 {
    trusted_proxies private_ranges
  }
}

[wangsijie]

@TheresaQWQ You can refer to this doc, and add X-Forwarded-Proto https://caddyserver.com/docs/caddyfile/directives/reverse_proxy#defaults

[Mohdsaleh939]

Any updates on this issue ? We are still blocked from installing Logto tool and got the same issue mentioned above.

[wangsijie]

@Mohdsaleh939 Is your Logto container behind a reverse proxy? Follow this doc to add X-Forwarded-Proto to your reverser proxy server.

[heng4fun]

I use the AWS alb ingress with https, got the same issue.

[wangsijie]

@heng4fun can you please share more details? especially the ingress configs

[JackyTYang]

I use the AWS alb ingress with https, got the same issue.

me too，and i don't know where and how can I set the header like x-forwarded-proto in alb console

[JackyTYang]

I want to make sure that logto can only support https, not http? If the x-forwarded-proto = "http", then it will redirect to unknown-session, right? So I need to make sure x-forwarded-proto= "https" is passed to the backend of logto then it will work.

[JackyTYang]

Solved，I added https 443 monitor to AWS ALB in which router rules are configed.

[wangsijie]

Logto employs a rigorous URL validation process that mandates the "https" protocol. This stringent requirement can lead to complications in environments based on reverse proxies. Configurations such as 'x-forwarded-proto' can mitigate these issues. However, we recognize that these solutions might not be straightforward for all users, particularly those new to Logto. In light of this, we are actively exploring options to allow the disabling of this strict URL check to facilitate a smoother initial setup experience. Please stay tuned for updates.

[yixinBC]

So any solusion to use logto with docker on development machine? I mean,HTTP connnection on localhost.

[wangsijie]

@yixinBC You can set ADMIN_ENDPOINT to http://localhost:3002

[yixinBC]

@yixinBC You can set ADMIN_ENDPOINT to http://localhost:3002

@wangsijie actually ADMIN_ENDPOINT on http://localhost:3002 works just fine.But when I tried to browse http://localhost:3001/ ,I'm just redirected to http://localhost:3001/unknown-session everytime.I'm sorry I havn't clarify.

[ciphermenial]

I am experiencing this issue too. I can access admin fine but anytime I go to logto.example.net I receive unknown-session.

I installed Logto using npm-init in an LXC container.

This is how traffic flows from Cloudflare, through HAProxy, to the web server.

graph TD
 EU[/External User\] -."http://logto.example.net".-> CF[Cloudflare]
 CF -.-> FE_HTTPS
 IU[/Internal User\] --"http://logto.example.net"--> FE_HTTP[HTTP Frontend]
 subgraph HAProxy
 FE_HTTPS -- "Internal User?" --> INT[Internal Backend]
 FE_HTTP --> FE_HTTPS[HTTPS Frontend]
 EXT -.-> FE_EXT[External Frontend]
 INT --> FE_INT[Internal Frontend]
 FE_HTTPS -. "External User?" .-> CS_DEC[(CrowdSec Decision)]
 subgraph CrowdSec
 CS_DEC ==Require CAPTCHA==> CS_CAPTCHA[CAPTCHA Page]
 CS_DEC ==Banned IP==> CS_BAN[Ban Page]
 CS_CAPTCHA ==CAPTCHA failed==> CS_DEC
 CS_DEC ==Captcha Remediated==> EXT[External Backend]
 end
 end
 CS_DEC -.Not In Decisions.-> EXT
 FE_EXT -.-> S[Web Service]
 FE_INT --> S

I have http-request set-header x-forwarded-proto https in the frontend configuration.

[JackyTYang]

Https is a must

[ciphermenial]

It seems this issue is universal. I have now tested using localhost and still get sent to unknown-session for the login. Admin page works fine.

[wangsijie]

@ciphermenial thanks for the detailed feedback, I'll revisit this issue.

[ciphermenial]

I should mention that I could log into the demo-app.

[wangsijie]

@ciphermenial Access to the default endpoint requires initiating the sign-in flow with OIDC tools, like our SDKs. Without this, you will be redirected to an "unknown session" page.

[wangsijie]

@fleuraly I think we can add some tips to the "unknown session" page?

[wangsijie]

I am closing this issue, the reason is that you can not access the OIDC sign in endpoint directly. Feel free to reopen if you guys have any other questions.

[PeterChen1997]

same problem. the doc should notice the user if they set the reverse proxy...

[clhey]

I tried requesting localhost:3002 in a Docker container using curl and it looks like it works fine, it seems to be a problem only when using docker port forwarding

I have the same setup, with all headers configured according to the documentation (https://docs.logto.io/docs/recipes/deployment/#reverse-proxy), and I've verified through actual testing that the headers are working properly. Can anyone help solve this issue?

I suspect that logto only allows requests from http://localhost:3002/ and the specified ADMIN_ENDPOINT for security reasons. My ADMIN_ENDPOINT is similar to https://user.example.com:8443/. Does logto only support port 443?

[adrianwnuk]

Unable to run with as nginx ingress on kubernetes. Same output like above "unknown-session"

apiVersion: networking.k8s.io/v1
kind: Ingress
metadata:
  name: ingress-logto
  namespace: logto
  annotations:
    nginx.ingress.kubernetes.io/ssl-redirect: "true"
    nginx.ingress.kubernetes.io/force-ssl-redirect: "true"
spec:
  ingressClassName: nginx
  tls:
  - hosts:
    - logto.logto.domain.com
    secretName: logto-domain-com-tls
  rules:
  - host: logto.domain.com
    http:
      paths:
      - pathType: Prefix
        path: "/"
        backend:
          service:
            name: logto-core
            port:
              number: 3001
      - pathType: Prefix
        path: "/admin"
        backend:
          service:
            name: logto-admin
            port:
              number: 3002

[WooodHead]

I encountered the same "unknown-session" issue. The solution was to open xxxx.logto.app and clear all cookies in the browser console, which resolved the problem.

[nqcuong72]

Add environment setting: 'HOST=0.0.0.0' will solve the problem

[jagyas]

I am using traefik proxy. After setting TRUST_PROXY_HEADER to true, at least I am able to access admin UI.