Repository navigation
Consolidate duplicated per-resource authorization checks across controllers #48
Description
Summary
The pattern "admin bypasses, everyone else must match a scope id on the target record, otherwise 403" is now copy-pasted across at least three controllers:
JudgeController::authorizeRunAccess()StaffController::authorizeTaskAccess()SiteController::authorizeSiteAccess()(added in Site coordinator role (issue #18, PR 2/2) #41)
Each is a private method with the same three-line shape (if ($user->isAdmin()) return; / compare an id / abort(403, ...)), just against a different scope column (contest_id, contest_id, site_id).
Inspiration
cd-moj/cdmoj generalizes an equivalent need (staff/print scoped by region) as one shared, reusable scope-filter concept applied across multiple resource types, rather than one bespoke check per controller.
Why this matters
This was explicitly flagged (and left as documented follow-up debt, not fixed) during code review of #41 -- see PR #41's review comment. A future change to the authorization semantics (e.g. logging denied attempts, or narrowing the admin bypass) has to be applied in three places today and will likely drift.
Suggested scope
A shared trait or base-controller helper, e.g.:
protected function authorizeScopedAccess(Model $resource, string $column, string $resourceLabel): void
{
if (auth()->user()->isAdmin()) return;
if (auth()->user()->{$column} !== $resource->{$column}) {
abort(403, "Voce nao pode gerenciar {$resourceLabel} de outro escopo.");
}
}...and refactor the three existing call sites to use it. Small, low-risk, mechanical refactor -- no behavior change if done correctly, so it should ship with the existing access-scoping tests re-run unchanged (JudgeControllerTest, tests/Feature/SiteControllerTest.php, etc.) as the safety net.
Activity
matbrgz commentedon Sep 11, 2026
Vou assumir o frontend e a especificação de integração desta issue, conforme solicitado pelo mantenedor, na worktree isolada
feat/issue-frontends-specs, baseada emmasterapós o PR #35.Especificação da consolidação de autorização e contrato uniforme de acesso negado para as novas interfaces. Sem mudança de regra: preservar o escopo de concurso/local e o bypass atual de admin; incluir matriz de regressão dos controladores existentes. Não vou alterar os helpers/controladores que pertencem ao backend.
Antes da implementação, registro a divisão: minhas mudanças serão interfaces, rotas GET de apresentação, testes de frontend e specs em
docs/specs/. Models, migrations, jobs, regras de domínio e endpoints de dados/mutação ficam com o time de backend. As interfaces só habilitarão ações quando o contrato real estiver disponível; haverá estado de indisponibilidade, sem confirmação fictícia de sucesso.Critérios de aceite do frontend: navegação por teclado, labels visíveis, feedback de processamento/erro, cores sem significado exclusivo, layout responsivo e testes dos fluxos principais. Vou vincular o PR e os contratos finais aqui; esta entrega não encerra a implementação de backend da issue.
Merge pull request #57 from UnitedOpen-Source/refactor/issue-48-share…
matbrgz commentedon Sep 11, 2026
Entrega publicada no PR #70: #70
Spec desta issue · Índice dos contratos
A extração já integrada pelo backend foi preservada; a spec registra regressões e distingue hardening adicional de comportamento existente.
Validação da branch: 604 testes PHP (3248 assertions), 26 testes de frontend e build aprovados. Fluxos Vue foram testados com contratos de teste; integração funcional exige endpoints reais. Revisão visual de biblioteca/enunciado feita no navegador, incluindo 375 px; telas administrativas tiveram revisão de código/componentes, com conferência visual limitada por bloqueio de outra extensão no Chrome.
As responsabilidades e critérios de aceite estão na spec. Este PR não encerra o trabalho pendente do backend.