I currently have an application running Laravel as an API and a SPA app as the frontend, they reside in a domain myapp.com, the api is at api.myapp.com and the frontend is at app.myapp.com.
I'm using laravel sanctum as the authentication package and they're working fine, no errors or bugs of any kind, but something got me thinking, i'm planning to deploy a hotsite at the main domain (myapp.com), and one of the steps of installing/configuring sanctum as a SPA authentication alternative is to define a .env variable called SESSION_DOMAIN and setting it to .yourdomain.com, which in my case would be .myapp.com, and a .env variable called SANCTUM_STATEFUL_DOMAINS and setting it to spa.yourdomain.com which in my case would be app.myapp.com.
With that in mind, if i deploy a hotsite using laravel at the root domain (myapp.com), wouldnt it mean that the session from the API would be shared across the apps since the SESSION_DOMAIN variable is set to .myapp.com (which translates to all subdomains and the root domain)?
I tried to set the SESSION_DOMAIN variable to app.myapp.com in the API .env, but the browsers refuse to use the cookie saying that "this attempt to set a cookie was blocked because its domain attribute was invalid with regards to the current host url".
The API uses a database connection as a session driver and the hotsite would use a file session driver, they're separate projects, but the sanctum api defines the SESSION_DOMAIN env variable with the trailing dot, thats the reason for this doubt.
Hi!
I don't know what a hotsite is, but yes, you are correct. When you place a dot in front of your domain for the SESSION_DOMAIN value, the cookies will be available for every subdomain of that domain.
If you remove the dot, the cookies will only be available for your main domain or if you specify another domain, they will only be available there.
If you want to separate the sessions for each domain, then cookie based session auth is probably not what you are looking for and the API token based auth would be more of a fit for you. Then you have two separate systems with different sessions for each of them.
I wish you a great day!
Hi Tom,
Thanks you very much for the reply, when i say hotsite i mean a marketing campaign site, like a promotional site 😁.
Even if they're separate projects with different app_keys and different sessions drivers (the hotsite uses file based sessions and the api uses database based sessions) they would share sessions?
I took a look into it the past days and i learnt that for a session to be shared it must reside in the same location (same filesystem or same database connnection for example) and should be using the same app_key, so it would encrypt and decrypt using that same key (that i'm not so sure, that would be true if laravel uses the app_key to encrypt/decrypt the app key) so separate projects can read the same session.
For example, lets say we have two laravel projects in the way i described above, one promotional site running a laravel project on the domain myapp.com that uses a file based session driver and one API running a laravel project on the subdomain api.myapp.com that uses sanctum and uses database session driver to authenticate first party spa's using cookie based auth (as seen here.
With that, wen we access the promotional site, we got some response set_cookie headers regarding our session and csrf cookies, and thats ok, now, if we go into the spa (that resides on spa.myapp.com, in which is the only configured sanctum stateful domain, oh, and its a vue based frontend) and try to reuse the values from the cookies from the promotional site, it doesnt find the session, because theoretically the session is stored in another place (in the promotional site project storage) and the decrypted value would never be the same because the projects doenst share the same app_key.
Of course, all of that can be really wrong, and in that case i think we must add that information in the laravel documentation to prevent people from using sanctum cookie based auth in environments that uses different projects in the same root domain.
The only solution i can find (other than using tokens to authenticate a spa app) is to run the promotional site in other domain.
Thanks for your time.
Sign in to participate in this thread!
Laravel
Laravel News
Laracasts
Laravel Podcast