v4 RestClient breaks token persistence on reload against HttpOnly-cookie Girder backends

[arjunrajlab]

@girder/components@4.0.0 (and likely earlier v4 releases) has three interacting issues in src/utils/restClient.js that, together, prevent reload-survives-auth when the Girder backend sets girderToken as HttpOnly (the default since girder/girder#3484, Dec 2023) and the front-end is served from a different origin than Girder (very common in dev: Vite/webpack on :5173/:8080 → Girder on a different port).

1. setCookieFromHash returns the entire URL hash as a "token" when no marker is present

restClient.js:19-29:

function setCookieFromHash(location) {
  const arr = location.hash.split(OauthTokenPrefix)
  const token = arr[arr.length - 1].split(OauthTokenSuffix)[0]
  if (token.length === GirderTokenLength) {
    // ... set cookie ...
  }
  return token   // <-- returned even when no marker matched
}

When window.location.hash is e.g. #/some/route/123 (i.e., any hash-routed SPA), the function returns "/some/route/123" as a "token". That value is then stored in this.token and sent as Girder-Token: /some/route/123 on every request → 401.

Pre-#3484, this code was dead in practice because cookies.get('girderToken') always succeeded first. Post-#3484, the JS cookie is gone, so this fallback runs and trips on the SPA's route hash.

Fix: only return the parsed token if it matched the marker; otherwise return null/empty.

2. The request interceptor sends Girder-Token even when empty, suppressing cookie auth

restClient.js:51-58:

this._axios.interceptors.request.use((config) => ({
  ...config,
  baseURL: this.apiRoot,
  headers: {
    [GirderToken]: this.token,   // <-- added unconditionally
    ...config.headers,
  },
}));

Girder's auth precedence is ?token= → Girder-Token header → girderToken cookie. An empty Girder-Token header still takes the header path — the cookie is never consulted as a fallback. So even if a valid HttpOnly cookie is present, a request from this client with this.token === "" will 401.

Fix: in the interceptor, skip adding the header when this.token is falsy, so the request goes out with no Girder-Token and Girder falls through to the cookie.

3. withCredentials is only set on the login call

restClient.js:107:

const resp = await this.get('user/authentication', {
  // ...
  withCredentials: this.authenticateWithCredentials,
});

withCredentials is only attached to the user/authentication call, and is gated on the authenticateWithCredentials option (default false). Every other request goes out without credentials. This means:

• Cookies are never sent cross-origin on any non-login request, so a deployment where the front-end origin differs from the Girder origin (dev typically, multi-origin prod sometimes) cannot use cookie-based auth at all.
• The Set-Cookie returned by /user/authentication itself is silently dropped by the browser when the login request is cross-origin and authenticateWithCredentials is left at its default false. So the HttpOnly cookie never gets persisted to begin with.

Fix: apply withCredentials: this.authenticateWithCredentials to all requests via the interceptor, not just login. (Or, even better, default authenticateWithCredentials to true — there's no realistic CSRF surface on /user/me etc., and the current default makes cookie auth essentially decorative in cross-origin setups.)

Combined symptom

In a hash-routed SPA on a different origin from Girder, after PR #3484:

1. User logs in. Set-Cookie: girderToken=...; HttpOnly is returned, but because authenticateWithCredentials defaulted to false and the request was cross-origin, the browser drops it. JS reads the token from the body and stays "logged in" via in-memory state + a JS-set host-only cookie at the front-end origin.
2. User reloads. New RestClient instance. cookies.get('girderToken') at the front-end origin returns the JS-set cookie if the browser kept it (Chrome's localhost-port handling is inconsistent here; HttpOnly conflict on same name can also block the JS set). If not, falls to setCookieFromHash (issue Use preferred shorthand yarn commands #1) → returns garbage.
3. First API call goes out with Girder-Token: <garbage> (or with Girder-Token: empty if the consumer sanitized Use preferred shorthand yarn commands #1) → 401. Cookie fallback never engages because of issues REST client utility #2 and CircleCI integration #3.

Suggested patch

--- a/src/utils/restClient.js
+++ b/src/utils/restClient.js
@@ function setCookieFromHash(location) {
-  if (token.length === GirderTokenLength) {
-    const expires = new Date()
-    expires.setDate(expires.getDate() + 365)
-    setCookieFromAuth({ token, expires })
-    location.hash = location.hash.replace(`${OauthTokenPrefix}${token}${OauthTokenSuffix}`, '')
-  }
-  return token
+  if (token.length !== GirderTokenLength) {
+    return null
+  }
+  const expires = new Date()
+  expires.setDate(expires.getDate() + 365)
+  setCookieFromAuth({ token, expires })
+  location.hash = location.hash.replace(`${OauthTokenPrefix}${token}${OauthTokenSuffix}`, '')
+  return token
 }
@@ this._axios.interceptors.request.use((config) => ({
-      ...config,
-      baseURL: this.apiRoot,
-      headers: {
-        [GirderToken]: this.token,
-        ...config.headers,
-      },
-    }));
+    this._axios.interceptors.request.use((config) => {
+      const headers = { ...(config.headers || {}) }
+      if (this.token) {
+        headers[GirderToken] = this.token
+      }
+      return {
+        ...config,
+        baseURL: this.apiRoot,
+        withCredentials: this.authenticateWithCredentials || config.withCredentials,
+        headers,
+      }
+    });

Reproducible with any Vue 3 + Vue Router (hash mode) + Girder 5.x backend on a separate origin from the front-end.

Versions:

• @girder/components: 4.0.0
• Girder backend: 5.0.7
• Browser: Chrome 147

[arjunrajlab]

Correction / clarification after debugging the actual flow.

Issues #2 (empty Girder-Token header suppressing cookie auth) and #3 (withCredentials only on login) in my original post are not the load-bearing problem, because Girder's API endpoints reject cookie-based auth by design regardless of how cleanly the cookie is delivered. Per Girder's @access.cookie decorator pattern, only a small set of routes (mostly file downloads) opt into cookie auth, as a CSRF measure. So even when we got the cookie delivered correctly cross-origin, /user/me and all the other endpoints needed for normal app operation still returned null (anonymous). I confirmed this with curl — direct call to a same-host backend with a fresh, valid girderToken cookie still returns null until the same value is sent as Girder-Token header.

This means the suggested patch for #2/#3 doesn't actually fix anything — those changes would only matter if Girder accepted cookie auth on the relevant endpoints, which it doesn't.

The real chain that breaks reload is narrower and shifts the fix entirely:

1. Girder 5+ sets girderToken as HttpOnly (Mark auth cookie as httponly girder#3484).
2. v4 RestClient persists the auth token by calling js-cookie.set('girderToken', token) after login (restClient.js:16-17, used from line 113 in login() and line 150 in register()).
3. Modern browsers silently reject that JS set on cookie-hygiene grounds — RFC 6265bis §5.7 step 11.2: when a same-name HttpOnly cookie already exists, the JS-originated set is dropped. Confirmed in Chrome 147; spec behavior is consistent across Firefox and Safari.
4. On reload, cookies.get('girderToken') returns undefined — the only HttpOnly copy at the front-end origin (if there even is one) is invisible to JS.
5. setCookieFromHash runs as the fallback and returns garbage (issue Use preferred shorthand yarn commands #1 in the original post — that part stands).
6. Garbage token goes out as Girder-Token: #/some/route → 401. Cookie fallback in Girder is a no-op because the endpoint doesn't allow cookie auth anyway.

So issue #1 from the original post is real and worth fixing. Issues #2 and #3 are misanalyses I'd retract.

The deeper issue is step 2/3: the persistence mechanism v4 chose (a same-named JS-set cookie) was always going to break against an HttpOnly Girder backend, and there's no way for the client to recover the token from document.cookie once the backend opts in. There's no place to put the persisted token where v4 can read it back on reload, short of changing the storage mechanism.

Suggested fix (in addition to the setCookieFromHash patch from the original post):

Switch token persistence from js-cookie to either:

• localStorage under a key like girderAuthToken (no conflict with the server's HttpOnly girderToken).
• A differently-named JS-set cookie (e.g., girderTokenJs), same security model but cookie-shaped.

Either approach decouples client-side persistence from the server's Set-Cookie and stops the HttpOnly conflict. Same XSS exposure as the current design (the v4 cookie is already non-HttpOnly and JS-readable by definition), so no security regression.

Workaround for consumers stuck on v4: in your RestClient factory, after new RestClient(...), restore client.token from localStorage if present, and listen on userLoggedIn / userLoggedOut / userFetched to keep localStorage in sync. ~15 lines, no library patch needed. Posted a working example at [arjunrajlaboratory/NimbusImage commit on claude/girder-token-logout-VUhQf] for reference.

Sorry for the noise on the original report — the SameSite / withCredentials theory was a plausible-looking dead end. The actual culprit is much smaller and more cleanly fixable.

[arjunrajlab]

One more data point that's worth surfacing: the localStorage suggestion isn't novel — it's what Girder's own reference web client switched to in the same PR (#3484) that added the HttpOnly server cookie. From girder/web_client/src/auth.js in that PR:

-var currentToken = cookie.find('girderToken');
+var currentToken = window.localStorage.getItem('girderToken');

-        if (cors && !cookie.find('girderToken')) {
-            // For cross-origin requests, we should write the token into
-            // this document's cookie also.
-            document.cookie = 'girderToken=' + getCurrentToken();
-        }
+        window.localStorage.setItem('girderToken', response.user.token.token);

And rest.js:

-        girderToken: getCurrentToken() || cookie.find('girderToken'),
+        girderToken: getCurrentToken() || window.localStorage.getItem('girderToken'),

The old cookie helpers are still in the file marked // TODO delete in next major version. So Girder upstream has already concluded that, when the server cookie goes HttpOnly, JS clients must persist the bearer token in localStorage rather than a same-named JS cookie — and they made that swap in the same change that introduced the HttpOnly behavior.

This makes the upstream fix for @girder/components essentially "bring v4 into line with what girder/web_client already does." It's not a design debate; it's just keeping the two reference clients consistent.