🐛 Bug Report: Redirect URL can be changed while logging in #268

New Issue

Closed

opened 2025-10-08 00:00:15 +03:00 by OVERLORD · 4 comments

OVERLORD commented 2025-10-08 00:00:15 +03:00

Owner

Copy Link

Originally created by @alex3305 on GitHub.

Reproduction steps

I have setup SSO on my primary domain and subdomains. Authentication and authorization is done through Caddy Security where Pocket ID acts like an IdP. This setup works reasonably well. But sometimes when I want to login on one of my subdomains, let's say adguard.example.com, I actually get redirected to the sabNZBd API: sabnzbd.example.com/api?apikey=XVrONFGjv90jhatgUipC3FE7DGZZMwh6&mode=queue&output-json.

I suspect this happens because I have the SABconnect++ browser extension installed which triggers an authentication event while I'm logging in.

While setting up - and migrating from Dex - I read somewhere that a redirect parameter or cookie is used. I'm not 100% sure if it was somewhere in Pocket ID's docs or Caddy Security. But I suspect that this value is overwritten because of the login timing of Pocket ID. Why Pocket ID? Because when I used Dex login was practically instantaneous. Or because the browser plugin just cannot authenticate without user interaction.

Expected behavior

When I authenticate with Pocket ID that I be redirected to the expected redirect URL that I initiated.

Actual Behavior

That I get redirected to an URL that I did not expect because of a browser plugin.

Version and Environment

• Caddy v2.9.1 with the latest Caddy Security
• Pocket ID v0.45.0
• Brave browser 1.77.95 Chromium: 135.0.7049.52 (Officiële build) (64-bits)
• SABconnect++ (but also happened with Linkding when I added that service behind Caddy Auth)

Log Output

No response

Originally created by @alex3305 on GitHub. ### Reproduction steps I have setup SSO on my primary domain and subdomains. Authentication and authorization is done through Caddy Security where Pocket ID acts like an IdP. This setup works reasonably well. But sometimes when I want to login on one of my subdomains, let's say `adguard.example.com`, I actually get redirected to the sabNZBd API: `sabnzbd.example.com/api?apikey=XVrONFGjv90jhatgUipC3FE7DGZZMwh6&mode=queue&output-json`. I suspect this happens because I have the [SABconnect++](https://chromewebstore.google.com/detail/sabconnect++/okphadhbbjadcifjplhifajfacbkkbod) browser extension installed which triggers an authentication event while I'm logging in. While setting up - and migrating from [Dex](https://dexidp.io/) - I read somewhere that a redirect parameter or cookie is used. I'm not 100% sure if it was somewhere in Pocket ID's docs or Caddy Security. But I suspect that this value is overwritten because of the login timing of Pocket ID. Why Pocket ID? Because when I used Dex login was practically instantaneous. Or because the browser plugin just cannot authenticate without user interaction. ### Expected behavior When I authenticate with Pocket ID that I be redirected to the expected redirect URL that I initiated. ### Actual Behavior That I get redirected to an URL that I did not expect because of a browser plugin. ### Version and Environment - Caddy v2.9.1 with the latest Caddy Security - Pocket ID v0.45.0 - Brave browser 1.77.95 Chromium: 135.0.7049.52 (Officiële build) (64-bits) - SABconnect++ (but also happened with Linkding when I added that service behind Caddy Auth) ### Log Output _No response_

OVERLORD added the bug label 2025-10-08 00:00:15 +03:00

OVERLORD closed this issue 2025-10-08 00:00:17 +03:00

OVERLORD commented 2025-10-08 00:00:19 +03:00

Author

Owner

Copy Link

@stonith404 commented on GitHub:

Yes, showing the UI might unnecessary, if we would directly redirect the user we could save some time.

In my opinion it's definitely an issue of the extension though that it manipulates the redirect URL, regardless of whether Pocket ID redirects slowly. I don't know the extension but is there a reason why it would manipulate the redirect URL?

@stonith404 commented on GitHub: Yes, showing the UI might unnecessary, if we would directly redirect the user we could save some time. In my opinion it's definitely an issue of the extension though that it manipulates the redirect URL, regardless of whether Pocket ID redirects slowly. I don't know the extension but is there a reason why it would manipulate the redirect URL?

OVERLORD commented 2025-10-08 00:00:19 +03:00

Author

Owner

Copy Link

@alex3305 commented on GitHub:

In my opinion it's definitely an issue of the extension though that it manipulates the redirect URL, regardless of whether Pocket ID redirects slowly. I don't know the extension but is there a reason why it would manipulate the redirect URL?

Maybe it's good if I re-iterate my use-case or at least what happens on my end to clear up any possible confusion. Perhaps yesterday evening wasn't the right time for me to create this issue 😉.

In a normal scenario I would expect this to be the authentication flow:

1. I go to service.example.com in my browser
2. Caddy Security intercepts this request and redirects me to auth.example.com
3. Caddy Security on auth.example.com notices the lack of authentication and redirects me to the identity provider (Pocket ID) on id.example.com
4. Pocket ID loads and let's me login, redirecting me to the original URL that is passed with the redirect_url parameter on auth.example.com
5. Caddy Security validates the authentication request and starts authorization
6. Caddy Security authorization succeeds and redirects me to the original URL of service.example.com

Note

This is identical for re-authentications with a refresh token within a session, but after the browser has been closed. The main difference is that Pocket ID automatically authenticates me on 4.

However something funny happens within Caddy Security, more specifically in the library used by Caddy Security: go-authcrunch. Which is by the same author. Because in addition to the redirect URL parameter, Caddy Security actually sets and prefers a cookie with the name AUTHP_REDIRECT_URL.

So what actually happens is:

1. I go to service.example.com in my browser
2. Caddy Security intercepts this request and redirects me to auth.example.com
3. Caddy Security on auth.example.com notices the lack of authentication and redirects me to the identity provider (Pocket ID) on id.example.com
4. Pocket ID loads and let's me login, redirecting me to the original URL that is passed with the redirect_url parameter on auth.example.com
5. Caddy Security validates the authentication request and starts authorization
6. Caddy Security authorization succeeds and redirects me to the redirect URL that is has found in the AUTHP_REDIRECT_URL cookie

Now it gets even more complicated because in my browser I also have one or more extensions installed that interact or try to interact with services behind Caddy Security and in extension Pocket ID. So what that happens is that somewhere between steps 3 and 6 the contents of the AUTHP_REDIRECT_URL cookie are overwritten by the browser extension. Perhaps because the browser extension tries to connect every 15 seconds.

Having this redirect cookie can be IMHO at minimal unexpected. Especially because it isn't documented very well. Google had only several results, where one of those was a link to the VW Cookie Policy (pdf) 😛 . So I guess they also use Caddy Security which is comforting. Personally I think that this feature should be disabled by default because of the potential unexpected behavior.

Back to Pocket ID. Like I said in my previous comment, having a ~2 second page load doesn't really help in this case. Especially when doing a session refresh or re-authentication when re-opening a browser. But I hardly consider that a bug, more of a design choice. And with the young age of this great piece of kit in the back of my mind it's not a major bother, just a slight inconvenience.

One thing kept bothering me though, and maybe that is a bug. I couldn't fully grasp why a browser extension - because multiple extensions behave the same - just couldn't authenticate by itself. It has my session data, so I shouldn't make a difference whether I manually surf or let a background proces do it's thing. At which point I stumbled multiple CORS errors. So I've added this snippet to my Caddy configuration:

(cors) {
        @cors_preflight{args[0]} method OPTIONS
        @cors{args[0]} header Origin {args[0]}
        handle @cors_preflight{args[0]} {
                header {
                        Access-Control-Allow-Origin {args[0]}
                        Access-Control-Allow-Methods "GET, POST, PUT, PATCH, DELETE, OPTIONS"
                        Access-Control-Allow-Headers *
                        Access-Control-Max-Age 3600
                        defer
                }
                respond 204
        }
        handle @cors{args[0]} {
                header {
                        Access-Control-Allow-Origin {args[0]}
                        Access-Control-Expose-Headers *
                        defer
                }
        }
}

which allows an 'insecure' OPTIONS preflight request and sets up CORS headers restricted to the given URL. Using this snippet is pretty trivial:

*.example.com {
        @pocket-id {
                host id.example.com
        }

        handle @pocket-id {
                @admin {
                        not remote_ip 192.168.0.0/16
                        path /settings/admin*
                }
                handle @admin {
                        redir https://example.com
                }
                import cors https://id.example.com
                reverse_proxy pocket-id:80
        }
        import common https://github.com/alex3305
}

Tip

I also setup a basic IP whitelist for the admin pages where I redirect when users don't have access. And the common directive at the bottom is a global directive that does a redir {args[0]} (among other things) when no matchers were found.

After setting this up and clearing the browser cache, authentication seems to work perfectly from a browser extension. This also means that I don't encounter this bug anymore 😄 . So I guess that's solved.

Maybe adding CORS settings is something that can be added to the documentation? I maybe the first that encounters this, but perhaps not the last.

Yes, showing the UI might unnecessary, if we would directly redirect the user we could save some time.

Maybe only hide the UI on session refreshes? Or maybe as an option? Because I already knew that I am authenticated. Not only to save time, but most other IdP's that I have worked with skip the UI. IMHO it's a bit redundant. On the other hand, it's not that it's a major bug or deal breaker 🤷 .

The final thing that I want to add is that I noticed that the JS being loaded in chunks take quite a long time to reach my machine. For instance:

Although downloaded in parallel because of HTTP/3 it seems that this could be improved. Maybe by bundling? Because it seems that Cache-Control is set correctly: public,max-age=31536000,immutable. But again, not a major issue at all.

Thanks for taking the time to respond and this great project. Keep it up 👍

@alex3305 commented on GitHub: > In my opinion it's definitely an issue of the extension though that it manipulates the redirect URL, regardless of whether Pocket ID redirects slowly. I don't know the extension but is there a reason why it would manipulate the redirect URL? Maybe it's good if I re-iterate my use-case or at least what happens on my end to clear up any possible confusion. Perhaps yesterday evening wasn't the right time for me to create this issue 😉. In a normal scenario I would expect this to be the authentication flow: 1. I go to `service.example.com` in my browser 2. Caddy Security intercepts this request and redirects me to `auth.example.com` 3. Caddy Security on `auth.example.com` notices the lack of authentication and redirects me to the identity provider (Pocket ID) on `id.example.com` 4. Pocket ID loads and let's me login, redirecting me to the original URL that is passed with the `redirect_url` parameter on `auth.example.com` 5. Caddy Security validates the authentication request and starts authorization 6. Caddy Security authorization succeeds and redirects me to the original URL of `service.example.com` > [!NOTE] > This is identical for re-authentications with a refresh token within a session, but after the browser has been closed. The main difference is that Pocket ID automatically authenticates me on 4. However something funny happens within Caddy Security, more specifically in the library used by Caddy Security: [go-authcrunch](https://github.com/greenpau/go-authcrunch). Which is by the same author. Because in addition to the redirect URL parameter, Caddy Security actually sets and prefers a [cookie with the name `AUTHP_REDIRECT_URL`](https://github.com/greenpau/go-authcrunch/blob/7241955902c82cb02a9a57df8962103d0a198b98/pkg/authn/cookie/cookie.go#L79). So what actually happens is: 1. I go to `service.example.com` in my browser 2. Caddy Security intercepts this request and redirects me to `auth.example.com` 3. Caddy Security on `auth.example.com` notices the lack of authentication and redirects me to the identity provider (Pocket ID) on `id.example.com` 4. Pocket ID loads and let's me login, redirecting me to the original URL that is passed with the `redirect_url` parameter on `auth.example.com` 5. Caddy Security validates the authentication request and starts authorization 6. Caddy Security authorization succeeds and redirects me to the redirect URL that is has found in the `AUTHP_REDIRECT_URL` cookie Now it gets even more complicated because in my browser I also have one or more extensions installed that interact or try to interact with services behind Caddy Security and in extension Pocket ID. So what that happens is that somewhere between steps 3 and 6 the contents of the `AUTHP_REDIRECT_URL` cookie are overwritten by the browser extension. Perhaps because the browser extension tries to connect every 15 seconds. Having this redirect cookie can be IMHO at minimal unexpected. Especially because it isn't documented very well. Google had only several results, where one of those was a link to the [VW Cookie Policy](https://consent.vwgroup.io/consent/v1/texts/pre-delivery-enrolment/gb/en-GB/cookie-policy/latest/pdf) (pdf) 😛 . So I guess they also use Caddy Security which is comforting. Personally I think that this feature should be disabled by default because of the potential unexpected behavior. Back to Pocket ID. Like I said in my previous comment, having a ~2 second page load doesn't really help in this case. Especially when doing a session refresh or re-authentication when re-opening a browser. But I hardly consider that a bug, more of a design choice. And with the young age of this great piece of kit in the back of my mind it's not a major bother, just a slight inconvenience. One thing kept bothering me though, and maybe that is a bug. I couldn't fully grasp why a browser extension - because multiple extensions behave the same - just couldn't authenticate by itself. It has my session data, so I shouldn't make a difference whether I manually surf or let a background proces do it's thing. At which point I stumbled multiple CORS errors. So I've added this snippet to my Caddy configuration: ``` (cors) { @cors_preflight{args[0]} method OPTIONS @cors{args[0]} header Origin {args[0]} handle @cors_preflight{args[0]} { header { Access-Control-Allow-Origin {args[0]} Access-Control-Allow-Methods "GET, POST, PUT, PATCH, DELETE, OPTIONS" Access-Control-Allow-Headers * Access-Control-Max-Age 3600 defer } respond 204 } handle @cors{args[0]} { header { Access-Control-Allow-Origin {args[0]} Access-Control-Expose-Headers * defer } } } ``` which allows an 'insecure' OPTIONS preflight request and sets up CORS headers restricted to the given URL. Using this snippet is pretty trivial: ``` *.example.com { @pocket-id { host id.example.com } handle @pocket-id { @admin { not remote_ip 192.168.0.0/16 path /settings/admin* } handle @admin { redir https://example.com } import cors https://id.example.com reverse_proxy pocket-id:80 } import common https://github.com/alex3305 } ``` > [!TIP] > I also setup a basic IP whitelist for the admin pages where I redirect when users don't have access. And the common directive at the bottom is a global directive that does a `redir {args[0]}` (among other things) when no matchers were found. After setting this up and clearing the browser cache, authentication seems to work perfectly from a browser extension. This also means that I don't encounter this bug anymore 😄 . So I guess that's solved. Maybe adding CORS settings is something that can be added to the documentation? I maybe the first that encounters this, but perhaps not the last. > Yes, showing the UI might unnecessary, if we would directly redirect the user we could save some time. Maybe only hide the UI on session refreshes? Or maybe as an option? Because I already knew that I am authenticated. Not only to save time, but most other IdP's that I have worked with skip the UI. IMHO it's a bit redundant. On the other hand, it's not that it's a major bug or deal breaker 🤷 . The final thing that I want to add is that I noticed that the JS being loaded in chunks take quite a long time to reach my machine. For instance:  Although downloaded in parallel because of HTTP/3 it seems that this could be improved. Maybe by bundling? Because it seems that `Cache-Control` is set correctly: `public,max-age=31536000,immutable`. But again, not a major issue at all. Thanks for taking the time to respond and this great project. Keep it up 👍

OVERLORD commented 2025-10-08 00:00:20 +03:00

Author

Owner

Copy Link

@stonith404 commented on GitHub:

Isn't that more of an issue of "SABconnect++"? I mean, if this extension changes the redirection URL, we can't really do much about it.

Do you have any idea why the extension would change the redirection URL?

@stonith404 commented on GitHub: Isn't that more of an issue of "SABconnect++"? I mean, if this extension changes the redirection URL, we can't really do much about it. Do you have any idea why the extension would change the redirection URL?

OVERLORD commented 2025-10-08 00:00:20 +03:00

Author

Owner

Copy Link

@alex3305 commented on GitHub:

Isn't that more of an issue of "SABconnect++"? I mean, if this extension changes the redirection URL, we can't really do much about it.

Do you have any idea why the extension would change the redirection URL?

Sure. I get where you are coming from. But I kindly disagree. On my system Pocket ID and Caddy auth take about 2 seconds from initial request to the redirect. And that's over a locally HTTP/3 connection. Because of this time the redirection URL can be changed due to a race condition.

I looked it up and within Caddy Security the redirect URL is set with the AUTHP_REDIRECT_URL cookie, which is use to redirect after authentication, regardless of what the redirect_url parameter is.

The other thing is that the extension apparently cannot authenticate on it's own (without user interaction). Which should be the case with #325 if I'm not mistaking. I'm not 100% sure what causes this, but I will look into this.

I understand that there are a lot of moving parts involved and it isn't that clear cut that this is a Pocket ID related bug per se. But on the other hand, the IMHO pretty big authentication delay that happens doesn't improve this situation.

@alex3305 commented on GitHub: > Isn't that more of an issue of "SABconnect++"? I mean, if this extension changes the redirection URL, we can't really do much about it. > > Do you have any idea why the extension would change the redirection URL? Sure. I get where you are coming from. But I kindly disagree. On my system Pocket ID and Caddy auth take about 2 seconds from initial request to the redirect. And that's over a locally HTTP/3 connection. Because of this time the redirection URL can be changed due to a race condition. I looked it up and within Caddy Security the redirect URL is set with the `AUTHP_REDIRECT_URL` cookie, which is use to redirect after authentication, regardless of what the `redirect_url` parameter is. The other thing is that the extension apparently cannot authenticate on it's own (without user interaction). Which should be the case with #325 if I'm not mistaking. I'm not 100% sure what causes this, but I will look into this. I understand that there are a lot of moving parts involved and it isn't that clear cut that this is a Pocket ID related bug per se. But on the other hand, the IMHO pretty big authentication delay that happens doesn't improve this situation.

OVERLORD referenced this issue 2025-10-08 00:03:38 +03:00

🐛 Bug Report: Pocket ID uses STARTTLS used by default if SMPT port is not 465 #326

OVERLORD referenced this issue 2025-10-08 00:19:24 +03:00

[PR #268] [MERGED] fix: add option to manually select SMTP TLS method #904

Sign in to join this conversation.

No Branch/Tag Specified

Branches Tags

main

oidc-scopes

breaking/v2

i18n_crowdin

v2/use-item-component

default-env-db-keys

slog-gorm

v1.16.0

v1.15.0

v1.14.2

v1.14.1

v1.14.0

v1.13.1

v1.13.0

v1.12.0

v1.11.2

v1.11.1

v1.11.0

v1.10.0

v1.9.1

v1.9.0

v1.8.1

v1.8.0

v1.7.0

v1.6.4

v1.6.3

v1.6.2

v1.6.1

v1.6.0

v1.5.0

v1.4.1

v1.4.0

v1.3.1

v1.3.0

v1.2.0

v1.1.0

v1.0.0

v0.53.0

v0.52.0

v0.51.1

v0.51.0

v0.50.0

v0.49.0

v0.48.0

v0.47.0

v0.46.0

v0.45.0

v0.44.0

v0.43.1

v0.43.0

v0.42.1

v0.42.0

v0.41.0

v0.40.1

v0.40.0

v0.39.0

v0.38.0

v0.37.0

v0.36.0

v0.35.6

v0.35.5

v0.35.4

v0.35.3

v0.35.2

v0.35.1

v0.35.0

v0.34.0

v0.33.0

v0.32.0

v0.31.0

v0.30.0

v0.29.0

v0.28.1

v0.28.0

v0.27.2

v0.27.1

v0.27.0

v0.26.0

v0.25.1

v0.25.0

v0.24.1

v0.24.0

v0.23.0

v0.22.0

v0.21.0

v0.20.1

v0.20.0

v0.19.0

v0.18.0

v0.17.0

v0.16.0

v0.15.0

v0.14.0

v0.13.1

v0.13.0

v0.12.0

v0.11.0

v0.10.0

v0.9.0

v0.8.1

v0.8.0

v0.7.1

v0.7.0

v0.6.0

v0.5.3

v0.5.2

v0.5.1

v0.5.0

v0.4.1

v0.4.0

v0.3.1

v0.3.0

v0.2.1

v0.2.0

v0.1.3

v0.1.2

v0.1.1

v0.1.0

Labels

Clear labels

breaking

bug

documentation

feature

needs more upvotes

open to pull requests

pull-request

Mirrored from GitHub Pull Request

No Label bug

Milestone

No items

No Milestone

Projects

Clear projects

No project

Assignees

Clear assignees

OVERLORD

No Assignees

1 Participants

Notifications

Subscribe

Due Date

No due date set.

Dependencies

No dependencies set.

Reference: starred/pocket-id-pocket-id-1#268