2016-11-28 3 views
3

Angenommen, ich habe zwei Entitäten wie folgt:Stellen Sie sicher, authentifizierte Benutzer können nur ihre eigenen Datensatz aktualisieren

@Entity 
public class ClassA { 
    private Long id; 

    public Long getId() { 
     return id; 
    } 

    public void setId(Long id) { 
     this.id = id; 
    } 

    @OneToMany 
    private Set<ClassB> classBs = new HashSet<>(); 
} 
@Entity 
public class ClassB { 
    private Long id; 
    private String name; 


    public Long getId() { 
     return id; 
    } 

    public void setId(Long id) { 
     this.id = id; 
    } 

    public String getName() { 
     return name; 
    } 

    public void setName(String name) { 
     this.name = name; 
    } 
} 

Das heißt, KlasseA enthält eine Reihe von ClassB. Und eine Ressource wie so KlasseA zu aktualisieren:

@RequestMapping(method = RequestMethod.PUT) 
public ClassA update(@RequestBody ClassA a){ 
    // Update code here 
} 

und dann in einem DAO (mit Hibernate) die folgenden genannt wird KlasseA in der Datenbank zu aktualisieren:

@Override 
public ClassA save(ClassA classA) { 
    sessionFactory.getCurrentSession().saveOrUpdate(classA); 
    return classA; 
} 

In einem Update Szenario, wenn Ein authentifizierter Benutzer ändert die id einer Instanz von ClassB in eine id, die einem anderen Benutzer gehört. Wir stellen fest, dass es keine Schutzmechanismen gibt, die verhindern, dass der Benutzer Objekte aktualisiert, die nicht zu ihnen gehören. Gibt es Methoden, dies zu verhindern? Was ist die beste Vorgehensweise, um dies zu verhindern (d. H. Verhindert, dass sie einen anderen Benutzer aktualisieren classB Details)?

Antwort

1

Siehe Access Control using @PreAuthorize and @PostAuthorize:

Access Control mit @PreAuthorize und @PostAuthorize

Die offensichtlich nützliche Anmerkung ist @PreAuthorize, die ein Verfahren entscheidet, ob tatsächlich oder nicht aufgerufen werden kann. Zum Beispiel (aus der „Kontakten“ Beispielanwendung)

@PreAuthorize("hasRole('USER')") 
public void create(Contact contact); 

was bedeutet, dass der Zugang nur für Benutzer mit der Rolle „ROLE_USER“ zugelassen werden. Offensichtlich könnte das Gleiche leicht mit einer traditionellen Konfiguration und einem einfachen Konfigurationsattribut für die erforderliche Rolle erreicht werden. Aber was ist:

@PreAuthorize("hasPermission(#contact, 'admin')") 
public void deletePermission(Contact contact, Sid recipient, Permission permission); 

Hier sind wir tatsächlich eine Methode Argument als Teil des Ausdrucks verwendet, um zu entscheiden, ob der aktuelle Benutzer die „admin“ Berechtigung für den angegebenen Kontakt hat. Der integrierte Ausdruck hasPermission() ist über den Anwendungskontext mit dem Spring Security-ACL-Modul verknüpft, wie wir im Folgenden sehen werden. Sie können auf alle Methodenargumente anhand ihres Namens als Ausdrucksvariablen zugreifen.

0

Dies wird Geschäftslogik genannt. Hibernate hat keine Ahnung, dass das Feld id einen Benutzer bezeichnen soll. Es wird Sie nicht davon abhalten, das Feld auf einen beliebigen Wert zu setzen.

Der Code, der dieses Feld aufruft und das ID-Feld ändert, muss die Einschränkungen des Felds id kennen und verhindern, dass der Benutzer es ändert. Sie sollten zwischen Ihrer Benutzeroberfläche und Ihrem DAO eine Business-Schicht haben, die diese Art der Überprüfung durchführt.

+0

Danke für die Antwort, ich schätze, was Sie sagen. In diesem Fall haben wir eine Service-Schicht zwischen dem Controller und dem DAO, und daher wäre es logisch, diese Logik zu verwenden. Ich nehme an, dass die Frage ist mehr Fragen, ist es möglich, automatisch überwintern (oder möglicherweise Frühjahr/Frühjahr-Sicherheit) tun diese Arbeit für Sie? Oder wenn Methoden dafür irgendwo bekannt und dokumentiert sind. –

Verwandte Themen