Seguridad y trabajo diario - Jira Cloud

Ámbitos y herencia

La configuración de Jira tiene dos niveles: cuenta y proyecto. Un proyecto sin credenciales propias hereda la dirección de la instancia, el correo y el token de la cuenta - la misma conexión sirve a todos los proyectos que no tienen motivo para informar a otra instancia. La cuenta interna de Dock tiene además acceso a la configuración de la plataforma: es el único caso en que un proyecto sin configuración propia ni de cuenta recurre a los ajustes que ha escrito un superadministrador. Los suscriptores nunca ven la configuración de la plataforma - el mismo límite que en Slack, Mattermost, Discord y Notion.

Quién tiene acceso

Las pantallas de Jira exigen el permiso de gestión de proyectos. Quien puede editar un proyecto en DockRay también puede conectar o desconectar su integración con Jira - no existe un permiso aparte solo para Jira, porque forma parte de la misma responsabilidad.

El token de API y su protección

El token de API se guarda cifrado y nunca vuelve al formulario - un campo vacío en los ajustes no significa un token vacío, sino 'deja el que ya está guardado'. La propia dirección de la instancia está restringida a direcciones HTTPS públicas en el dominio *.atlassian.net, y la clave del proyecto de Jira entra directamente en la ruta de la petición, así que solo se acepta su forma real:

^[A-Z][A-Z0-9_]*$

Sin esta regla, una cadena como ../ escrita como clave de proyecto sacaría la petición fuera del endpoint previsto de la API de Jira.

Qué sale hacia Jira, y qué nunca sale

A la descripción del ticket llega el fragmento relevante de la pila de llamadas - los marcos que pertenecen al código propio de la aplicación cliente, o la cima de la pila cuando no hay ninguno. Nunca se envían, en cambio, los valores de las variables locales, las cabeceras de la petición, los datos del usuario ni la cadena de consulta - la dirección se recorta a la simple ruta, porque los tokens y las claves suelen viajar en los parámetros de consulta. Es el mismo límite que rige las integraciones de MCP y Notion, porque un único lugar del código decide qué sale de un error hacia fuera. 'Repeticiones' y 'primera aparición' en la lista de datos se refieren a un solo día - lo que cabe en una fila de la tabla de errores.

Un campo vacío: ¿'borrar' o 'no cambiar'?

Que un campo vacío del formulario borre un valor guardado o lo deje intacto lo decide la pantalla de ajustes, no la propia escritura en la base de datos. Esto importa al pasar un proyecto de sus propias credenciales a heredarlas de la cuenta: borrar la dirección de la instancia debe borrar también el token antiguo, para que el proyecto empiece de verdad a heredar y no se quede solo aparentándolo, con el token ajeno guardado en silencio.

Rotar el token y bajas del equipo

El token de API pertenece a la cuenta de Atlassian que lo generó, no a la persona que técnicamente rellenó el formulario en DockRay. Cuando esa persona pierde el acceso a la cuenta de Atlassian o deja el equipo, hay que regenerar el token en los ajustes de Atlassian y pegarlo en DockRay - la integración no lo detectará por sí sola, porque desde su punto de vista el token simplemente deja de funcionar en cuanto falla la primera petición. La sospecha de que un token se ha filtrado ya es motivo suficiente para revocarlo de inmediato en el lado de Atlassian, sin esperar a que alguien actualice la configuración en el panel.