Comment mettre en œuvre AuditorAware avec Spring Data JPA et de la Sécurité Printemps?

Nous utiliser Hibernate/JPA, le printemps, le Printemps des Données et de la Sécurité Printemps dans notre application. J'ai une User entité qui est mappé à l'aide de JPA. De plus, j'ai un UserRepository

public interface UserRepository extends CrudRepository<User, Long> {
    List<User> findByUsername(String username);
}

qui suit le Printemps de Données de la convention pour nommer les méthodes de requête. J'ai une entité

@Entity
public class Foo extends AbstractAuditable<User, Long> {
    private String name;
}

Je veux utiliser de Printemps de l'audit des Données de soutien. (Comme descripe ici.) J'ai donc créé un AuditorService comme suit:

@Service
public class AuditorService implements AuditorAware<User> {

    private UserRepository userRepository;

    @Override
    public User getCurrentAuditor() {
        String username = SecurityContextHolder.getContext().getAuthentication().getName();
        List<User> users = userRepository.findByUsername(username);
        if (users.size() > 0) {
            return users.get(0);
        } else {
            throw new IllegalArgumentException();
        }
    }

    @Autowired
    public void setUserService(UserService userService) {
        this.userService = userService;
    }
}

Lorsque je crée une méthode

@Transactional
public void createFoo() {
    Foo bar = new Foo(); 
    fooRepository.save(foo);
}

Où tout est correctement câblé et FooRepository une source de Données CrudRepository. Puis un StackOverflowError est jeté depuis l'appel à findByUsername semble déclencher d'hibernation pour purger les données de la base de données qui déclenche AuditingEntityListener qui appelle AuditorService#getCurrentAuditor qui déclenche une nouvelle fois une couleur, et ainsi de suite.

Comment éviter cette récursivité? Est-il une "manière canonique" pour charger le User entité? Ou est-il un moyen pour empêcher Hibernate/JPA, la purge?

InformationsquelleAutor gregor | 2013-01-08

La solution est de ne pas récupérer les User enregistrement dans le AuditorAware mise en œuvre. Cela déclenche le décrit en boucle, depuis une requête select déclenche une chasse d'eau (c'est le cas depuis Hibernate/JPA, veut écrire les données dans la base de données pour valider la transaction avant l'exécution de la sélection), ce qui déclenche un appel à AuditorAware#getCurrentAuditor.

La solution est de stocker les User enregistrement dans le UserDetails prévue pour le Printemps de Sécurité. J'ai donc créé ma propre mise en œuvre:

public class UserAwareUserDetails implements UserDetails {

    private final User user;
    private final Collection<? extends GrantedAuthority> grantedAuthorities;

    public UserAwareUserDetails(User user) {
        this(user, new ArrayList<GrantedAuthority>());
    }

    public UserAwareUserDetails(User user, Collection<? extends GrantedAuthority> grantedAuthorities) {
        this.user = user;
        this.grantedAuthorities = grantedAuthorities;
    }

    @Override
    public Collection<? extends GrantedAuthority> getAuthorities() {
        return grantedAuthorities;
    }

    @Override
    public String getPassword() {
        return user.getSaltedPassword();
    }

    @Override
    public String getUsername() {
        return user.getUsername();
    }

    @Override
    public boolean isAccountNonExpired() {
        return true;
    }

    @Override
    public boolean isAccountNonLocked() {
        return true;
    }

    @Override
    public boolean isCredentialsNonExpired() {
        return true;
    }

    @Override
    public boolean isEnabled() {
        return true;
    }

    public User getUser() {
        return user;
    }
}

De plus, j'ai changé mon UserDetailsService pour charger le User et de créer UserAwareUserDetails. Maintenant, il est possible d'accéder à la User exemple par le biais de la SercurityContextHolder:

@Override
public User getCurrentAuditor() {
    return ((UserAwareUserDetails) SecurityContextHolder.getContext().getAuthentication().getPrincipal()).getUser();
}

J'ai changé mon UserDetailsService retour d'un UserAwareUserDetails utilisateur, mais quand je fais la getPrincipal l'objet est toujours une chaîne de caractères et non pas à l'utilisateur.
ce que @gregor entend par User n'était pas de cet utilisateur org.springframework.security.core.userdetails.User mais la User créé pour être enregistré dans la base de données. Alors que db-User est celui que vous devez enregistrer dans votre UserAwareUserDetails.

InformationsquelleAutor gregor

11

J'ai eu le même problème et ce que j'ai fait était juste changer la propagation sur la findByUsername(username) méthode pour Propagation.REQUIRES_NEW, je me doutais que c'était un problème avec les transactions, donc j'ai changé pour une nouvelle transaction et qui a bien fonctionné pour moi. J'espère que cela peut vous aider.
```
@Repository
public interface UserRepository extends JpaRepository<User, String> {

    @Transactional(propagation = Propagation.REQUIRES_NEW)
    List<User> findByUsername(String username);
}
```
- Merci beaucoup! Solution parfaite
- bonne solution, mais ne devrais pas cette @Transactional être sur le niveau de Service? Il en fait ma question, juste une remarque à propos de la place 🙂 je l'ai placé sur le service et cela a fonctionné...
InformationsquelleAutor Anand Shah
3

Il semble que vous utilisez une entité Utilisateur pour deux choses différentes:
- authentification
- vérification
Je pense que ce sera mieux pour préparer un spécial AuditableUser à des fins d'audit (il va avoir le même nom d'utilisateur que l'Utilisateur d'origine).
Considérons le cas suivant: vous voulez supprimer un Utilisateur de la base de données. Si tous vos audit, les objets sont liés à l'Utilisateur alors qu'ils seront un) lâche auteur b) peut être supprimé par la cascade de trop (dépend de la façon dont le lien est mis en œuvre). Pas sûr que vous le souhaitez.
Donc, en utilisant des AuditableUser, vous aurez:
- pas de récursivité
- capacité à supprimer certains l'Utilisateur du système et de préserver l'ensemble de la vérification de l'info à ce sujet
- pourquoi supprimer un utilisateur de toute façon? pourquoi ne pas marquer comme étant supprimés ou qqch.
InformationsquelleAutor Maksym Demidas

Pour être honnête, Vous n'avez pas réellement besoin l'un de l'autre entité.
Par exemple, j'ai eu le même problème et je l'ai résolu de la manière suivante:

public class SpringSecurityAuditorAware implements AuditorAware<SUser>, ApplicationListener<ContextRefreshedEvent> {
    private static final Logger LOGGER = getLogger(SpringSecurityAuditorAware.class);
    @Autowired
    SUserRepository repository;
    private SUser systemUser;

    @Override
    public SUser getCurrentAuditor() {
        final Authentication authentication = SecurityContextHolder.getContext().getAuthentication();
        SUser principal;
        if (authentication == null || !authentication.isAuthenticated()) {
            principal = systemUser;
        } else {
            principal = (SUser) authentication.getPrincipal();
        }
        LOGGER.info(String.format("Current auditor is >>> %s", principal));
        return principal;
    }

    @Override
    public void onApplicationEvent(final ContextRefreshedEvent event) {
        if (this.systemUser == null) {
            LOGGER.info("%s >>> loading system user");
            systemUser = this.repository.findOne(QSUser.sUser.credentials.login.eq("SYSTEM"));
        }
    }
}

Où SUser est à la fois la classe que j'utilise pour l'audit ainsi que pour la sécurité.
J'avais peut-être différents cas d'utilisation que le Vôtre et mon approche sera supprimé après, mais il peut être résolu comme ça.

InformationsquelleAutor kornicameister

Vous devez vous connecter pour publier un commentaire.