test(rbac): prove hardened agent is blocked on destructive ops (CRM-182) - #282
Conversation
Negative proof the card required. Grants exactly the attendance set the default
agent holds AFTER CRM-182 and asserts, through the full request stack:
- 403 on conversations#destroy, contacts#destroy, pipeline_stages#destroy and
teams#create (revoked keys), with the target record left intact / uncreated;
- 200 on conversations#toggle_status and teams#index (kept keys).
A refactor that re-maps any of these controllers to a key the agent still holds
(or drops the gate) turns an example red. Complements the evo-auth seed/migration
change, which stops granting the keys in the first place.
Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
Reviewer's GuideAdds a new request spec to assert that the hardened default agent role is forbidden from destructive/admin CRM endpoints while still allowed on specific attendance-related actions, without changing production code. File-Level Changes
Tips and commandsInteracting with Sourcery
Customizing Your ExperienceAccess your dashboard to:
Getting Help
|
There was a problem hiding this comment.
Hey - I've left some high level feedback:
- The AGENT_KEYS set is hard-coded in this spec; consider centralizing this permission set in a shared helper or referencing the real role definition so the test doesn’t silently drift from production behavior over time.
- The use of allow_any_instance_of on Api::BaseController and EvoAuthService tightly couples the spec to internals; if possible, replace this with a shared authentication/authorization test helper or dependency injection to keep the test setup more robust to refactors.
Prompt for AI Agents
Please address the comments from this code review:
## Overall Comments
- The AGENT_KEYS set is hard-coded in this spec; consider centralizing this permission set in a shared helper or referencing the real role definition so the test doesn’t silently drift from production behavior over time.
- The use of allow_any_instance_of on Api::BaseController and EvoAuthService tightly couples the spec to internals; if possible, replace this with a shared authentication/authorization test helper or dependency injection to keep the test setup more robust to refactors.Help me be more useful! Please click 👍 or 👎 on each comment and I'll use the feedback to improve your reviews.
|
ℹ️ Independente. O request spec stubba a permissão (não lê o seed do auth), então passa standalone na develop — sem ordem obrigatória. Ordem geral da leva (desmembramento do antigo PR #84): Os 4 PRs do auth tocam os mesmos arquivos ( Par de deploy: #85 (auth, a chave Independentes (sem ordem): #281 (CRM-181 comentário), #282 (CRM-182 spec), #283 (CRM-190 spec), #310 (CRM-178 front). 🤖 Generated with Claude Code |
CRM-182 (lado CRM) — prova negativa que faltava
Achado 🔴 CRITICAL da review do Guilherme: o card é de segurança e não havia teste provando a propriedade de segurança no CRM (o PR do auth só prova que uma string saiu de um array).
Request spec pelo stack completo, concedendo exatamente o set que o
agentmantém após o CRM-182:conversations#destroy,contacts#destroy,pipeline_stages#destroy,teams#create(com o registro-alvo intacto / não criado);conversations#toggle_statuseteams#index.Um refactor que re-mapeie qualquer desses controllers para uma chave que o agent ainda tem (ou remova o gate) fica vermelho. Modelado sobre
partial_actions_rbac_spec.rb/contact_destructive_ops_rbac_spec.rb.6 examples, 0 failures (rodado localmente contra Postgres + Redis). Sem mudança de código de produção — os gates já existem na develop.
🤖 Generated with Claude Code
Summary by Sourcery
Tests: