Uitsmijter 0.10.5: Solid Logout, Sharper UX

Version 0.10.5 tightens the logout flow across multi-domain setups, hardens cookie handling for WebKit, and polishes the login experience with small but meaningful improvements.

Uitsmijter 0.10.5: Solid Logout, Sharper UX  

Not every release rewrites the rules. Sometimes the most important work is making sure the existing rules are followed consistently — everywhere, every time. Uitsmijter 0.10.5 is that kind of release. It focuses on correctness in the logout flow, reliable cookie handling across browser engines, and a small but immediately noticeable improvement to the login page.

The Problem with Multi-Domain Logout  

Modern deployments often span more than one domain. A typical Uitsmijter setup running in Traefik forward-authentication mode places the interceptor middleware on one hostname (say, .ops.example.com) while the OAuth login page lives on another (such as login.ops.example.com). Both domains set their own SSO cookies independently, which is exactly how the system is designed to work.

But until version 0.10.5, logout only invalidated the cookie it knew about directly — the one on the domain where the request arrived. The cookie on the other domain survived. From a browser’s perspective, the user was still logged in. Refreshing a protected resource would silently re-authenticate via the surviving cookie, making it appear that logout had no effect at all.

This release closes that gap. The logout handler now inspects the full domain-to-cookie mapping configured via COOKIE_DOMAINS and issues invalidation Set-Cookie headers for every domain associated with the session — not just the one that received the logout request. The result is a complete, trustworthy logout across all relevant browser cookie jars.

Cookies That Actually Reach the Browser  

Fixing multi-domain logout exposed a second, subtler problem. Vapor’s built-in SessionsMiddleware manages cookies through an internal dictionary keyed by cookie name. When two Set-Cookie headers share the same name but target different domains, the dictionary collapses them into one entry — and only the last one survives into the response.

To work around this framework limitation, 0.10.5 introduces ExtraCookiesMiddleware. This middleware runs after SessionsMiddleware has finished its processing and appends the additional invalidation cookies directly to the response headers. The framework’s dictionary never sees them; they go straight to the browser. It is the kind of unglamorous infrastructure work that most users will never notice, which is exactly the point — it should just work, silently and reliably.

WebKit and the SameSite Puzzle  

Safari and other WebKit-based browsers handle cookie forwarding differently from Chromium and Firefox. When a page triggers a meta-refresh navigation — which the Uitsmijter logout flow uses to chain through the finalization step — WebKit does not always forward SameSite=Strict cookies along with the redirected request. In practice, this meant that the /logout/finalize endpoint sometimes received no valid JWT cookie at all from Safari users, causing the redirect to fail rather than completing the logout gracefully.

The fix is straightforward but important: the finalization endpoint no longer requires a valid JWT cookie to determine where to send the user next. Instead, it resolves the redirect target from the request context — specifically from the tenant matched to the request hostname. If the cookie is present, it is used; if it is absent (as WebKit may cause), the system falls back to the tenant configuration. Logout completes correctly on all browsers.

Wildcard Cookie Domain Sanitization  

Uitsmijter’s cookieDomain configuration fields accept wildcard values like *.example.com for flexible subdomain matching. The Set-Cookie HTTP specification, however, does not understand wildcard notation — a cookie domain must begin with a dot (.example.com) to apply to subdomains. Browsers that encounter *.example.com as a cookie domain silently reject the cookie.

Version 0.10.5 sanitizes cookieDomain values before they reach the Set-Cookie header. Leading wildcard prefixes are stripped and replaced with the correct dot notation automatically. Existing configurations that worked around this limitation by writing .example.com directly continue to work unchanged.

Autofocus on the Login Page  

The smallest change in this release is perhaps the most immediately visible. The username field on the Uitsmijter login page now carries the autofocus HTML attribute. When the page loads, the cursor lands directly in the username field. No click, no tap, no extra interaction required — users can begin typing their credentials the moment the page appears.

It is a one-attribute change, but it reflects a broader principle: authentication should be as frictionless as possible. The fewer steps between a user and their session, the better.

Upgrading  

Version 0.10.5 is a drop-in upgrade. No configuration changes are required, though users running multi-domain setups are encouraged to review their COOKIE_DOMAINS / cookieDomain Helm values to ensure all relevant domains are enumerated — the new logout logic relies on that mapping to send invalidation headers everywhere they are needed.

Full release notes are available in the CHANGELOG. As always, thank you for being part of the Uitsmijter community.