Claves

FortressFlag tiene dos tipos de claves, y son opuestas a propósito. Saber cuál es cuál — y tratar cada una en consecuencia — es casi todo lo que hay que saber.

Claves de cliente: `ffc_` — públicas por diseño

Una clave de cliente autentica el plano de cliente: tus apps de iOS, Android y web. Viaja dentro de cada copia de tu app, y cualquiera con tu binario o el código fuente de tu página puede leerla. El diseño da eso por hecho. Una clave de cliente:

es de solo lectura, limitada a un proyecto y un entorno
solo puede obtener los valores evaluados de un único dispositivo — nunca tus reglas, nunca los datos de otro dispositivo, nunca nada de la API de gestión
tiene límite de peticiones por clave y por dispositivo

Así que ponla en la configuración de tu app con la conciencia tranquila. Lo que alguien aprende al tener tu clave de cliente son tus claves de flags de un entorno — que ya podía leer del binario en el que venía la clave. El prefijo ffc_ existe para que los escáneres de secretos puedan reconocerla como clave de cliente y no despertar a nadie.

Claves de servidor: `ffs_` — un secreto de verdad

Una clave de servidor autentica el plano de servidor: tu propio backend descargando el ruleset completo — reglas de targeting incluidas — para evaluarlo localmente. Trátala exactamente como una contraseña de base de datos:

guárdala en un gestor de secretos o en una variable de entorno
nunca en código del lado del cliente, nunca en un repositorio, nunca en un log
el prefijo ffs_ está ahí para que un escáner de filtraciones la clasifique como un secreto real que debe despertar a alguien — exactamente lo contrario de ffc_, y por eso las dos no comparten prefijo

Una clave de servidor también está limitada a un proyecto y un entorno, es de solo lectura y no puede alcanzar la API de gestión. Pero su radio de daño en una filtración son tus reglas de targeting, no solo tus claves de flags — de ahí el trato distinto.

Emitir, mostrar una sola vez, revocar

Las claves se gestionan desde la pantalla Claves SDK de cada proyecto (los Admins y los Owners emiten y revocan; los Developers pueden ver la lista):

Emitir crea una clave vinculada a un proyecto + entorno. La clave completa se muestra exactamente una vez, en el momento de emitirla — cópiala entonces, porque después la lista muestra solo lo suficiente para identificarla. No hay «mostrar la clave otra vez»: una clave que se puede volver a mostrar es una clave guardada en una forma que se puede robar.
Revocar surte efecto en el siguiente uso de la clave — sin lanzar una versión de la app, sin desplegar. Y es seguro hacerlo bajo presión: los SDK con una clave revocada recurren a su caché en lugar de romperse.

Rotación

Varias claves activas por entorno son legales, y esa es la receta de la rotación: emite la clave nueva, despliégala en tus apps o servidores, y después revoca la antigua. Sin tiempo de inactividad, sin huecos en el servicio de flags, y la ventana en la que funcionan ambas claves la controlas tú.

¿Por dónde seguir?

Cómo llegan los flags a tu app — los dos planos que estas claves desbloquean
Entornos y proyectos — el ámbito al que está vinculada una clave
Roles y seguridad — quién puede emitir y revocar