starred/pocket-id
1
0
Fork 0
mirror of https://github.com/pocket-id/pocket-id.git synced 2025-12-09 17:23:22 +03:00
Code Issues 121 Packages Projects Releases 16 Wiki Activity

🐛 Bug Report: Pocket-ID login loop after logout due to conflicting access_token cookies #376

New Issue
Closed
opened 2025-10-07 00:12:23 +03:00 by OVERLORD · 4 comments
OVERLORD commented 2025-10-07 00:12:23 +03:00
Owner
Copy Link

Originally created by @kmendell on GitHub.

Discussed in https://github.com/stonith404/pocket-id/discussions/170

Originally posted by agreenfield1 January 23, 2025

I've encountered an issue I was able to resolve it mostly, but am presenting it here as I'm not sure if it is a Pocket-ID or caddy-security bug, or just a configuration issue.

Summary: Pocket-ID enters a state where it is impossible to log in after logging out. The login process loops back to the sign-in page. This issue is resolved by manually deleting cookies (access_token specifically).

How to reproduce:

  • have caddy doing a reverse proxy for https://<service>.domain.com and https://pocketid.domain.com, and set up the caddy-security module according to the provided documentation for <service>
  • navigate to https://<service>.domain.com and authorize
  • navigate to https://pocketid.domain.com and authorize
  • log out from https://pocketid.domain.com
  • attempt to log back in, but am unable to do so (it just loops back to the signin page)
  • delete cookies, and the sign-in / authorization issue is resolved

Cause:

It looks like there are two access_token cookies under https://pocketid.domain.com:

  • Cookie1 was generated during the authorization to https://<service>.domain.com, and the domain scope is .domain.com
  • Cookie2 was generated during the authorization to https://pocketid.domain.com, and the domain scope is pocketid.domain.com

When logging out the value of Cookie2 is cleared but Cookie1 remains, a scenario that appears not handled well by Pocket-ID.

Not sure if this is an issue more related to Pocket ID or caddy-security. But it could certainly be handled better I think. I was able to resolve it by inserting the following line into my caddyfile for each <service>, but not sure if this is the best fix?:

cookie domain <service>.domain.com</div>
Originally created by @kmendell on GitHub. ### Discussed in https://github.com/stonith404/pocket-id/discussions/170 <div type='discussions-op-text'> <sup>Originally posted by **agreenfield1** January 23, 2025</sup> I've encountered an issue I was able to resolve it mostly, but am presenting it here as I'm not sure if it is a Pocket-ID or caddy-security bug, or just a configuration issue. **Summary:** Pocket-ID enters a state where it is impossible to log in after logging out. The login process loops back to the sign-in page. This issue is resolved by manually deleting cookies (access_token specifically). **How to reproduce:** - have caddy doing a reverse proxy for `https://<service>.domain.com` and `https://pocketid.domain.com`, and set up the caddy-security module according to the provided documentation for `<service>` - navigate to `https://<service>.domain.com` and authorize - navigate to `https://pocketid.domain.com` and authorize - log out from `https://pocketid.domain.com` - attempt to log back in, but am unable to do so (it just loops back to the signin page) - delete cookies, and the sign-in / authorization issue is resolved **Cause:** It looks like there are two `access_token` cookies under `https://pocketid.domain.com`: - Cookie1 was generated during the authorization to `https://<service>.domain.com`, and the domain scope is `.domain.com` - Cookie2 was generated during the authorization to `https://pocketid.domain.com`, and the domain scope is `pocketid.domain.com` When logging out the value of Cookie2 is cleared but Cookie1 remains, a scenario that appears not handled well by Pocket-ID. Not sure if this is an issue more related to Pocket ID or caddy-security. But it could certainly be handled better I think. I was able to resolve it by inserting the following line into my caddyfile for each `<service>`, but not sure if this is the best fix?: cookie domain <service>.domain.com</div>
OVERLORD commented 2025-10-07 00:12:26 +03:00
Author
Owner
Copy Link

@stonith404 commented on GitHub:

Great, I'll create a release ASAP. @agreenfield1 Thanks for giving such a detailed bug description, this really helped to debug the issue.

@stonith404 commented on GitHub: Great, I'll create a release ASAP. @agreenfield1 Thanks for giving such a detailed bug description, this really helped to debug the issue.
OVERLORD commented 2025-10-07 00:12:26 +03:00
Author
Owner
Copy Link

@kmendell commented on GitHub:

@stonith404 Im not sure if this is a bug in Pocket ID or not, I moved this to and issue to investigate further.

@kmendell commented on GitHub: @stonith404 Im not sure if this is a bug in Pocket ID or not, I moved this to and issue to investigate further.
OVERLORD commented 2025-10-07 00:12:27 +03:00
Author
Owner
Copy Link

@stonith404 commented on GitHub:

Fixed in 0.27.1.

@stonith404 commented on GitHub: Fixed in `0.27.1`.
OVERLORD commented 2025-10-07 00:12:29 +03:00
Author
Owner
Copy Link

@agreenfield1 commented on GitHub:

Tried the development image per the Q&A thread and it appears fixed!

@agreenfield1 commented on GitHub: Tried the development image per the Q&A thread and it appears fixed!
Sign in to join this conversation.
No Branch/Tag Specified
Branches Tags
Labels
Clear labels
breaking
bug
documentation
feature
needs more upvotes
open to pull requests
pull-request
Mirrored from GitHub Pull Request
No Label
Milestone
No items
No Milestone
Projects
Clear projects
No project
Assignees
Clear assignees
OVERLORD
No Assignees
1 Participants
Notifications
Due Date
No due date set.
Dependencies

No dependencies set.

Reference: starred/pocket-id#376
Delete Branch "%!s()"

Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?