Guía de la versión preliminar · 0.1.0

Autenticación y permisos exactos

Conecta el editor y el navegador previstos, aprueba la solicitud correspondiente y mantén separadas las concesiones de código y repositorio.

La referencia de la API está en inglés.

Identifica qué necesita acceso

CodeSecurity toma varias decisiones independientes. Usa el control correspondiente al acceso necesario:

Un perfil conectado no autoriza código automáticamente ni hereda la aprobación de repositorio de otra generación. El capítulo de permisos sigue estos límites en la implementación.

Conecta una instalación nueva

Inicia el backend y abre el repositorio previsto en el perfil previsto de VS Code. Ejecuta CodeSecurity: Get Started y revisa Workspace Trust.

En una instalación nueva sin propietario navegador, IDE activo ni autoridad del instalador consumida, el primer perfil apto puede reclamar los derechos de propietario de un solo uso. Tras conceder confianza, su panel integrado se asocia mediante el flujo admitido. Esta ruta no exige generar ni pegar un secreto IDE.

Si varios perfiles nuevos se inician a la vez, solo la solicitud apta del primer propietario puede reclamar esos derechos. Las demás quedan pendientes de revisión. Cuando ya existe un propietario, usa el siguiente flujo de aprobación en lugar de intentar recrear un estado nuevo.

Aprueba otro perfil de editor

1. En el perfil nuevo, espera Approval needed y su código corto en la barra de estado de CodeSecurity.
2. Ejecuta CodeSecurity: Connect / Review IDE Access.
3. En el navegador externo del propietario ya autenticado, abre Settings > IDE access.
4. Compara el código, el punto de acceso y el nombre reconocible del editor o espacio de trabajo con el perfil solicitante.
5. Aprueba únicamente la solicitud correspondiente.
6. Verifica que ese cliente exacto pasa a activo y que el editor aparece conectado.

La aprobación activa los permisos ya conservados para ese perfil, origen y generación. No emite una clave API de uso general. El perfil vuelve a conectarse tras reinicios del editor y del backend mientras esos permisos sigan siendo válidos.

Usa Refresh IDE access si el estado es incierto. Reject o Cancel afecta a la solicitud pendiente correspondiente; Revoke, al miembro activo previsto. Una solicitud antigua no puede eliminar una generación de reemplazo creada simultáneamente.

Abre o añade un navegador

Cuando el acceso IDE está activo en un espacio de confianza, la extensión intenta inscribir su panel integrado. Las aperturas posteriores con Open Dashboard reutilizan la pertenencia confirmada del navegador.

Restricted Mode y el almacenamiento explícitamente efímero del navegador integrado impiden una asociación duradera. La extensión explica el cambio necesario sin modificar silenciosamente el navegador. La pertenencia del IDE y sus hallazgos nativos son distintos de la cookie y la pertenencia del navegador integrado.

Para añadir otro navegador, ejecuta CodeSecurity: Add Browser to Lomo CodeSecurity. La opción recomendada copia un código de asociación de un solo uso y diez minutos para un perfil local no asociado. La opción del navegador del sistema también exige un perfil no asociado. La invitación no sustituye un navegador ya asociado.

Mantén los valores de asociación fuera de incidencias, capturas, archivos de código y ajustes del editor. No copies los archivos de permisos de un perfil a otro.

Recupera un navegador propietario

Si no queda una sesión utilizable del propietario, sigue el flujo fijado de recuperación del navegador. make auth-info es el punto de entrada mantenido para inicio y recuperación solo del navegador desde la copia del producto. No se necesita para aprobar perfiles mientras un propietario sigue autenticado.

Trata su valor de un solo uso como una credencial. Usa la página local de asociación y evita registrarlo en transcripciones de terminal o registros compartidos. Si se expuso o consumió, sigue los pasos explícitos de restablecimiento del flujo; no restablezcas todos los clientes como primera respuesta a una cookie ausente.

Distingue una lectura fallida de una lista vacía

Settings muestra carga hasta la primera lectura correcta de miembros. No paired IDE clients significa un resultado vacío obtenido correctamente. Un fallo significa que no se pudieron cargar los miembros.

Un fallo posterior conserva los clientes cargados y comunica el error. Solicitudes pendientes y clientes activos pueden fallar por separado: una actualización correcta de clientes activos puede coexistir con un error explícito de solicitudes pendientes. Contrasta ambos antes de decidir sobre el acceso.

Repara solo el registro afectado

La corrupción local de permisos y una fila corrupta de pertenencia en el servidor tienen recuperaciones diferentes. La reparación local de la extensión confirma los archivos exactos del perfil cuya corrupción se ha probado y que no han cambiado. Remove invalid record en Settings apunta a la fila inválida exacta del servidor. Ninguna sustituye a la otra ni restablece silenciosamente la instalación.

Cambiar lomoCodeSecurity.apiBaseUrl exige conectarse de nuevo al origen previsto. Otro puerto es otro origen. Conserva la instalación y el perfil anteriores al resolver la discrepancia; usa recuperación si el destino o la identidad del miembro no están claros.

Lee el protocolo para el cliente adecuado

Las sesiones de navegador usan una cookie HttpOnly y SameSite. Las modificaciones también exigen el Origin exacto de control y un X-CSRF-Token ligado a la sesión. Las capacidades IDE usan una lista limitada de rutas y comprobaciones de propietario específicas de cada ruta. Poder crear proyectos no implica poder leerlos sin restricciones.

Las credenciales no deben ir en parámetros de consulta de URL. Este sitio no retransmite solicitudes del producto ni recoge valores de asociación. La referencia de autenticación y las operaciones IDE sobre código documentan los contratos del cliente correspondiente.