Principais pontos
- Autorize e valide o usuário que faz o upload antes de criar uma Assembly; um processamento de imagem bem-sucedido não é uma aprovação de moderação.
- Remova os metadados incorporados do derivado de entrega, preservando qualquer evidência de origem necessária sob uma política de retenção separada.
- Use um caminho exclusivo com asset_id e assembly.id para que novas tentativas não possam sobrescrever imagens revisadas; combine-o com uma verificação de deduplicação na aplicação.
Um pipeline de imagens geradas por usuários precisa de mais do que armazenamento de objetos barato. A aplicação precisa saber qual upload foi aceito, qual política de derivados foi executada, onde o resultado fica e se ele pode ser entregue. Caminhos sem colisão no Backblaze e uma chave de aplicativo restrita mantêm as novas tentativas de armazenamento separadas da moderação e do estado do produto.
O que mais importa
- Restrinja a chave de aplicativo padrão do B2 ao bucket de destino e a um prefixo de saída estável, como community/web-v1/, que cubra todos os caminhos gerados pelo Template.
- Use cabeçalhos X-Bz-Info-* para rótulos estáveis do fluxo de trabalho, não para dados privados de usuários nem para nomes de arquivos arbitrários sem codificação.
- Sirva ou autorize o objeto finalizado pela camada de entrega da aplicação, em vez de tratar a URL do resultado do armazenamento como o modelo de permissões do produto.
Separe os estados de moderação e de processamento
Uma imagem válida não é necessariamente um conteúdo que o produto deve expor. Registre o autor do upload, o tenant, o checksum da origem, o estado de moderação e a operação de processamento antes de iniciar a Assembly. O fluxo de trabalho de imagem pode normalizar pixels e remover metadados incorporados, mas a aplicação precisa decidir se o tema retratado, a titularidade e o contexto atendem à sua política.
Mantenha distintos estados como upload concluído, em processamento, revisão necessária, aprovado, rejeitado e exportação com falha. Não marque o conteúdo como aprovado só porque /image/resize e /backblaze/store foram concluídos com sucesso, e não transforme um erro de processamento em uma rejeição de moderação. Cada estado precisa de seu próprio comportamento de nova tentativa, revisão e retenção.
Crie o Template de imagem versionado do Backblaze
O Template aceita um único upload limitado, cria um derivado WebP que cabe nas dimensões escolhidas, remove os metadados incorporados da imagem e exporta apenas esse derivado. Como zoom é false, uma origem menor continua menor. O caminho de destino contém um rótulo de versão e assembly.id, de modo que cada Assembly gera um caminho sem colisões em vez de sobrescrever uma imagem já revisada.
A aplicação fornece um asset_id validado, mas não escolhe credencial, bucket, prefixo arbitrário nem parâmetros de Robot. Mantenha allow_steps_override como false e use os limites de auth do Template como fronteira final de carga de trabalho. Preserve um original separadamente quando contestações, reprocessamento ou exigências legais precisarem de evidência da origem; strip afeta o derivado, não um acervo externo de mídias originais.
{
"allow_steps_override": false,
"auth": {
"max_number_of_files": 1,
"max_size": 26214400
},
"steps": {
":original": {
"robot": "/upload/handle"
},
"community_webp": {
"use": ":original",
"robot": "/image/resize",
"width": 2048,
"height": 2048,
"resize_strategy": "fit",
"zoom": false,
"format": "webp",
"quality": 80,
"strip": true
},
"backblaze_versioned": {
"use": "community_webp",
"robot": "/backblaze/store",
"credentials": "backblaze-community-images",
"path": "community/web-v1/${fields.asset_id}/${assembly.id}/${file.url_name}",
"headers": {
"X-Bz-Info-workflow": "community-web-v1"
},
"result": true
}
}
}Restrinja a chave de aplicativo do Backblaze
Crie uma chave de aplicativo padrão em vez de usar a chave mestra. Restrinja-a ao bucket de destino e a um prefixo de saída estável, como community/web-v1/, que cubra todos os caminhos gerados pelo Template. A documentação do Robot de armazenamento do Backblaze exige listBuckets, writeFiles e listFiles para que o Robot possa resolver o bucket e fazer o upload do objeto.
Uma restrição de prefixo e caminhos de destino exclusivos reduzem o impacto se a credencial for exposta, mas não autorizam um usuário da aplicação nem moderam conteúdo. Armazene o bucket, o ID da chave de aplicativo e a chave de aplicativo em Credenciais de Template nomeadas. Faça a rotação ou a revogação dessa credencial independentemente das sessões de login da aplicação e teste a substituta antes de remover a chave antiga.
Fronteira do bucket
A chave não pode operar em buckets não relacionados.
Fronteira do prefixo
A chave fica limitada a objetos sob o namespace dos derivados.
Fronteira da aplicação
O produto ainda decide qual tenant e qual ativo podem invocar o Template.
Use caminhos e informações de arquivo de forma deliberada
Os nomes de objetos do Backblaze B2 formam um namespace plano, mesmo quando ferramentas apresentam prefixos separados por barras como pastas. Use esses prefixos para organização e restrição de chaves, não como prova de que diretórios pai existem. Inclua no caminho uma versão do fluxo de trabalho e um identificador de aplicação limitado, e use assembly.id para evitar colisões de nomes.
O Robot /backblaze/store aceita cabeçalhos com valores de string, incluindo informações de arquivo X-Bz-Info-*. Use rótulos estáveis, como a versão do fluxo de trabalho do derivado. Não insira dados privados de usuários, segredos nem um nome de arquivo original sem limite. O Robot rejeita um nome de arquivo gerado com mais de 1.024 bytes em UTF-8, portanto todo campo da aplicação que entra no caminho precisa de um contrato de comprimento e de caracteres.
Teste o modelo de falhas do derivado e do destino
Teste orientação, transparência, animação, perfis de cor, dimensões grandes, arquivos malformados, submissões duplicadas, chaves de aplicativo inválidas, uma chave restrita ao prefixo errado e um bucket indisponível. Inspecione aparência, formato, dimensões, bytes, remoção de metadados, caminho do objeto e informações de arquivo em vez de se contentar apenas com uma Assembly bem-sucedida.
Acompanhe as falhas por recebimento, processamento, autenticação, consulta ao bucket e upload. Um timeout incerto deve entrar em reconciliação, porque o objeto pode já existir. Verifique a Assembly original e o registro da operação antes de criar um novo caminho versionado; caso contrário, o produto pode acumular vários derivados com aparência de aprovados para uma única origem.
Mantenha as URLs de armazenamento separadas da autorização de entrega
Uma URL de resultado identifica o que o Step de armazenamento retornou; ela não é a política de tenant ou de moderação da aplicação. Mantenha o objeto indisponível para os consumidores do produto até que a aplicação o reconcilie com a operação esperada e avance o estado de moderação. Faça a entrega pela configuração de bucket e CDN escolhida para o produto, com a autorização aplicada nessa fronteira.
Retenha o bucket e o nome de objeto duráveis, a versão do fluxo de trabalho, o Assembly ID, a identidade da origem e a decisão de moderação. Exclua derivados rejeitados ou substituídos por meio de um processo de retenção separado que entenda as versões de arquivo do Backblaze e os requisitos de auditoria do produto. O Template de processamento não deve tomar essa decisão destrutiva.
Detalhes técnicos que vale a pena conhecer
- O Robot /backblaze/store exige os valores de bucket, ID da chave de aplicativo e chave de aplicativo, que podem ser fornecidos por meio de Credenciais de Template nomeadas.
- Para o Robot /backblaze/store, a chave de aplicativo precisa da permissão listBuckets para resolver o ID do bucket, além de writeFiles e listFiles.
- As chaves de aplicativo padrão do Backblaze podem ser restritas a um bucket e a um prefixo de nome de arquivo; o prefixo precisa cobrir o caminho gerado pelo Template.
- O Robot /backblaze/store aceita um caminho com Assembly Variables e um objeto headers com valores de string. Cabeçalhos X-Bz-Info-* se tornam informações de arquivo do Backblaze.
- Os nomes de objetos do Backblaze B2 são strings planas; pastas delimitadas por barras são prefixos apresentados como hierarquia por ferramentas e interfaces.
- O Robot rejeita nomes de arquivo do Backblaze gerados com mais de 1.024 bytes em UTF-8; o limite conta bytes codificados, não caracteres.
Uma abordagem prática
- 1
Defina limites de upload, estados de moderação, formato de destino, política de metadados e um prefixo de destino estável.
- 2
Crie uma chave de aplicativo do Backblaze restrita por prefixo e salve-a como Credenciais de Template nomeadas.
- 3
Processe imagens de teste representativas: de dispositivos móveis, transparentes, animadas, malformadas e com muitos metadados.
- 4
Persista a identidade do objeto no B2 antes de alterar o estado da aplicação e faça novas tentativas por operação, não por nome de arquivo.
Quando a Transloadit é útil
Use /upload/handle para um único candidato à entrada moderada, /image/resize para um WebP limitado e sem metadados e /backblaze/store para um caminho versionado exclusivo. Use uma chave de aplicativo padrão do B2 restrita ao bucket de destino e a um prefixo de saída estável, e coloque metadados estáveis do fluxo de trabalho em cabeçalhos X-Bz-Info-*.
Limite da arquitetura
A Transloadit aceita uma imagem da comunidade, cria a versão otimizada para armazenamento e a grava em um bucket do Backblaze B2. A aplicação continua responsável pela moderação, pela propriedade por tenant, pelos registros de origem duráveis, pela política do bucket, pela autorização de entrega e pela exclusão.
Perguntas frequentes
A remoção de metadados modera a imagem?
Não. Ela remove os metadados incorporados do derivado. A política de conteúdo, a propriedade e a revisão contextual continuam sendo responsabilidades da aplicação.
O fluxo de trabalho deve usar uma chave de aplicativo mestra do Backblaze?
Não. Use uma chave de aplicativo padrão restrita ao bucket de destino e a um prefixo de derivados que cubra todos os caminhos gerados, com as capacidades exigidas pelo Robot.
Caminhos separados por barras são pastas reais do B2?
Não. O B2 armazena nomes de objetos planos. As interfaces podem apresentar prefixos compartilhados como pastas, o que é útil para organização e restrição de acesso.
Os cabeçalhos X-Bz-Info podem conter dados de usuários?
Evite isso. Use rótulos operacionais limitados e não sensíveis e mantenha os dados privados de usuários ou de moderação no banco de dados da aplicação.
Por que não sobrescrever o derivado anterior?
Caminhos versionados exclusivos facilitam a reconciliação de novas tentativas, evidências de moderação, reversões e comportamento de cache. Combine-os com uma verificação de deduplicação na aplicação e, depois, exclua as versões substituídas de acordo com uma política de retenção explícita.