A resposta curta: crie uma chave para cada programa, só com as permissões de que ele precisa e com uma validade curta. Se uma chave ficar exposta, revogue-a logo na página API do My MozOut; as outras continuam a funcionar. Uma chave perdida não se recupera: revoga-se e cria-se outra.
Porque uma chave por programa
Se o site, o script de cópias e o sistema de facturação usarem a mesma chave, basta um deles ser atacado para os três ficarem expostos, e revogar a chave pára os três ao mesmo tempo. Com uma chave para cada um, sabe qual está a fazer o quê e pode cortar só a que tem problemas. Tem até 20 chaves por conta, o que chega para separar bem as coisas.
O que uma chave nunca pode fazer
Seja qual for a permissão, uma chave nunca pode criar outra chave, mudar a senha ou o e-mail da conta nem ver dados de cartões. Ou seja: quem apanhar uma chave não fica dono da conta. Mas pode fazer tudo o que essa chave permite, e é por isso que as permissões mínimas importam.
Quando uma chave deixa de funcionar
| Situação |
Resposta da API |
| A chave está em falta ou não é válida |
401 unauthorized |
| A chave foi revogada ou passou da validade |
401 unauthorized |
| Quem criou a chave já não tem acesso à conta |
401 unauthorized |
| O pedido vem de um IP que não está na lista da chave |
403 ip_not_allowed |
| A chave não tem a permissão que a operação pede |
403 insufficient_scope |
| A conta não pode usar a API neste momento |
403 forbidden |
O que fazer com cada um está em os códigos de erro da API.
Substituir uma chave sem parar o programa
Quando a validade está a chegar ao fim, ou quando quer mudar as permissões, faça a troca por esta ordem:
| 1 |
Crie a chave nova na página API, com as permissões e a validade certas.
|
|
| 2 |
Ponha-a no programa, na variável de ambiente ou no cofre de segredos onde estava a antiga.
|
|
| 3 |
Confirme que funciona com GET /v1/token: deve devolver o nome, o modo e as permissões da chave nova.
|
|
| 4 |
Revogue a chave antiga. A partir daí, qualquer pedido com ela recebe 401.
|
|
|
Chave exposta num repositório, num e-mail, numa conversa ou no código de uma página? Não espere pela troca organizada: revogue-a já e crie outra. A ordem completa dos passos está em o que fazer quando uma chave fica exposta. Lembre-se de que uma chave Sandbox também lê dados verdadeiros da conta.
|
Boas práticas
| 1 |
Guarde a chave numa variável de ambiente ou num cofre de segredos, nunca no código nem num repositório.
|
|
| 2 |
Use a lista de IPs quando o programa corre num servidor com endereço fixo.
|
|
| 3 |
Prefira validades curtas (30 ou 90 dias) e marque na agenda a data da troca.
|
|
| 4 |
Quando contactar o suporte, nunca envie a chave. Envie o X-Correlation-ID da resposta, a hora e a operação: é o que basta para encontrar o pedido.
|
|
|
As chaves criadas enquanto a API está em preparação, de qualquer modo, são revogadas quando a API abrir, e o dono da conta recebe um aviso por e-mail. Nesse dia, crie chaves novas e troque-as nos programas.
|
|
Tem uma chave a expirar, perdida ou exposta? Revogue-a e crie outra na página API do My MozOut.
Criar uma chave
|
|
VEJA TAMBÉM
Criar uma chave da API: nome, modo, permissões, validade, lista de IPs e limite de gastos
Uma chave de API ou um token ficou exposto: o que fazer, pela ordem certa
Permissões da API por área: ler ou alterar, e que permissão pede cada tarefa
Os códigos de erro da nossa API: o que quer dizer cada um, e quais vale a pena repetir
Sandbox ou Produção na API: o que faz cada chave, e como passar o programa para produção
Permissões sensíveis da API e limite de gastos: pagar, comprar, reinstalar, entrar no cPanel
|
PRODUTO RECOMENDADO Hospedagem de sites com cPanel Domínio e SSL incluídos, cópias diárias e o painel que já conhece. desde 5.940,00 Kz/mês (plano de 3 anos, com cupão) Ver planos |