Secrets de cliente hasheados
Generado automáticamente desde el archivo fuente. No editar a mano — vuelve a ejecutar
catalyst-changelog-sync.
Qué cambió
Sección titulada «Qué cambió»- Breaking:
OAuthApplication.secretse persiste ahora como hash bcrypt y se enmascara aundefineden toda ruta de lectura; la autenticación de cliente verifica elclient_secretpresentado conbcrypt.compareen todos los grants (password, authorization_code, refresh_token). - Breaking: los ficheros
environment*.tsdel frontend deben llevar el secret en claro enoAuth.applicationSecret— el antiguo literal con el hash precomputado ya no autentica. - El seeder de arranque siembra ahora un valor en claro que se hashea al escribir, reconcilia el drift con
bcrypt.comparepara que los reinicios nunca hagan doble hash, y repara en el arranque un secret de bootstrap heredado sin hashear.
Por qué importa
Sección titulada «Por qué importa»Los secrets se guardaban como el valor literal enviado por el cliente, así que cualquier lectura de la base de datos, listado de administración o volcado de backup exponía todos los client_secret usables de la plataforma. La ruta de migración: actualiza los environments del frontend al secret en claro y, para las apps satélite provisionadas antes de este cambio, sigue la estrategia documentada de re-registro / detect-and-hash — de lo contrario sus logins fallarán la comparación bcrypt. El paquete de credenciales de un solo uso sigue devolviendo el valor en claro; solo cambia la representación en reposo.