If you hit a page which requires authentication and you are not authenticated, Beaker redirects your browser to /login?forward_url=/jobs/mine or similar. The /login endpoint is protected by Apache authentication so the idea is that the user will be authenticated, and once the request actually hits Beaker we can read REMOTE_USER and then redirect their browser back to the real page they were trying to hit. However if you just click the Login link at the top of the page, you go to /login without any forward_url parameter. In that case, after successful authentication, Beaker redirects back to the URL in the Referer request header (if one is present). For authentication flows like LDAP over HTTP basic, or Kerberos, which don't have any redirect dance, this logic is fine -- the Referer header will either not be set at all, or more likely will be set to the page in Beaker where the user clicked the Login link. It even works fine for OpenID which *does* a redirect dance using 302s, because the Referer is kept the same through all the redirects. However for SAML, the identity provider may do a meta-refresh redirect (Ipsilon does this) which means by the time the browser lands back on Beaker's /login page having successfully authenticated, the Referer header will be something *outside* of Beaker (the already-consumed Ipsilon transaction page in this case). So the /login handler should redirect to Referer *only if* that URL is actually a page inside Beaker -- otherwise it should just redirect back to /.
On second thought, maybe we should stop paying any attention Referer and just adjust master.kid so that the Login link always has a proper ?forward_url= parameter pointing back to the page where we rendered the link on. That seems like it would be less error prone. As a fallback we can still just redirect to / if there is no forward_url parameter at all.
http://gerrit.beaker-project.org/5287
Beaker 23.3 has been released.