Ir al contenido principal

Cookies de sesión compartidas entre subdominios

 Cita de la documentación de Laravel Sanctum: you should ensure your application's session cookie domain configuration supports any subdomain of your root domain. You may accomplish this by prefixing the domain with a leading . within your application's config/session.php configuration file:

1'domain' => '.domain.com',



Este texto te da un consejo muy útil para configurar las cookies de sesión en tu aplicación Laravel, especialmente cuando trabajas con subdominios.

La frase dice:

"Debes asegurarte de que la configuración del dominio de la cookie de sesión de tu aplicación soporta cualquier subdominio de tu dominio raíz.1 Puedes lograr esto prefijando el dominio con un punto inicial (.) dentro del archivo de configuración config/session.php de tu aplicación: 'domain' => '.dominio.com'"

Vamos a desglosarlo para que quede bien claro:


Entendiendo la Cookie de Sesión y su Dominio

Cuando un usuario inicia sesión en una aplicación web, el servidor (Laravel, en este caso) generalmente le envía una cookie de sesión al navegador. Esta cookie contiene un identificador único que el navegador devuelve en cada solicitud posterior, permitiendo al servidor "recordar" que el usuario está autenticado y mantener su sesión activa.

El dominio de una cookie es una propiedad crucial. Por defecto, una cookie solo es visible y enviada por el navegador a las solicitudes que van al mismo dominio exacto que la estableció.


El Problema con los Subdominios

Imagina que tienes:

  • Tu aplicación principal en: www.tuapp.com
  • Un subdominio para tu blog en: blog.tuapp.com
  • Un subdominio para tu API en: api.tuapp.com

Si un usuario inicia sesión en www.tuapp.com y la cookie de sesión se establece con el dominio www.tuapp.com, esa cookie no se enviará automáticamente cuando el navegador haga una solicitud a blog.tuapp.com o api.tuapp.com. Esto significa que el usuario tendría que iniciar sesión de nuevo en cada subdominio, lo cual es una mala experiencia.


La Solución: El Prefijo con un Punto (.) en el Dominio Raíz

Aquí es donde entra en juego la solución que propone el texto. Al prefijar el dominio con un punto (.) en la configuración de la cookie de sesión de Laravel, le estás diciendo al navegador que la cookie es válida no solo para el dominio exacto, sino también para todos sus subdominios.

  • Configuración en config/session.php:
    PHP
    'domain' => '.tuapp.com',
    
    (Reemplaza tuapp.com con tu dominio real).

¿Qué logra esto?

Si la cookie de sesión se establece con el dominio .tuapp.com:

  • Cuando el usuario navega a www.tuapp.com, la cookie se envía.
  • Cuando navega a blog.tuapp.com, la cookie también se envía.
  • Cuando navega a api.tuapp.com, la cookie también se envía.

Esto crea una experiencia de "inicio de sesión único" (Single Sign-On o SSO) entre tus diferentes subdominios, ya que la sesión del usuario se mantiene activa a través de todos ellos.


¿Cuándo es esto especialmente útil?

  • Aplicaciones Modulares: Si tienes diferentes partes de tu aplicación alojadas en subdominios (ej. un panel de administración en admin.tuapp.com, un e-commerce en shop.tuapp.com).
  • SPAs con API en Subdominios: Si tu SPA está en app.tuapp.com y tu API de Laravel en api.tuapp.com, y estás usando la autenticación de SPAs de Laravel Sanctum (que se basa en cookies/sesiones para dominios de primera parte), esta configuración es esencial para que las cookies de sesión se compartan entre ambos subdominios y la autenticación funcione correctamente.

En resumen, añadir un . (punto) al inicio del dominio en tu configuración de sesión de Laravel asegura que tu cookie de sesión sea válida para tu dominio principal y todos sus subdominios, permitiendo que la sesión del usuario persista a través de ellos.


Comentarios

Entradas populares de este blog

Crear proyecto de frontend con Vite, React, Tailwind, Typescript y JSX

 ¿Cómo se crea un proyecto exclusivo de frontend con Vite, React, Tailwind, Typescript y JSX? ¡Absolutamente! Entiendo que quieres la guía completa para pasar de cero a tener un proyecto de frontend moderno, vacío y listo para ser llenado con tu código. A continuación, te proporciono un archivo de guía detallada que incluye todos los comandos necesarios para inicializar el proyecto, configurar Tailwind CSS, y los pasos clave para empezar a "poblarlo". Voy a generar un documento Markdown con la guía paso a paso, incluyendo los comandos de terminal y las modificaciones esenciales a los archivos de configuración. Guía: Creación de un Proyecto Frontend Puro (Vite, React, TypeScript, Tailwind) Este documento detalla el proceso para inicializar un proyecto de frontend vacío y optimizado, utilizando Vite como empaquetador, React como librería, TypeScript para tipado y Tailwind CSS para estilizado. 1. Inicialización del Proyecto con Vite Vite es la herramienta más rápida para emp...

Tokens V2

Tokens: Programme to discover tokens, where there are not. Now available at  https://puszcza.gnu.org.ua/projects/tokens/ This is Version 2, for  version 1, go here . Synopsis: use TokensV2; sub printFile; my @FORMAT = ( ['<Message Date=".*?" Time=".*?" DateTime=".*?" SessionID=".*?"><From>(?:<User FriendlyName=".*?"/>)+</From><To>(?:<User FriendlyName=".*?"/>)+</To><Text(?: Style=".*?")?>.*?</Text></Message>',   sub {     my $fh = $_[1];     my ($d, $t, $f, $s, $T) = $_[0] =~ m|<Message Date="(.*?)" Time="(.*?)" DateTime=".*?" SessionID=".*?">(<From>(?:<User FriendlyName=".*?"/>)+</From>)<To>(?:<User FriendlyName=".*?"/>)+</To><Text(?: Style="(.*?)")?>(.*?)</Text></Message>|;     my $F = join '<br />', ...

Perl Net::LDAP::SimpleServer

Adaptaciones sobre el módulo LDAP Server para Windows (Strawberry Perl) Lista de adaptaciones (continúa más abajo): - Relajación de condiciones de bind:     - Cuenta principal (principal account)     - Validación de contraseñas Ubicación del archivo: %Strawberry_Perl%\site\lib\net\ldap\SimpleServer\ProtocolHandler.pm CPAN: http://search.cpan.org/~russoz/Net-LDAP-SimpleServer-0.0.17/lib/Net/LDAP/SimpleServer.pm Código: package Net::LDAP::SimpleServer::ProtocolHandler; use strict; use warnings; # ABSTRACT: LDAP protocol handler used with Net::LDAP::SimpleServer our $VERSION = '0.0.17';    # VERSION use Net::LDAP::Server; use base 'Net::LDAP::Server'; use fields qw(store root_dn root_pw allow_anon); use Carp; use Net::LDAP::LDIF; use Net::LDAP::Util qw{canonical_dn}; use Net::LDAP::FilterMatch; use Net::LDAP::Constant (     qw/LDAP_SUCCESS LDAP_AUTH_UNKNOWN LDAP_INVALID_CREDENTIALS/,   ...