Redirect loop, can't access any resources, can only access pangolin itself.

[ellite]

I have discussed this issue on Discord before. It was happening on Firefox on my laptop. Now it's happening on my phone Brave iOS. On the laptop is easy to remove the cookies and move on, but not on the phone.
Seems to work fine on my laptop on both Brave and ARC, so it's hard to find the cause of the issue.

Symptoms:

try to open a resource on firefox:

service.domain.tld

results on a 302 to https://pangolin.domain.tld/auth/resource/2?redirect=https%3A%2F%2Fservice.domain.tld%2F
which results on a 307 back to https://service.domain.tld/?p_session_request=tyznl7i47g6ci6cazr27vhdq67fb52ui
which results on a 302 to https://service.domain.tld/
which results on a 302 to https://pangolin.domain.tld/auth/resource/2?redirect=https%3A%2F%2Fservice.domain.tld%2F 

and so on, and so on and so on.

Seems to loop 5 times until firefox responds with:

The page isn’t redirecting properly

Firefox has detected that the server is redirecting the request for this address in a way that will never complete.

Note that the p_session_request is different on each iteration of the loop.
But I always end up at https://service.domain.tld/?p_session_request=sometoken

On mobile the behaviour is a bit different

Every resource I try to open I see the login page. It shows the credentials pre filled, but it fails to login if I press submit. If I press the icon to show the password, the input fields are now empty. (nothing to do with this probably)

Then I login and end up on a "This site can't be reached page" with the p_session_request=sometown on the url
If I refresh, I see the login page again. and the same happens and it seems it keeps adding p_session_request to the url as you try and try again.

I ended up with this:
https://service.domain.tld/?p_session_request=wh7qovs5olsnuct65p63jnoke67avzak&p_session_request=fxu5i3knxjcq6lxegahi25v4gscazmnt&p_session_request=d2vvt462kuntd42payujlmtrxgyq4lyl&p_session_request=bxypfrfyjbm7m4jwsfjutolzk4kqhoum&p_session_request=2aa7zglzy6sebzxu3c6d2c4odccbgteg&p_session_request=s66mazgzqxx2w7uo4ruj5zwenauvaqig&p_session_request=e3667mo6ppir4ayngryz3nzac3w3gcat&p_session_request=juvopnvu4pmjnxelmdekhstvykdnevfy&p_session_request=vln2umvusx7jk7uur5cdpy3ej6mgfe5q&p_session_request=ibeqaa4b5gvtuszn7rdxjo44jabgqkui&p_session_request=c53xva7uugyommmgvopprn7cefwqcgxf

$ sudo docker compose logs -f does not show anything as I am making this requests.

Please let me know if I can add more information on the issue.
At the moment I can't access any resource via browser on my phone, since I can't delete individual site cookies.
On firefox desktop I can resolve it by deleting the cookies for my domain (I have to use an extension, since the offending cookie can not be deleted directly on the developer tools) , but it comes back eventually. Sometimes after a couple of minutes, sometime after a couple of hours.

[hhftechnology]

It is possible CrowdSec is blocking some of the authentication attempts or interfering with session validation.

[hhftechnology]

Try temporarily disabling CrowdSec to see if that resolves the issue:

Comment out the CrowdSec middleware in traefik_config.yml
Restart Traefik

[ellite]

Hi. Thanks.
I've never setup crowdsec. And there's nothing related to crowdsec on the config file.

[adrianipopescu]

having this without crowdsec as well, but also without auth as I am relying on the app's built-in one

LE: it was caused by cloudflare's proxying

anyone know why cloudflare's acting up?

LE: needed strict ssl

[BingoRox]

I'm having the same issues on v1.0.0 and v1.0.1. On Firefox Windows 11 24H2 and on iOS 18.3.2 Safari (and other browsers). On Chrome desktop it's hard to reproduce, but on iOS all the browsers I have use the Safari webkit so they all act the same. Unfortunately, the issue persists on Safari even after clearing the website data. On Firefox desktop if I clear the site data it will work for about a minute before breaking again. The resources that have the correct rules (e.g. allowed path /api/*) work on Firefox desktop, but the same resources redirect loop on Safari iOS.

I've reinstalled Pangolin 3 times on 2 different VPSs. I've tried with and without Crowdsec, I've tried with HHFs recent Traefik config/rules improvements (thanks for those btw), but the only thing that works is either disabling auth in Pangolin or sometimes setting an allowed IP rule in Pangolin (this is still inconsistent on Safari for some reason).

I've enabled debug logs and failed attempt logs in Pangolin, and when the redirect loop is happening I see the failed login attempts in the console with the resource value and my ip listed, but the debug logs just show Badger and the resource sending mismatched cookies back and forth and auth being denied. I can provide logs if helpful, sorry I'm currently on mobile but I wanted to join the discussion at least. Thanks everyone!

[ellite]

Happy to see I'm not alone.
As I have it working on Brave, I just use it on the desktop. But yeah, on the iphone nothing works on the browser.

But, 3 days ago I changed some values on the config.yml

from:

session_cookie_name: p_session_token
resource_access_token_param: p_token
resource_session_request_param: p_session_request

to:

session_cookie_name: p_session_token_s
resource_access_token_param: p_token_s
resource_session_request_param: p_session_request_s

I had to login everywhere again, but it is still working. Not sure if it will at some point return to not working, but it usually only works for a couple of minutes after I clear the website data, so, this looks promising.

[hhftechnology]

i did my tests it happens when using enhanced tracking protection. try adding exceptions for your domains.

server:
  # Other settings...
  session_cookie_name: p_session_token
  resource_access_token_param: p_token
  resource_session_request_param: p_session_request
  trust_proxy: true           # try this mark it as true if behind a adblocker. 
  cors:
    credentials: true         # I am not sure how safe this is but this prevents it when credentials are allowed in CORS

[BingoRox]

I tried with the following Safari settings on and off for the host, pangolin subdomain, and resource subdomains: Advanced Tracking and Fingerprint Protection, Prevent Cross-Site Tracking, Hide IP Address, content blockers toggled on/off.

I tried enabling trust_proxy in the config but it didn't work unfortunately. I didn't try cors credentials: true.

Thankfully ellite's solution worked for me as well, changing the server config has resolved all the redirect loops so far:

session_cookie_name: p_session_token_s
resource_access_token_param: p_token_s
resource_session_request_param: p_session_request_s

I don't know how this has fixed anything because the cookies in the console are listed as "p_session_token_s_s" now, but it's working at least!

[miloschwartz]

I think what could be happening here is the browser is rejecting the new cookie and not overwriting the old one. I'm assuming the browsers aren't playing nice with the way we're setting the cookies in the proxy middleware.

I am going to try to test and release a change which will append a random string to the end of the cookie name for new cookies when they need to refresh. My hope is that this will solve the issue.

[BingoRox]

Well looks like I spoke too soon of course Safari iOS is acting up again, although it does seem like Firefox desktop has been stable. I noticed that the base domain and pangolin subdomain are not having issues, it's only the other subdomains that are redirect looping and timing out. I'm using a wildcard cert for the subdomains, not sure if it's related but just wanted to mention in case it's helpful.

[miloschwartz]

@BingoRox

I don't know how this has fixed anything because the cookies in the console are listed as "p_session_token_s_s" now, but it's working at least!

Does this mean you see two cookies? You should have p_session_token_s_s and p_session_token_s, which is the new cookie and the old cookie?

I just added added the thing to append the timestamp to the cookie name, and will be releasing soon. It's hard for me to tell if it's fixing the issue because I can't figure out how to replicate the redirect loop, but my fingers are crossed!