Pattern question, client-side init() + is_logged_in cookie

[Thomanidas]

Hi Artem, thanks for the module.

I've been using it in production for 7 months alongside Laravel Echo (in cookie/session mode, not token) and it works perfectly.

Quick context: my Nuxt SSR runs on a Cloudflare Worker, Laravel API in the US. The SSR init() call to /api/user takes 300–500ms and kills my TTFB.

I noticed big sites like GitHub do auth state client-side only, with a non-HttpOnly hint cookie (logged_in) so SSR pages can be CDN-cached without making per-user API calls. I want to apply the same idea with your module: move init() to a client-only plugin, and write custom middlewares that read the hint cookie in SSR and defer to useSanctumAuth() in client.

// plugins/sanctum-init-client.ts
export default defineNuxtPlugin({
  name: 'sanctum-init-client',
  dependsOn: ['nuxt-auth-sanctum'],
  async setup() {
    const { init } = useSanctumAuth()
    try { await init() } 
    catch (err) {
      // <-- logger consola with 401 and 419 -->
    }
  },
})

// app/middleware/auth.ts
export default defineNuxtRouteMiddleware(() => {
  if (import.meta.server) {
    if (!useCookie('is_logged_in').value) return navigateTo('/login')
    return
  }
  const { isAuthenticated } = useSanctumAuth()
  if (!isAuthenticated.value) return navigateTo('/login')
})

I haven't found a clear write-up of this pattern online — would really value your perspective on whether it's the right direction, or if there's something I'm missing that experienced devs handle differently.

Thanks!

[manchenkoff]

Hey @Thomanidas, thanks, glad this module helps!

I noticed big sites like GitHub do auth state client-side only, with a non-HttpOnly hint cookie (logged_in) so SSR pages can be CDN-cached without making per-user API calls.

It is indeed the way to go if you want to improve loading but there are some tricky things you should keep in mind. This cookie should be used only for non-sensitive UI which can be cached globally (no personal data, user names, etc). The main reason for this is that any user can set this cookie manually and uncover some part of your page which were not meant to be seen.

I want to apply the same idea with your module: move init() to a client-only plugin, and write custom middlewares that read the hint cookie in SSR and defer to useSanctumAuth() in client.

Yes, you can disable default module initialisation and set custom cookie on login call and delete it on logout, see sanctum:login and sanctum:logout hooks.

Then I would define some composable like useLocalAuthentication which would tell whether the user has this cookie set or not. It will let you use it in custom middleware like you described and some parts of pages or components (show button for auth only users). Although, I'd still prefer using sanctum:auth for sensitive pages where you show anything user-specific but if they are available just in CSR mode once user is fetched, it should be fine for your use-case.

The pitfall here is that you cannot combine middleware to do the early return, like your-auth -> [ok], sanctum:auth -> [skip] so if you keep both, sanctum:auth will behave like if there is no user - your-auth -> [ok], sanctum:auth -> [fail]. The reason is here, we check that user is set.

So, if you want to skip this, you would need to set some "default" user identity via useSanctumUser in your middleware in order to comply with sanctum:auth. This is more like a trick and I would not recommend doing that but I'm letting you know if you want to try this out.

would really value your perspective on whether it's the right direction, or if there's something I'm missing that experienced devs handle differently.

To sum up 😄 the best way probably to reduce the latency with your API (and potentially carefully cache it to speed up) but if you want to unlock pages without user-specfic data, this solution might work.

[manchenkoff]

Forgot to mention but if your case is just early-return on non-happy-path (block unauthetnicated users), then for sure it works well 😄

[Thomanidas]

Thanks Artem, that's exactly what I needed. Going with my own middleware and keeping the hint cookie strictly for UX. Agreed the real fix is API first 🙏