bug: 404 Error Page Returned After Clicking Login Button Issue

[cuixiaorui]

Describe the bug

Recently, while using Logto, we have encountered numerous user reports indicating that clicking the login button results in a 404 page. This issue is not isolated; multiple users have experienced it. Interestingly, the problem resolves after clearing the browser cache.

Expected behavior

Users should be able to log in without encountering a 404 error page.

How to reproduce?

1. Navigate to the login page.
2. Click the login button.
3. Observe the 404 error page.

Context

• [ ] Logto Cloud
• [x] Self-hosted, Logto version =
  • [x] Container (Docker image) svhd/logto:latest
  • [ ] Raw Node.js

Screenshots

[wangsijie]

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

[cuixiaorui]

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.

[wangsijie]

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.

[cuixiaorui]

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?

[cuixiaorui]

GET /oidc/auth?client_id=6a6nklaj98airdef8xr6d&redirect_uri=http%3A%2F%2Flocalhost%3A3000%2Fcallback%2F&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%3Alogto%3Ascope%3Aorganizations&resource=http%3A%2F%2Flocalhost%3A3001%2F&resource=urn%3Alogto%3Aresource%3Aorganizations
2024-08-07 09:35:40   --> GET /oidc/auth?client_id=6a6nklaj98airdef8xr6d&redirect_uri=http%3A%2F%2Flocalhost%3A3000%2Fcallback%2F&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%3Alogto%3Ascope%3Aorganizations&resource=http%3A%2F%2Flocalhost%3A3001%2F&resource=urn%3Alogto%3Aresource%3Aorganizations 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:

[wangsijie]

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.

[wangsijie]

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

[cuixiaorui]

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.

[wangsijie]

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

[cuixiaorui]

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.