GitHub ha activado un encabezado temporal, X — GitHub-Stateless-S2S-Token, que permite forzar el nuevo formato de los GitHub App installation tokens en una única petición, facilitando la validación previa al despliegue general. La medida busca que integraciones y flujos puedan comprobar compatibilidad con el nuevo formato sin esperar a recibirlo por el rollout del servidor.
En el endpoint POST /app/installations/:installation_id/access_tokens el encabezado admite tres comportamientos: enabled devuelve un token stateless en formato JWT con prefijo ghs_, de aproximadamente 520 caracteres y con dos puntos (puntos) como separadores; disabled devuelve el token stateful clásico, una cadena opaca sin puntos; y si el encabezado está ausente se aplica el rollout normal del servidor. Cualquier otro valor en el encabezado se ignora y se aplica el comportamiento estándar. El encabezado solo anula la decisión del servidor para la petición concreta, y es de carácter temporal.
Para identificar rápidamente el tipo de token basta con inspeccionar la cadena tras el prefijo ghs_: dos puntos indican un JWT; ausencia de puntos indica un token opaco. GitHub recomienda actualizar las validaciones y expresiones regulares a ghs_[A — Za-z0-9\\._]{36,}, garantizar que columnas de base de datos y cabeceras acepten al menos 520 caracteres y tratar los tokens con prefijo ghs_ como cadenas opacas cuando se realice introspección.
El cambio afecta a GitHub Enterprise Cloud y a entornos con Data Residency; GitHub Enterprise Server no se ve afectado por este ajuste. Los siguientes despliegues se centrarán inicialmente en tokens server — to-server de Apps, incluido el Actions GITHUB_TOKEN. Además, GitHub anunció que publicará más detalles sobre posibles modificaciones en los tokens user-to-server usados en Copilot code review.
En la práctica, si el rollout alcanza una integración antes de estar lista, es posible recuperar tokens opacos usando X — GitHub-Stateless-S2S-Token: disabled mientras se adapta el código. Se recomienda probar proactivamente con enabled para validar el flujo end-to-end y con disabled para garantizar un degradado elegante; una vez validados ambos formatos, hay que quitar el encabezado del código de producción porque es temporal y pronto dejará de respetarse. Los tokens existentes seguirán funcionando hasta su expiración y, si el cambio afecta flujos críticos, GitHub Support y la comunidad de GitHub están disponibles para asistencia; consulte la documentación REST del endpoint para ejemplos de petición.
Fuentes
Respuestas (0)
Aún no hay respuestas en este tema.
