Wie die Umsetzung AuditorAware mit Spring Data JPA und Spring Security?

Verwenden wir Hibernate/JPA, Spring, Spring Data und Spring Security in unserer Anwendung. Ich habe eine standard - User Person, die abgebildet wird, die mit JPA. Weiter habe ich eine UserRepository

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

folgt der Frühling-Daten-Konvention für die Benennung von Methoden Abfragen. Ich habe eine Entität

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

Will ich mit Spring Data auditing-support. (Als descripe hier.) Daher erstellte ich eine AuditorService wie folgt:

@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;
    }
}

Wenn ich eine Methode erstellen

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

Wo alles ist richtig verkabelt und FooRepository eine Feder befindet, die Daten CrudRepository. Dann ein StackOverflowError geworfen wird, da der Aufruf findByUsername auszulösen scheint hibernate Spülen, um die Daten zur Datenbank, die Trigger AuditingEntityListener wer ruft AuditorService#getCurrentAuditor was wiederum löst einen flush und so weiter.

Wie Sie vermeiden, diese Rekursion? Gibt es eine "kanonische Weg" laden die User Entität? Oder gibt es eine Möglichkeit zu verhindern, Hibernate/JPA von der Spülung?

InformationsquelleAutor gregor | 2013-01-08

Die Lösung ist nicht zu Holen die User Datensatz in der AuditorAware Umsetzung. Dies löst die beschriebene Schleife, da eine select-Abfrage löst einen flush (dies ist der Fall, da Hibernate/JPA will schreiben der Daten in die Datenbank festschreiben der Transaktion vor der Ausführung der select), die löst ein Aufruf AuditorAware#getCurrentAuditor.

Die Lösung ist die Speicherung der User Datensatz in der UserDetails zur Verfügung gestellt Spring Security. Daher habe ich meine eigene Implementierung:

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;
    }
}

Weiter, änderte ich meine UserDetailsService zu laden User und erstellen UserAwareUserDetails. Jetzt ist es möglich, den Zugriff auf die User etwa durch die SercurityContextHolder:

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

Ich änderte meine UserDetailsService, um wieder eine UserAwareUserDetails user, aber wenn ich die getPrincipal das Objekt ist immer ein string und nicht der Benutzer.

InformationsquelleAutor gregor

9

Ich habe das gleiche Problem und was ich Tat, war ändern Sie einfach die Verteilung auf die findByUsername(username) Methode Propagation.REQUIRES_NEW ich vermutete, dass war ein problem mit den Transaktionen, so dass ich geändert, um eine neue Transaktion und die gut für mich gearbeitet. Ich hoffe, dass dies helfen kann.
```
@Repository
public interface UserRepository extends JpaRepository<User, String> {

    @Transactional(propagation = Propagation.REQUIRES_NEW)
    List<User> findByUsername(String username);
}
```
- Vielen Dank! Perfekte Lösung
InformationsquelleAutor Anand Shah
3

Sieht es aus wie Sie eine benutzerdefinierte Entität für zwei verschiedene Dinge:
- Authentifizierung
- audit
Ich denke, es wird besser sein, um ein spezielles AuditableUser für audit-Zwecke (es werden identische Feld username original-Benutzer).
Betrachten Sie folgenden Fall: Sie löschen möchten einige Benutzer aus der Datenbank. Wenn alle Ihre Objekte überwachen verknüpft sind-Benutzer sind, dann werden Sie a) lose Autor b) kann gelöscht werden, indem Sie die Kaskade zu (hängt davon ab, wie die Verknüpfung implementiert ist). Nicht sicher, dass Sie es wollen.
So werden durch die Verwendung spezieller AuditableUser haben Sie:
- keine Rekursion
- Fähigkeit, löschen Sie einige Benutzer aus dem system und erhalten Sie alle audit-Informationen
- warum einen Benutzer löschen, eh? warum nicht mark wie gelöscht oder sth.
InformationsquelleAutor Maksym Demidas

Um ehrlich zu sein, Sie nicht wirklich erfordern, dass man einem anderen Unternehmen.
Zum Beispiel, ich hatte ähnliches problem und habe es behoben in folgender Weise:

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"));
        }
    }
}

Wo SUser ist sowohl die Klasse, die ich benutze für die überwachung als auch für die Sicherheit.
Vielleicht hatte ich verschiedene use-case als Deins und mein Ansatz nach gelöscht werden, aber es kann geklärt werden wie diese.

InformationsquelleAutor kornicameister

Schreibe einen Kommentar

Du musst angemeldet sein, um einen Kommentar abzugeben.