Un cookie strict e un nuovo dominio
Dopo il passaggio di EAuth a un dominio proprio, l'accesso alla console riportava al login. Perché lo causa un cookie SameSite=Strict e cosa significa per Lei.
Il trasloco di EAuth su eauth.me ha rotto l'accesso alla nostra console in un modo che sembrava niente: si effettuava l'accesso e si finiva di nuovo sulla pagina di login. Lo abbiamo scoperto otto giorni prima che il trasloco andasse online, e lo abbiamo corretto allora. Vale la pena mettere per iscritto la causa, perché chiunque acceda con EAuth e usi un cookie di sessione strict incontrerà lo stesso problema.
Cosa è successo
L'accesso alla console funziona così. La console La manda a EAuth, EAuth verifica la Sua password e La rimanda all'indirizzo di callback della console con un codice. Il callback scambia il codice, imposta il cookie di sessione della console e La manda avanti alla console vera e propria.
Il cookie di sessione della console è SameSite=Strict, e lo stesso vale per quello della dashboard. Un cookie strict viene inviato solo con una richiesta avviata dallo stesso sito. Non viene mai inviato quando la navigazione la avvia un altro sito, nemmeno per un semplice link. Per una superficie amministrativa è una scelta voluta: nessuna pagina altrove può far agire il Suo browser nella console mentre Lei è connesso.
Finché EAuth stava su auth.elchi.dev, EAuth e la console erano lo stesso sito, perché un browser decide se si tratta dello «stesso sito» in base al dominio registrabile, elchi.dev, e non al nome host completo. Su eauth.me non lo sono più. La navigazione di ritorno al callback ora la avvia eauth.me. Il callback impostava il cookie e rispondeva con un redirect alla console, e il browser inviava la richiesta successiva senza il cookie. Un redirect dal nostro stesso server non cambiava chi aveva avviato la navigazione. La console non vedeva alcuna sessione e mostrava la pagina di login.
Cosa abbiamo cambiato
Le risposte abituali sono tre.
- Rendere il cookie
Lax. Un cookie lax accompagna una navigazione di primo livello partita da un altro sito, quindi il redirect lo porterebbe con sé. Per la maggior parte delle applicazioni è il default giusto. Per la nostra console e la dashboard volevamo restare su strict. - Usare due cookie, uno lax che dice soltanto «qualcuno ha effettuato l'accesso» e uno strict per tutto ciò che modifica qualcosa. Solido, ma con più parti in movimento di quante ce ne servissero.
- Concludere il callback su una pagina nostra. Il callback imposta il cookie e risponde con una piccola pagina che prosegue da sola. Una navigazione avviata da quella pagina è avviata dal sito stesso della console, quindi il cookie strict la accompagna.
Abbiamo scelto la terza. La pagina contiene un'istruzione di refresh e un semplice link, nessuno script, e resta sullo schermo il tempo di una richiesta. Manda il browser soltanto verso un percorso sull'host della console: qualunque altra destinazione riceva diventa la pagina iniziale, e il controllo sta nel codice, non è lasciato al template. La pagina non invia alcun referrer e non viene mai messa in cache.
Il costo è piccolo: il callback risponde con qualche riga di HTML invece che con un redirect, e un browser che ignora il refresh mostra un link da cliccare. Rinunciare ai cookie strict sulla console sarebbe costato di più, solo in modo meno visibile.
Se Lei sviluppa su EAuth
Dal 3 ottobre 2026 auth.elchi.dev si limita a reindirizzare a eauth.me, quindi ogni applicazione che usa EAuth per l'accesso si trova su un sito diverso da EAuth. Ne seguono tre cose.
- Un cookie di sessione strict si comporta come il nostro. Se lo imposta nel callback e poi fa un redirect, la richiesta successiva arriva senza. Usi
Lax, oppure concluda il callback su una pagina che prosegue la navigazione. - Tutto ciò che salva prima di mandare qualcuno a EAuth, lo
statee il verifier PKCE, deve tornare con quella navigazione cross-site. In un cookie, questo significaLax. Il nostro SDK li tiene nel session storage, che non ha questa regola: appartiene alla scheda, e la scheda che torna è la stessa. - Il logout funziona allo stesso modo nella direzione opposta: mandi il browser all'
end_session_endpointdi EAuth con l'ID token che possiede comeid_token_hint, e il browser torna all'indirizzo post-logout che ha registrato. Senza l'hint, EAuth chiede conferma alla persona prima di disconnetterla e non la manda verso un indirizzo che non può verificare.
Il cookie di sessione di EAuth stesso è Lax proprio per il primo motivo: deve arrivare quando un'applicazione manda qualcuno ad accedere, e quella navigazione è sempre avviata da un altro sito. I moduli sulle pagine di EAuth non si affidano solo a questo. Ognuno porta un token derivato dalla sessione e deve essere inviato da eauth.me stesso.
Fonti
- Set-Cookie header, SameSite, MDN, consultato il
- Cookies: HTTP State Management Mechanism (draft-ietf-httpbis-rfc6265bis), IETF, consultato il
- Site (glossary), MDN, consultato il
- OpenID Connect RP-Initiated Logout 1.0, OpenID Foundation, consultato il
Scritto da Samuel Krauss, Founder. Archiviato in eauth, cookies.
Tradotto dall’inglese. Leggi l’originale inglese