BA
Better Auth•3w ago
Kenny

Admin Plugin - Issue with cookie cache and secondary storage not updating on `auth.api.setRole` call

I'm encountering a problem with cookie cache and secondary storage behavior when updating user roles using auth.api.setRole in my Remix+Better-Auth project. Issue description: - When I call auth.api.setRole to update a user's role (e.g., promote a user to "admin" or revert them), the response headers do not include any Set-Cookie headers. Example response headers look like this: 
  { "Content-Type": "application/json" }
  
  { "Content-Type": "application/json" }
- Because of this, the cookie session does not update on the client side. - In my Cloudflare KV store (which is configured as the secondaryStorage for Better-Auth), the user data appears duplicated rather than updated properly. I assume the KV data is supposed to be tied to the session cookie. - This leads to inconsistent state where I can promote a user to admin and then when logged in as a "member", change them back to admin again, since cookie cache and secondary storage aren't working properly. - Even when I forcibly disable cookie cache like this: 
  const session = await auth.api.getSession({
    headers: request.headers,
    query: {
      disableCookieCache: true,
    },
  });
  
  const session = await auth.api.getSession({
    headers: request.headers,
    query: {
      disableCookieCache: true,
    },
  });
the problem persists.
2 Replies
Kenny
KennyOP•2w ago
Environment & Setup: - Using Better-Auth with Kysely-D1 dialect on Cloudflare Workers. - Cookie cache is enabled with 5-minute maxAge. - Secondary storage is backed by Cloudflare KV with typical get, set, and delete operations. - setRole API response does not contain any Set-Cookie header, which seems unusual since the session info should theoretically be updated or synced after role changes. - Relevant portion of serverAuth config: 
  session: {
    modelName: "firestorm_sessions",
    cookieCache: {
      enabled: true,
      maxAge: 300,
    },
  },
  secondaryStorage: {
    get: (k) => FIRESTORM_AUTH_KV.get(k),
    set: (k, v) => FIRESTORM_AUTH_KV.put(k, v),
    delete: (k) => FIRESTORM_AUTH_KV.delete(k),
  },
  
  session: {
    modelName: "firestorm_sessions",
    cookieCache: {
      enabled: true,
      maxAge: 300,
    },
  },
  secondaryStorage: {
    get: (k) => FIRESTORM_AUTH_KV.get(k),
    set: (k, v) => FIRESTORM_AUTH_KV.put(k, v),
    delete: (k) => FIRESTORM_AUTH_KV.delete(k),
  },
- In my admin users PATCH handler, after calling auth.api.setRole, the returned Response headers lack any cookies. Could someone please help clarify: 1. Should auth.api.setRole update the session cookie or send Set-Cookie headers automatically on role change? 2. Does Better-Auth sync the updated user data to secondary storage automatically on setRole? Or do I need to do something manually to prevent duplication or stale data? 3. Could the lack of cookie headers in the response be expected behavior? If so, how should the session and cookie cache be properly updated after role changes? 4. Anything else I should look for or debug to ensure cookie cache and secondary storage remain consistent with user updates? Thank you for any pointers or explanations! I should also mention that if I run the command to update my user's name attribute with that api right after everything is updated in cookies and second storage properly so I have isolated the issue to auth.api.setRole. running it on the client doesn't fix it either This is the temporary workaround I came up with (located after authClient.admin.setRole`: 
            // HACK to force secondary and cookie storage to be updated
            // Track https://discord.com/channels/1288403910284935179/1367653484496683169
            await authClient.updateUser({
                name: user.name,
            });
            // HACK to force secondary and cookie storage to be updated
            // Track https://discord.com/channels/1288403910284935179/1367653484496683169
            await authClient.updateUser({
                name: user.name,
            });
bump
La_rs
La_rs•2w ago
The session in secondary storage is also not updated when the user verifys their email I think it is a bug, that only updateUser updates the session in secondary storage

Did you find this page helpful?