What kind of application/SDK? And could you provide steps to reproduce this?

I am currently using @logto/vue version "^2.2.5" in my client-side application. I have received user feedback indicating that after logging in, they are unexpectedly redirected to a 404 page. Subsequently, attempting to log in again does not resolve the issue.

The 404 error they encounter is as follows:

Could you please look into this issue and provide guidance on how to resolve it?

Thank you.

Could you please provide a minimal project that can reproduce this error?

One possibility is that the users open the sign in page directly, without the init of SDK sign in process.

I apologize for the delay in reproducing the issue.

It's quite intriguing that the problem only occurs when using an incognito browser window.

I'm currently at a loss on how to troubleshoot this issue, or what information I should provide to assist in diagnosing it.

Could you guide me on how to proceed with the investigation?

GET /oidc/auth?client_id=6a6nklaj98airdef8xr6d&redirect_uri=http://localhost:3000/callback/&code_challenge=WiUVU32zWFQ1JMA-8dj7BChx2t2c1vb5drgyY4YOsaM&code_challenge_method=S256&state=HfaYb36TI2XXDSaWdUDGj4P_MW5VQ920Rp48Wlcmv1SdMMT_FHsbLwXLvYe-4Oo_OK-yz1M6Y6DMRR9lJ39-zQ&response_type=code&prompt=consent&scope=openid offline_access profile email phone custom_data identities urn:logto:scope:organizations&resource=http://localhost:3001/&resource=urn:logto:resource:organizations
2024-08-07 09:35:40   --> GET /oidc/auth?client_id=6a6nklaj98airdef8xr6d&redirect_uri=http://localhost:3000/callback/&code_challenge=WiUVU32zWFQ1JMA-8dj7BChx2t2c1vb5drgyY4YOsaM&code_challenge_method=S256&state=HfaYb36TI2XXDSaWdUDGj4P_MW5VQ920Rp48Wlcmv1SdMMT_FHsbLwXLvYe-4Oo_OK-yz1M6Y6DMRR9lJ39-zQ&response_type=code&prompt=consent&scope=openid offline_access profile email phone custom_data identities urn:logto:scope:organizations&resource=http://localhost:3001/&resource=urn:logto:resource:organizations 303 96ms 47b
2024-08-07 09:35:40   <-- GET /consent
2024-08-07 09:35:40   --> GET /consent 302 5ms 105b
2024-08-07 09:35:40   <-- GET /unknown-session
2024-08-07 09:35:40   --> GET /unknown-session 200 2ms 354b
2024-08-07 09:35:40   <-- GET /index.2664a438.css
2024-08-07 09:35:40   --> GET /index.2664a438.css 200 14ms 6.43kb
2024-08-07 09:35:40   <-- GET /index.3bd4cf2d.js
2024-08-07 09:35:40   <-- GET /index.c67aae80.js
2024-08-07 09:35:40   --> GET /index.3bd4cf2d.js 200 6ms 666b
2024-08-07 09:35:40   --> GET /index.c67aae80.js 200 6ms 264.27kb
2024-08-07 09:35:41   <-- GET /api/.well-known/sign-in-exp
2024-08-07 09:35:41   <-- GET /api/.well-known/phrases
2024-08-07 09:35:41   <-- GET /index.2664a438.css.map
2024-08-07 09:35:41   <-- GET /index.3bd4cf2d.js.map
2024-08-07 09:35:41   --> GET /index.2664a438.css.map 200 5ms 13.14kb
2024-08-07 09:35:41   --> GET /index.3bd4cf2d.js.map 200 33ms 1.62kb
2024-08-07 09:35:41   --> GET /api/.well-known/sign-in-exp 200 70ms 4.02kb
2024-08-07 09:35:41   --> GET /api/.well-known/phrases 200 65ms 2.94kb
2024-08-07 09:35:41   <-- GET /index.c67aae80.js.map
2024-08-07 09:35:41   --> GET /index.c67aae80.js.map 200 9ms 1.09mb

It also occurred on my local environment.

The general process is:

I clicked the logout button.

A permission error occurred, leading to a 404.

After refreshing the page and clicking login again,

it resulted in a 404, redirecting to the /unknown-session path.

The above is from the Logto service logs.

Interestingly, everything works fine after clearing the cache.

The version I am using is:

One possibility is cookie lost. When calling "sign-in" via SDK, the user is redirected to url "/oidc/auth?client_id=xxxx" and init a session with key saved in cookie. If the browser is rejects the cookie, then the session can not be found.

In the "unknown session" page, you can check if the cookie exists:

Thank you, I'll observe the situation.

I'm curious to know under what circumstances the cookie might become invalid. Also, I'd like to understand if there's an automatic cleanup mechanism in place, such as deleting old cookies or redirecting back to the login page. The current 404 error is causing confusion for users.

I would appreciate your insights on this matter.

Yes, good suggestion, the "unknown session" can be confusing, we'll revisit this design.

I truly appreciate your assistance! This issue has been a persistent concern of mine, and I frequently find users approaching me, inquiring about the 404 error. I then have to inform them that clearing their cache is necessary.

Thank you once again for your support.

1

We've had one user reporting of similar issue (in Chrome).
Edge worked fine, so we cleared cache in Chrome - Which worked.

User tries to sign in but gets redirected to https : //login....domain....app/unknown-session
Only thing I find in Audit logs is; "Interaction started"

this link may help you
nginx config add
proxy_set_header X-Forwarded-Proto https;

this link may help you nginx config add proxy_set_header X-Forwarded-Proto https;

I don't think that's it

because I have been set proxy_set_header X-Forwarded-Proto

This configuration is equivalent to proxy_set_header X-Forwarded-Proto: https

My users are still experiencing this problem after I upgraded to version 1.20

this link may help you nginx config add proxy_set_header X-Forwarded-Proto https;

I don't think that's it

because I have been set proxy_set_header X-Forwarded-Proto

This configuration is equivalent to `proxy_set_header X-Forwarded-Proto: https`

群晖吗，我最早也是设置的$scheme ，换成https就好了，你可以试一试。看你截图有汉字，直接中文回复了

this link may help you nginx config add proxy_set_header X-Forwarded-Proto https;

I don't think that's it
because I have been set proxy_set_header X-Forwarded-Proto

This configuration is equivalent to proxy_set_header X-Forwarded-Proto: https

群晖吗，我最早也是设置的$scheme ，换成https就好了，你可以试一试。看你截图有汉字，直接中文回复了

感谢 我改了试一试