Une seconde barrière — exercice corrigé de Spring Boot : écrire le serveur (école d'ingénieur) (chapitre 8)

Une seconde barrière

Sécuriser l'application · niveau 2

Énoncé

Les règles portent sur les adresses. Ajouter une protection sur le service lui-même : seul un administrateur peut appeler LivreService.supprimer, d'où qu'on l'appelle. Que se passe-t-il si une comptable l'appelle directement, sans passer par HTTP ?

Corrigé

On active la sécurité des méthodes sur la configuration (@EnableMethodSecurity), puis on annote la méthode :


    @PreAuthorize("hasRole('ADMIN')")     // exercice 8.2 : une seconde barrière, sur le service
    public void supprimer(String isbn) {
        depot.delete(charger(isbn));
    }

Spring entoure alors le service d'un proxy, comme pour @Transactional, qui vérifie l'expression avant l'appel. Une comptable qui l'appelle directement reçoit une AuthorizationDeniedException (« Access Denied »), que la couche web traduirait en 403 :


    // Exercice 8.2 : la règle sur la méthode s'applique même sans passer par HTTP
    @Test
    @WithMockUser(roles = "COMPTABLE")
    void ex2_preAuthorize() {
        assertThatThrownBy(() -> livres.supprimer("9782956300045"))
                .isInstanceOf(AuthorizationDeniedException.class)
                .hasMessage("Access Denied");
    }

Les deux barrières se complètent : une nouvelle adresse qui appellerait supprimer serait protégée, même si l'on oubliait sa règle.