vincent15000's avatar

Prefix for session cookie

Hello,

Laravel / InertiaJS / VueJS

I have added a prefix to the session cookie and it's not possible to login anymore.

'cookie' => env(
    'SESSION_COOKIE',
    '__Host-'.Str::slug(env('APP_NAME', 'laravel'), '_').'_session'
),

Why ?

Can you help me to keep this prefix ? What do you suggest me to check ?

Thanks.

V

0 likes
10 replies
LaryAI's avatar
LaryAI
AI
3 days ago
Level 58

Certainly! Here’s an explanation and solution:

When you prepend the prefix __Host- to your session cookie, you need to satisfy strict requirements enforced for cookies that use this prefix. According to the specification:

  • The cookie must be Secure (i.e., sent over HTTPS).
  • The cookie must have Path=/.
  • The cookie must NOT have a Domain attribute.
  • The cookie should not be set from client-side JavaScript.

If any of these conditions are not met, the browser will refuse to set or send the cookie. That’s likely why login/authorization is failing.

What to check in your Laravel setup:

  1. Configure secure: Make sure your config/session.php has secure set to true, or set via your .env:

    SESSION_SECURE_COOKIE=true

  2. Configure path: Ensure your path is '/' (which is default in Laravel):

    'path' => '/',

  3. Unset domain: Set the domain key in config/session.php to null or omit it entirely:

    'domain' => null,

    Or in your .env:

    SESSION_DOMAIN=null

  4. Use HTTPS:
    If you’re not serving your application over HTTPS, the cookie will never be sent.

Example config/session.php settings:

'cookie' => env(
    'SESSION_COOKIE',
    '__Host-'.Str::slug(env('APP_NAME', 'laravel'), '_').'_session'
),
'path' => '/',
'domain' => null, // This must be null for __Host- prefix
'secure' => env('SESSION_SECURE_COOKIE', true),

And ensure in your .env:

SESSION_SECURE_COOKIE=true
SESSION_DOMAIN=null
SESSION_COOKIE=

Now, using the __Host- prefix should work properly in supported browsers if and only if you are using HTTPS.

Summary:
If you add the __Host- prefix to cookies, ensure you meet all its requirements (secure, path, no domain, HTTPS). Otherwise, cookies won’t be set and session (including login) will break!

References:

imranbru's avatar

99% of the time I see this break, it's because you are testing locally over HTTP.

The __Host- prefix tells the browser to strictly enforce HTTPS. If you're using php artisan serve or an un-secured Valet/Herd site, the browser will silently drop the cookie. Inertia then fails to authenticate because the session cookie literally doesn't exist in your browser, causing 419 or 401 errors.

'cookie' => env('APP_ENV') === 'production' 
    ? '__Host-' . Str::slug(env('APP_NAME', 'laravel'), '_') . '_session'
    : Str::slug(env('APP_NAME', 'laravel'), '_') . '_session',

Also, triple-check your .env file. If you have SESSION_DOMAIN=localhost (or anything else), remove it entirely. The __Host- spec requires the domain attribute to be completely omitted, not just null.

1 like
vincent15000's avatar

Hello,

I know that __Host- is only with an HTTPS connexion.

But this can be interesting => The __Host- spec requires the domain attribute to be completely omitted, not just null.

I set it to null as suggested in some documentation, but it didn't work.

vincent15000's avatar

I have tested and it's ok, but there is a problem.

When a user navigates to another page, the authentication is lost.

vincent15000's avatar

Oh effectively ... yes I understand ... well ... I went to this website.

https://securityheaders.com/

The diagnostic was simply that the cookie didn't have any prefix. So I read the documentation about what __Host- is and I thought that it was a good idea to add it ;).

JussiMannisto's avatar

Are you serving the site over https? Or are you using something like http://localhost?

Browsers ignore the secure flag of cookies on localhost. They treat *.localhost domains as special cases and don't enforce the secure requirement because it makes local development easier. But they should still respect cookie prefixes (if they're supported to begin with). If you're not using https, that would explain why your session cookies aren't working.

Please or to participate in this conversation.