hotfix: Browser-verify that Fase 7's Tasks 7.1 (order-service interna……l purchase check) and 7.2 (product-service reviews)

[edsonwade]

Resultados dos testes no browser

Testei os dois contratos diretamente no browser (navegação + fetch via javascript_tool, sem Postman/curl), usando dados reais: registei um cliente novo (f7.tester@example.com, userId 21), completei uma compra real (produto 251, "4K Monitor 1", $399.99) e acompanhei a saga até CONFIRMED (Inventory Reserved → Order Confirmed), para ter uma compra verificável genuína — não havia nenhuma order CONFIRMED/SHIPPED/DELIVERED em BD antes deste teste.

Task 7.1 — order-service internal purchase check

Cenário	Chamada	Resultado
Sem X-Internal-Token, direto a :8083	GET /internal/purchases/exists	401 order.internal.token.invalid ✅
Com token interno válido, compra real (21/251)	idem	200 {"purchased":true} ✅
Com token interno válido, produto nunca comprado (21/1)	idem	200 {"purchased":false} ✅
Via gateway :8222, sem JWT	idem	401 gateway.auth.missing.token ✅ (Layer 1 bloqueia anónimos)
Via gateway :8222, com JWT válido de qualquer utilizador autenticado	idem	401 order.internal.token.invalid — pedido chegou ao order-service

Achado a registar: o gateway tem Path=/api/v1/orders/** como predicate (linha 161 de gateway-service.yml), que também casa com /internal/**. Um utilizador autenticado (não só o product-service) consegue fazer o pedido chegar ao order-service através do gateway — só não obtém dados porque a Layer 2 (X-Internal-Token) o rejeita. Isto não é um bug: os comentários no próprio código (OrderSecurityConfig.java, InternalTokenFilter.java) já dizem explicitamente "an anonymous external caller is stopped at the gateway" — só anónimos, não autenticados. Mas a frase mais informal da tarefa ("gateway não expõe /internal") é mais forte do que o comportamento real; deixo isto explícito para não gerar falsa confiança.

Task 7.2 — product-service reviews (via gateway :8222, rota pública)

Cenário	Resultado
GET reviews (público, sem auth)	200 página vazia ✅
POST sem auth	401 ✅
POST autenticado, compra verificada (21/251)	201, corpo com customerId, productId, rating, comment corretos ✅
GET reviews depois do POST	review aparece ✅
POST duplicado (mesmo cliente/produto)	409 review.already.exists ✅
POST para produto nunca comprado (21/1)	403 review.not.purchased — prova a chamada Feign real product-service→order-service ✅
GET reviews produto inexistente (999999)	404 product.not.found ✅
GET reviews produto SUSPENDED (6652)	404 product.not.found (indistinguível de not-found, D4) ✅
DELETE como autor (review 1)	204, some da lista ✅
DELETE repetido (já apagada)	404 review.not.found ✅
DELETE por outro cliente (customer 22 → review 2 do 21)	403 review.delete.forbidden ✅
DELETE como autor real (cleanup review 2)	204 ✅

Não testado: o caminho 503 (review.verification.unavailable) — exigiria derrubar o order-service, o que não fiz por ser ação destrutiva fora do pedido.

Estado final: reviews voltaram a 0 para o produto 251 (limpeza feita); ficaram 2 contas de cliente novas e 1 order CONFIRMED reais em BD, criadas propositadamente para servir de prova de compra verificada.