Identidade, papéis e auditoria¶
Papéis¶
O sistema diferencia três fronteiras principais:
- client: consome ofertas, campanhas, cupons e recursos pessoais;
- partner: administra suas unidades/ofertas e operação associada;
- super_admin: curadoria e operação global.
A interface pode esconder ações, mas autorização real deve existir em Rules/Functions.
Propriedade do partner¶
Firestore considera partner owner quando:
Uma store é do usuário quando seu partner_id resolve para um partner que ele possui.
Super Admin¶
A autorização privilegiada usa custom claim:
O SuperAdminRoleGuard do Flutter Web é apenas UX; Functions como curateOffer, createOfferAsAdmin e gestão de schedulers verificam novamente a claim.
Autoria de oferta¶
Campos de autoria são protegidos para impedir que partner simule ação administrativa. Na criação regular, Rules exigem autor real, role partner, createdByAdmin=false, tier free e status pending_review.
Na criação por Super Admin, esses campos são calculados no servidor.
Auditoria¶
onOfferWritten observa offers/{offerId} com contexto de autenticação e chama processOfferWrite.
O audit processor:
- diferencia create/update/delete;
- produz ações específicas para criação administrativa, aprovação, rejeição e mudança de limite;
- ignora alterações puramente operacionais de contadores/trending para não gerar ruído;
- cria ID determinístico a partir do
eventId, evitando duplicação por redelivery; - resolve o ator a partir dos campos persistidos/contexto do evento;
- grava em
offers/{offerId}/audit_logs/{logId}.
As Rules bloqueiam qualquer write de cliente em audit_logs, admin_notes e deletion_context.
Referral¶
submitReferralCode impede autoindicação e múltiplas associações conflitantes. Se phone_verified já é verdadeiro, tenta aplicar o benefício imediatamente; caso contrário, o código fica salvo.
Triggers em users/{userId} cobrem:
- mudança de
phone_verifiedparatrue; - criação do usuário já verificado.
A implementação atual trabalha com benefícios/recompensas, não com um saldo genérico de créditos.
Premium e Stripe¶
Estado de assinatura é sincronizado pelo backend. stripeWebhook trata checkout, invoices e alterações/cancelamento de subscription. subscriptions e campos Premium sensíveis em users não são graváveis pelo próprio usuário segundo as Rules.
Remote Config pode decidir qual oferta visual/plano de lançamento mostrar, mas não concede Premium.