Netlify Functions ahora saben quién visita tu sitio
Si tu sitio está protegido con login de equipo o es un proyecto privado, tus funciones ya pueden identificar al usuario que hace la request, sin que tengas que montar un segundo login.
Qué cambia con context.user
En proyectos privados o sitios protegidos con team login de Netlify, tus Netlify Functions y Edge Functions ahora reciben un objeto context.user con la identidad de quien hizo la request. Ese objeto trae el ID del usuario, su email y la fecha de expiración de su acceso. No es algo que tengas que configurar aparte: si el sitio está protegido y el visitante inició sesión, context.user llega poblado a tu código. Si context.user no está presente, significa que no hay un usuario autenticado reconocido por Netlify en esa request.
El problema que resolvía a medias la protección de sitios
Antes, proteger un sitio con Netlify significaba que Netlify controlaba quién podía entrar, pero una vez adentro, tu código no tenía forma de saber quién era esa persona. Para tu función, todas las requests autenticadas se veían iguales. Si necesitabas mostrar datos distintos según el usuario, o registrar quién hizo qué, tenías que construir tu propio sistema de login encima del que ya te daba Netlify, duplicando esfuerzo y manteniendo dos capas de autenticación en paralelo. Ahora ese segundo login deja de ser necesario para estos casos: la identidad que ya usa tu equipo para entrar al sitio es la misma que le llega a tu código.
Por qué no se puede falsificar
Un punto central del cambio es que context.user no sale de headers que el visitante controla, sino que lo arma Netlify en el edge después de verificar al visitante. Esto importa porque si context.user viniera de un header de la request, cualquiera podría mandar su propio header y hacerse pasar por otra persona. Al venir de la verificación que hace Netlify antes de que la request llegue a tu función, un visitante no puede inyectar un ID o email falso. Esto es lo que habilita usar context.user directamente para decisiones de autorización dentro de tu código, sin pasos adicionales de validación.
Ejemplo: una función whoami
El ejemplo que da Netlify es una función que expone en /whoami quién es el usuario autenticado. Si context.user no está presente, la función responde 401. Si está presente, devuelve el ID, el email y la expiración del acceso como JSON. Es un patrón simple que podés adaptar directamente para debuggear permisos, armar un endpoint de sesión para tu frontend, o como punto de partida para lógica de autorización más compleja.
// netlify/functions/whoami.tsimport type { Config, Context } from '@netlify/functions'export default async (req: Request, context: Context) => { if (!context.user) { return new Response('Unauthorized', { status: 401 }) } return Response.json({ id: context.user.id, email: context.user.email, expiresAt: context.user.expiresAt.toISOString(), })}export const config: Config = { path: '/whoami' }Para qué sirve en la práctica
Netlify menciona explícitamente cuatro escenarios donde esto se vuelve útil. El primero es dashboards y herramientas internas que muestran a cada persona sus propios datos en vez de una vista genérica. El segundo es logs de auditoría que registran quién hizo un cambio o disparó una acción, algo que antes requería que la app mantuviera su propio sistema de identidad para poder atribuir eventos. El tercero son flujos de aprobación y revisión que necesitan saber quién aprobó qué, útil en herramientas internas de operaciones. El cuarto es configuración o permisos por persona dentro de una app interna, donde cada usuario puede tener acceso distinto a funciones según quién es.
Dónde aplica
Esto funciona en proyectos privados y en sitios protegidos con team login de Netlify, tanto en Functions como en Edge Functions. Es decir, no es un mecanismo de autenticación nuevo que tengas que activar por separado, sino una extensión de los dos mecanismos de protección que Netlify ya ofrecía: ahora, además de controlar el acceso, te dicen quién entró.
What you get
context.user expone ID, email y expiración de acceso del usuario autenticado por Netlify en Functions y Edge Functions.
Aplica solo en proyectos privados o sitios con team login protection, no es un sistema de auth nuevo.
El dato viene verificado por Netlify en el edge, no de headers de la request, así que no se puede falsificar.
Elimina la necesidad de un segundo login propio para casos como dashboards internos, audit logs o flujos de aprobación.
Si context.user no existe en la request, tu función debe tratarlo como no autenticado y responder en consecuencia.
Want a class on this?
If enough people ask for it, it goes on the schedule. No email, no name needed.