Acceso privado

Cómo abre una aplicación privada un miembro o un invitado: el canje en el host de la aplicación, la cookie de acceso limitada al host, los permisos de recurso de corta duración, los dos errores de acceso y lo que la privacidad no puede ocultar.

  • Disponibilidad: Experimental
  • Evidencia: Leído del código fuente
  • Referencia

Aplicaciones públicas y privadas

Las aplicaciones gratuitas son públicas: cualquiera que tenga la URL puede obtener sus recursos. Una aplicación privada es una capacidad premium que un operador de la plataforma habilita manualmente para una organización. Niega su HTML y todos los recursos restringidos salvo que la solicitud lleve un permiso de recurso válido. Negar es lo predeterminado: sin acceso, un release privado responde ACCESS_REQUIRED incluso para rutas que no existen, así que no revela nada de lo que contiene.

Quién puede abrir una aplicación privada

Un permiso de recurso se apoya en una de dos cosas:

  • Un permiso de invitado. Una persona ajena a la organización tiene un permiso limitado a una aplicación, que vence y se puede revocar. No es una cuenta, una membresía ni una credencial de registro, y la API de administración nunca lo acepta. Consulta Acceso e invitados.
  • Un pase de miembro. Un miembro de la organización propietaria cuyo rol incluye application.read le pide a la API de administración un ticket de miembro de un solo uso con access.tickets.create. El pase es válido durante una ventana de confirmación, window; pedir un ticket otra vez lo confirma otra vez.

El canje

El acceso se establece en el propio host de la aplicación, nunca en un host de la plataforma.

Solicitud en el host de la aplicación Propósito
GET /_beyond/access Una página estática sin contenido de la aplicación. Los enlaces de invitación y de miembro apuntan a ella: https://<host>/_beyond/access#token=… para un invitado y #ticket=… para un miembro.
POST /_beyond/access/exchange JSON {"token": "<guest token>"} o {"ticket": "<member ticket>"}. Responde 204 con la cookie de acceso.
POST /_beyond/access/leave Quita la cookie

El secreto viaja en el fragmento de la URL. Un navegador nunca envía un fragmento a un servidor, así que el secreto no llega a ningún registro de servidor, referente ni proxy. La página lo lee, lo envía al endpoint de canje y abre /.

Un secreto desconocido, ya usado, vencido, revocado o de otra aplicación responde 403 ACCESS_DENIED, sin indicar cuál es el caso. Una solicitud cuyo Origin nombra otro host se rechaza.

HTTP
Set-Cookie: __Host-beyond-access=<grant token>; Max-Age=<seconds>; Path=/; HttpOnly; Secure; SameSite=Lax

El prefijo __Host- hace que los navegadores exijan Secure, Path=/ y la ausencia de Domain. La cookie está limitada al host: nunca puede asociarse a un dominio superior compartido con la plataforma o con otro cliente. Contiene el permiso de recurso de corta duración, nunca el token de invitación ni el ticket.

Las credenciales de la plataforma no significan nada en el host de una aplicación. Allí se ignora un encabezado Authorization, un token bearer de la plataforma no se puede canjear, y ninguna respuesta establece una cookie de la plataforma.

Los permisos son cortos y se renuevan solos

Un permiso de recurso dura poco y nunca sobrevive a aquello en lo que se apoya. En una solicitud que llega en la segunda mitad de su vida, el servicio comprueba el apoyo y, mientras se mantenga, establece en la respuesta un permiso nuevo con un token nuevo. Una aplicación que sigue cargando conserva su acceso. Un cliente que permanece inactivo durante toda la vida de un permiso hace el canje de nuevo: un invitado con la misma invitación mientras sea válida, un miembro con un ticket nuevo.

Qué responde la entrega

Estado Código Significado
401 ACCESS_REQUIRED No hay cookie de acceso, o el permiso se agotó. Haz el canje de nuevo.
403 ACCESS_DENIED Un permiso que existe y no permite esto: fue revocado, pertenece a otra aplicación, o es un invitado que pide contenido solo para miembros, como los source maps restringidos

Ambas negativas llevan Cache-Control: private, no-store y Vary: Cookie, y ningún encabezado WWW-Authenticate. Una respuesta correcta a una solicitud autorizada se almacena de forma privada, durante la vida de un permiso, y nunca es public ni immutable:

Text
Cache-Control: private, max-age=60
Vary: Cookie

La revocación es acotada, no instantánea

  • Revocar un permiso de invitado termina el permiso y los permisos de recurso que se apoyan en él en una sola transacción. El servicio rechaza la siguiente solicitud con 403 ACCESS_DENIED. Lo que un navegador almacenó de forma privada caduca con su max-age.
  • Por cualquier otro camino, como un vencimiento o un pase de miembro que dejó de confirmarse, el permiso de recurso simplemente no se vuelve a emitir y se agota solo.
  • Un miembro eliminado pierde el acceso después de la ventana de confirmación más el tiempo durante el cual se guarda en caché la respuesta de la autoridad.

Un cliente que no es un navegador

Un ejecutor externo o un script hace lo mismo por HTTP:

  1. POST https://<host>/_beyond/access/exchange con Content-Type: application/json y el token de invitado.
  2. Conserva la cookie __Host-beyond-access y envíala en cada solicitud.
  3. Reemplázala cada vez que una respuesta traiga Set-Cookie.
  4. Cuando una solicitud responda 401, haz el canje de nuevo.

Lo que la privacidad no cubre