Autenticación
Entras una sola vez y estás dentro de toda la suite. El login vive en planitone.co/login, se resuelve con Firebase Auth mediante Google Sign-In usando tu correo institucional, y deja una sesión compartida entre subdominios: iniciar sesión una vez te habilita DataLab, docs y las demás piezas sin volver a autenticarte.
Un solo inicio de sesión para toda la suite
La autenticación es central: no cada aplicación tiene su propio login, sino que toda la suite PlanItOne apunta al mismo punto de entrada. Te identificas con Google Sign-In y tu correo institucional, y a partir de ahí la sesión te acompaña a través de los subdominios.
Google Sign-In
La identidad la resuelve Firebase Auth con Google. Usas tu correo institucional: sin contraseñas propias que administrar ni recuperar.
Login central
El punto de entrada de la suite es planitone.co/login. Desde ahí nace la sesión que luego
reconocen DataLab, docs y las demás piezas.
Sesión compartida
La cookie de sesión tiene dominio .planitone.co, así que se comparte entre
subdominios. Un login vale para toda la suite.
Cookie protegida
La sesión pio_sid es HttpOnly y secure: viaja solo por
HTTPS y no es accesible desde JavaScript del navegador.
planitone.co/login con el botón de Google Sign-In y el ingreso con correo institucional.
Del login a los subdominios: paso a paso
El recorrido desde que pulsas «iniciar sesión» hasta que DataLab te reconoce es corto y siempre el mismo. Estos son los cuatro momentos:
Inicias sesión con Google
En planitone.co/login te autenticas con Google Sign-In y tu correo
institucional. Firebase Auth valida tu identidad.
Se obtiene un ID token
Tras el login, Firebase Auth entrega un ID token que representa tu identidad ya verificada. Ese token es la materia prima de la sesión, no la sesión en sí.
admin-api crea la session cookie
El servicio admin-api toma el ID token y, con createSessionCookie
(firebase-admin), emite la Firebase session cookie: la cookie pio_sid,
HttpOnly y secure, con dominio .planitone.co.
La sesión te sigue por los subdominios
Como la cookie es de dominio .planitone.co, se comparte con
datalab, docs y demás subdominios. Cada servidor la comprueba con
verifySessionCookie (firebase-admin) antes de dejarte pasar.
pio_sid la crea admin-api a partir de ese
token con createSessionCookie. Lo que viaja entre subdominios y lo que verifican los servidores es la
cookie, no el token.La cookie de sesión pio_sid
Toda la sesión se materializa en una sola cookie. Sus propiedades no son casuales: cada una responde a un motivo de seguridad o de alcance.
| Propiedad | Valor | Por qué |
|---|---|---|
| Nombre | pio_sid | Firebase session cookie que representa tu sesión en la suite. |
| La crea | admin-api | Con createSessionCookie (firebase-admin) a partir del ID token. |
| La verifica | Cada servidor | Con verifySessionCookie (firebase-admin) en cada petición protegida. |
| Dominio | .planitone.co | Se comparte entre subdominios: datalab, docs y demás. |
| HttpOnly | Sí | No es accesible desde JavaScript del navegador. |
| Secure | Sí | Solo viaja por HTTPS. |
| Cierre de sesión | Expira la cookie | Al cerrar sesión, pio_sid se expira y deja de valer. |
pio_sid. Como la cookie es la que se comparte entre subdominios, expirarla corta el acceso a la
suite. En equipos compartidos, cierra sesión al terminar.
El singleton de Firebase en el frontend
Del lado del navegador, la inicialización de Firebase está centralizada en un único punto para evitar conflictos. Todo el front consume la misma instancia.
firebase-init.js
Expone un singleton con app, db, auth y
storage listos para usar. Nadie más los inicializa.
Una sola initializeApp
Ningún otro módulo llama a initializeApp. Con eso se evita el error
app/duplicate-app por inicializar Firebase dos veces.
auth, db o storage,
impórtalos del singleton de firebase-init.js. No vuelvas a llamar initializeApp.