Chaves

O FortressFlag tem dois tipos de chave, e eles são opostos de propósito. Saber qual é qual — e tratar cada um de acordo — é quase tudo o que há para saber.

Chaves de cliente: `ffc_` — públicas por design

Uma chave de cliente autentica o client plane: os seus apps iOS, Android e web. Ela viaja dentro de toda cópia do seu app, e qualquer pessoa com o seu binário ou o código-fonte da sua página consegue lê-la. O design assume isso. Uma chave de cliente:

é somente leitura, com escopo de um projeto e um ambiente
só consegue buscar os valores avaliados de um único dispositivo — nunca as suas regras, nunca os dados de outro dispositivo, nunca nada da API de gerenciamento
tem limite de taxa por chave e por dispositivo

Então coloque-a na configuração do seu app com a consciência tranquila. O que alguém aprende ao ter a sua chave de cliente são as chaves das suas flags em um ambiente — que essa pessoa já podia ler no binário de onde a chave veio. O prefixo ffc_ existe para que scanners de segredos a reconheçam como chave de cliente e não acordem ninguém.

Chaves de servidor: `ffs_` — um segredo de verdade

Uma chave de servidor autentica o server plane: o seu próprio backend baixando o ruleset completo — regras de segmentação incluídas — para avaliação local. Trate-a exatamente como uma senha de banco de dados:

guarde-a em um gerenciador de segredos ou em uma variável de ambiente
nunca em código client-side, nunca em um repositório, nunca em um log
o prefixo ffs_ está ali para que um scanner de vazamentos a classifique como um segredo de verdade que deve acordar alguém — exatamente o oposto de ffc_, e é por isso que as duas não compartilham prefixo

Uma chave de servidor também tem escopo de um projeto e um ambiente, é somente leitura e não alcança a API de gerenciamento. Mas o seu raio de dano em um vazamento são as suas regras de segmentação, não só as chaves das suas flags — daí o tratamento diferente.

Criar, revelar uma vez, revogar

As chaves são gerenciadas na tela Chaves de SDK de cada projeto (Admins e Owners criam e revogam; Developers podem ver a lista):

Criar gera uma chave vinculada a um projeto + ambiente. A chave completa é revelada exatamente uma vez, no momento da criação — copie-a nessa hora, porque depois a lista mostra só o suficiente para identificá-la. Não existe “mostrar a chave de novo”: uma chave que pode ser reexibida é uma chave armazenada em uma forma que pode ser roubada.
Revogar entra em vigor no próximo uso da chave — sem release do app, sem deploy. E é seguro fazer sob pressão: SDKs com uma chave revogada recorrem ao seu cache em vez de quebrar.

Rotação

Várias chaves ativas por ambiente são permitidas, e essa é a receita de rotação: crie a chave nova, distribua-a para os seus apps ou servidores, e então revogue a antiga. Sem downtime, sem lacuna no serviço das flags, e a janela em que as duas chaves funcionam é você quem controla.

Para onde ir agora

Como as flags chegam ao seu app — os dois planes que essas chaves destravam
Ambientes e projetos — o escopo ao qual uma chave está vinculada
Papéis e segurança — quem pode criar e revogar