Sensei Feature-Highlight: Bibliotheksumfang
Abhängigkeiten flexibel managen
Die Scope-Funktionalität von Sensei war schon immer ein Favorit der Entwickler. Mit der Möglichkeit, den Anwendungsbereich eines Rezepts zu erweitern oder einzuschränken, konnten Entwicklungsteams die Verwendung des Rezepts an einzelne Projekte und Branchen innerhalb ihrer Organisationen anpassen - was den Entwicklern die Möglichkeit gab, ihre Erfahrung zu personalisieren.
Und verständlicherweise steht sie im Mittelpunkt der kontinuierlichen Innovationsprozesse von Sensei. Während eines Innovations-Brainstormings zur Erweiterung des "Scope" (ja, Wortspiel beabsichtigt) kam eine Frage auf:
"Ich habe versucht, ein Rezept für ... zu erstellen, aber seit Version x hat das Framework die Funktion veraltet. Ich bin mir nicht sicher, ob es noch sinnvoll ist, ein Rezept zu erstellen. Was denken Sie?"
Natürlich ist dies nicht das erste Mal, dass wir gezögert haben, ein Rezept zu erstellen. Während das Rezept als Bereitstellung redundanter Informationen angesehen werden könnte, glauben wir, dass es wertvoll ist, etwas zu erstellen, das auf eine begrenzte Anzahl von Versionen der beteiligten Abhängigkeit anwendbar ist. Und deshalb haben wir den Library-Bereich erstellt.
Mit dem Bibliotheksumfang können wir prüfen, ob eine Abhängigkeit im Projekt vorhanden ist und Sensei Rezepte bedingt anwenden. Dies bietet große Flexibilität, wenn Teams durch Legacy-Code und Abhängigkeiten navigieren.
Viele von Ihnen kennen vielleicht den Bibliotheksbereich, der bereits unter Allgemeine Einstellungen verfügbar ist. Was ist das also, fragen Sie? Wir haben dafür gesorgt, dass der Bibliotheksbereich in YAML vorhanden ist, genau wie die Suche. Dies schafft ein besseres Benutzererlebnis und unterbricht nicht den Fluss beim Erstellen des Rezepts, bei dem Sie sonst zu den Allgemeinen Einstellungen und zurück navigieren müssten, um die Metadaten zu aktualisieren. Weitere dieser Scopes werden in YAML Einzug halten, aber wir haben mit dem Library Scope begonnen.
Lassen Sie uns also anhand eines Beispiels ein wenig tiefer in die Funktionsweise eintauchen.
Bibliotheksumfang, der auf hibernate-jpamodelgen angewendet wird
Stellen Sie sich den folgenden Fall vor:
Wir möchten eine Spring Web REST-API erstellen, mit der wir einige Daten abfragen können. Gemäß den Best Practices erstellen wir ein Modell für die Entität, die wir abfragen wollen. Als Nächstes fügen wir eine Abhängigkeit zum Hibernate ORM hinzu, damit wir uns nicht mit der Datenbankstruktur herumschlagen müssen. Der ORM übernimmt das für uns. Außerdem müssen wir einen Dienst erstellen, der die Daten aus der Datenzugriffsschicht (CRUD-Repositories usw.) für den Controller bereitstellt. Schließlich erstellen wir die Controller-Klasse für unsere API, in der wir die zulässigen Abfragen als Endpunkte bereitstellen.
Um zu vermeiden, dass wir für jedes abfragbare Feld unterschiedliche Endpunkte bereitstellen müssen, entscheiden wir uns stattdessen für die Verwendung von JPA 2-Spezifikationen. Dazu erstellen wir eine Spezifikation im Controller aus der Anfrage-URL. Diese Spezifikation beschreibt, wie die Entitäten, nach denen wir suchen, aussehen sollen. In der Klasse `Specification` selbst implementieren wir die Methode `toPredicate`, um anzugeben, wie die Spezifikation validiert werden kann.
Aber wir stehen vor einem Problem in der Methode "toPredicate". Um das Prädikat zu konstruieren, müssen wir die Namen der zu vergleichenden Spalten in der Datenbank kennen. Da wir aber ein ORM verwenden, haben wir diese Spalten nicht in einem separaten Modell. Also kommt der JPA 2 Metamodel Generator() von Hibernate zur Rettung! Dieser hilft dabei, ein Metamodell für die Entitäten zu generieren, die wir angefordert haben. Diese Metamodelle ermöglichen es uns, die Spaltennamen als Eigenschaften zu referenzieren, anstatt sie hart zu kodieren.
Erstellen des Rezepts Sensei
Jetzt, wo wir die Metamodelle generiert haben, wollen wir sie sinnvoll einsetzen. Sensei kann jedem, der an dem Projekt arbeitet, helfen, indem es ihn daran erinnert, das Metamodell zu verwenden, und sicherstellt, dass die Spaltennamen nirgendwo hardcodiert sind. Lassen Sie uns das also in die Praxis umsetzen.
Zunächst werfen wir einen Blick auf die Methode `toPredicate`.

Dieses einfache Prädikat vergleicht nur den Namen unserer Entität. Wir können es mit "und"-Klauseln erweitern, aber für den Zweck dieses Rezepts ist diese "einfache" Prüfung ausreichend.
Für die Suchkomponente des Rezepts wollen wir die Methode `get()` des Root-Parameters aufrufen, also wählen wir die Option `methodcall` aus dem Dropdown. Als nächstes wollen wir die Suche auf einen Methodenaufruf mit dem Namen `get` beschränken, dessen Signatur in der Schnittstelle `Path` des Pakets `javax.persistence.criteria` deklariert ist. Da die Methode überladen wurde, müssen wir der Suche auch mitteilen, dass unser Rezept nur für die Variante gilt, die einen einzelnen String als Argument nimmt. Um das Problem mit den Spaltennamen im Code zu beheben, möchten wir stattdessen ein Argument vom Typ `SingularAttribute` verwenden, demselben Typ, der vom Metamodell-Generator bereitgestellt wird.

Das Rezept, das wir bisher erstellt haben, wird auf jeder Codebasis ausgelöst, die die JPA 2 `Path`-Schnittstelle verwendet, unabhängig davon, ob die Codebasis für die Verwendung des Hibernate Model Generator eingerichtet ist. Wenn diese Bibliothek im Projekt vorhanden ist, möchten wir dem Benutzer anzeigen, dass sie verwendet werden soll, also fügen wir dem Rezept einen Bibliotheksbereich hinzu.

Und schließlich ist unser Rezept nun fertig.

Mit diesem Rezept wird jedes Auftreten von `Path#get`, das einen String-Wert als Argument verwendet, gekennzeichnet. Wie Sie an dem hervorgehobenen Beispielcode im obigen Screenshot erkennen können, funktioniert dieses Rezept auch dann, wenn der literale Name des Spaltennamens in einer Zwischenvariablen gespeichert ist.
Hinweis - Wir können den Bibliotheksbereich auch invertieren, um den Fall zu behandeln, dass die Bibliothek nicht verfügbar ist, indem wir dem Bereich eine "not"-Klausel voranstellen.
Fazit
Wie wir im obigen Beispiel gesehen haben, können wir mit dieser neuen Funktion nützlichere Rezepte erstellen, indem wir sie basierend auf dem Vorhandensein von Abhängigkeiten im Projekt anwenden. Um die Leistungsfähigkeit noch weiter zu erhöhen, haben wir mehr Optionen als im Beispiel gezeigt aufgenommen, wie z. B. nicht nur zu prüfen, ob die Abhängigkeit vorhanden ist, sondern auch Bedingungen auf die spezifische Version der Abhängigkeit anzuwenden.
Die Hauptanwendungsfälle, die wir für diese Funktion sehen, sind das Verhindern, dass Rezepte doppelte Informationen bereitstellen, das Erkennen von Problemen im Zusammenhang mit bestimmten Versionen von Abhängigkeiten, aber auch die Durchführung von Migrationen von einer Abhängigkeitsversion zur nächsten. Wir freuen uns darauf, von Ihnen zu hören, welche Anwendungen Sie für diese Funktion sehen.
Wie bei allen Funktionen von Sensei finden Sie weitere Informationen über den Umfang der Bibliothek in der Referenzdokumentation.
Nick ist ein engagierter Sicherheitsforscher bei Secure Code Warrior, mit Erfahrung sowohl in der Softwareentwicklung als auch in der Sicherheit. Neben einer Leidenschaft für Sicherheit hat er einen Msc. Ir. in Computerwissenschaften von der Universität Gent. Er ist auf einer Mission, Software für uns alle sicherer zu machen.

Secure Code Warrior ist für Ihr Unternehmen da, um Sie dabei zu unterstützen, Ihren Code über den gesamten Lebenszyklus der Softwareentwicklung hinweg zu sichern und eine Kultur zu schaffen, in der Cybersicherheit an erster Stelle steht. Ganz gleich, ob Sie AppSec-Manager, Entwickler, CISO oder ein anderer Sicherheitsverantwortlicher sind, wir können Ihrem Unternehmen helfen, die mit unsicherem Code verbundenen Risiken zu reduzieren.
Demo buchenNick ist ein engagierter Sicherheitsforscher bei Secure Code Warrior, mit Erfahrung sowohl in der Softwareentwicklung als auch in der Sicherheit. Neben einer Leidenschaft für Sicherheit hat er einen Msc. Ir. in Computerwissenschaften von der Universität Gent. Er ist auf einer Mission, Software für uns alle sicherer zu machen.


Abhängigkeiten flexibel managen
Die Scope-Funktionalität von Sensei war schon immer ein Favorit der Entwickler. Mit der Möglichkeit, den Anwendungsbereich eines Rezepts zu erweitern oder einzuschränken, konnten Entwicklungsteams die Verwendung des Rezepts an einzelne Projekte und Branchen innerhalb ihrer Organisationen anpassen - was den Entwicklern die Möglichkeit gab, ihre Erfahrung zu personalisieren.
Und verständlicherweise steht sie im Mittelpunkt der kontinuierlichen Innovationsprozesse von Sensei. Während eines Innovations-Brainstormings zur Erweiterung des "Scope" (ja, Wortspiel beabsichtigt) kam eine Frage auf:
"Ich habe versucht, ein Rezept für ... zu erstellen, aber seit Version x hat das Framework die Funktion veraltet. Ich bin mir nicht sicher, ob es noch sinnvoll ist, ein Rezept zu erstellen. Was denken Sie?"
Natürlich ist dies nicht das erste Mal, dass wir gezögert haben, ein Rezept zu erstellen. Während das Rezept als Bereitstellung redundanter Informationen angesehen werden könnte, glauben wir, dass es wertvoll ist, etwas zu erstellen, das auf eine begrenzte Anzahl von Versionen der beteiligten Abhängigkeit anwendbar ist. Und deshalb haben wir den Library-Bereich erstellt.
Mit dem Bibliotheksumfang können wir prüfen, ob eine Abhängigkeit im Projekt vorhanden ist und Sensei Rezepte bedingt anwenden. Dies bietet große Flexibilität, wenn Teams durch Legacy-Code und Abhängigkeiten navigieren.
Viele von Ihnen kennen vielleicht den Bibliotheksbereich, der bereits unter Allgemeine Einstellungen verfügbar ist. Was ist das also, fragen Sie? Wir haben dafür gesorgt, dass der Bibliotheksbereich in YAML vorhanden ist, genau wie die Suche. Dies schafft ein besseres Benutzererlebnis und unterbricht nicht den Fluss beim Erstellen des Rezepts, bei dem Sie sonst zu den Allgemeinen Einstellungen und zurück navigieren müssten, um die Metadaten zu aktualisieren. Weitere dieser Scopes werden in YAML Einzug halten, aber wir haben mit dem Library Scope begonnen.
Lassen Sie uns also anhand eines Beispiels ein wenig tiefer in die Funktionsweise eintauchen.
Bibliotheksumfang, der auf hibernate-jpamodelgen angewendet wird
Stellen Sie sich den folgenden Fall vor:
Wir möchten eine Spring Web REST-API erstellen, mit der wir einige Daten abfragen können. Gemäß den Best Practices erstellen wir ein Modell für die Entität, die wir abfragen wollen. Als Nächstes fügen wir eine Abhängigkeit zum Hibernate ORM hinzu, damit wir uns nicht mit der Datenbankstruktur herumschlagen müssen. Der ORM übernimmt das für uns. Außerdem müssen wir einen Dienst erstellen, der die Daten aus der Datenzugriffsschicht (CRUD-Repositories usw.) für den Controller bereitstellt. Schließlich erstellen wir die Controller-Klasse für unsere API, in der wir die zulässigen Abfragen als Endpunkte bereitstellen.
Um zu vermeiden, dass wir für jedes abfragbare Feld unterschiedliche Endpunkte bereitstellen müssen, entscheiden wir uns stattdessen für die Verwendung von JPA 2-Spezifikationen. Dazu erstellen wir eine Spezifikation im Controller aus der Anfrage-URL. Diese Spezifikation beschreibt, wie die Entitäten, nach denen wir suchen, aussehen sollen. In der Klasse `Specification` selbst implementieren wir die Methode `toPredicate`, um anzugeben, wie die Spezifikation validiert werden kann.
Aber wir stehen vor einem Problem in der Methode "toPredicate". Um das Prädikat zu konstruieren, müssen wir die Namen der zu vergleichenden Spalten in der Datenbank kennen. Da wir aber ein ORM verwenden, haben wir diese Spalten nicht in einem separaten Modell. Also kommt der JPA 2 Metamodel Generator() von Hibernate zur Rettung! Dieser hilft dabei, ein Metamodell für die Entitäten zu generieren, die wir angefordert haben. Diese Metamodelle ermöglichen es uns, die Spaltennamen als Eigenschaften zu referenzieren, anstatt sie hart zu kodieren.
Erstellen des Rezepts Sensei
Jetzt, wo wir die Metamodelle generiert haben, wollen wir sie sinnvoll einsetzen. Sensei kann jedem, der an dem Projekt arbeitet, helfen, indem es ihn daran erinnert, das Metamodell zu verwenden, und sicherstellt, dass die Spaltennamen nirgendwo hardcodiert sind. Lassen Sie uns das also in die Praxis umsetzen.
Zunächst werfen wir einen Blick auf die Methode `toPredicate`.

Dieses einfache Prädikat vergleicht nur den Namen unserer Entität. Wir können es mit "und"-Klauseln erweitern, aber für den Zweck dieses Rezepts ist diese "einfache" Prüfung ausreichend.
Für die Suchkomponente des Rezepts wollen wir die Methode `get()` des Root-Parameters aufrufen, also wählen wir die Option `methodcall` aus dem Dropdown. Als nächstes wollen wir die Suche auf einen Methodenaufruf mit dem Namen `get` beschränken, dessen Signatur in der Schnittstelle `Path` des Pakets `javax.persistence.criteria` deklariert ist. Da die Methode überladen wurde, müssen wir der Suche auch mitteilen, dass unser Rezept nur für die Variante gilt, die einen einzelnen String als Argument nimmt. Um das Problem mit den Spaltennamen im Code zu beheben, möchten wir stattdessen ein Argument vom Typ `SingularAttribute` verwenden, demselben Typ, der vom Metamodell-Generator bereitgestellt wird.

Das Rezept, das wir bisher erstellt haben, wird auf jeder Codebasis ausgelöst, die die JPA 2 `Path`-Schnittstelle verwendet, unabhängig davon, ob die Codebasis für die Verwendung des Hibernate Model Generator eingerichtet ist. Wenn diese Bibliothek im Projekt vorhanden ist, möchten wir dem Benutzer anzeigen, dass sie verwendet werden soll, also fügen wir dem Rezept einen Bibliotheksbereich hinzu.

Und schließlich ist unser Rezept nun fertig.

Mit diesem Rezept wird jedes Auftreten von `Path#get`, das einen String-Wert als Argument verwendet, gekennzeichnet. Wie Sie an dem hervorgehobenen Beispielcode im obigen Screenshot erkennen können, funktioniert dieses Rezept auch dann, wenn der literale Name des Spaltennamens in einer Zwischenvariablen gespeichert ist.
Hinweis - Wir können den Bibliotheksbereich auch invertieren, um den Fall zu behandeln, dass die Bibliothek nicht verfügbar ist, indem wir dem Bereich eine "not"-Klausel voranstellen.
Fazit
Wie wir im obigen Beispiel gesehen haben, können wir mit dieser neuen Funktion nützlichere Rezepte erstellen, indem wir sie basierend auf dem Vorhandensein von Abhängigkeiten im Projekt anwenden. Um die Leistungsfähigkeit noch weiter zu erhöhen, haben wir mehr Optionen als im Beispiel gezeigt aufgenommen, wie z. B. nicht nur zu prüfen, ob die Abhängigkeit vorhanden ist, sondern auch Bedingungen auf die spezifische Version der Abhängigkeit anzuwenden.
Die Hauptanwendungsfälle, die wir für diese Funktion sehen, sind das Verhindern, dass Rezepte doppelte Informationen bereitstellen, das Erkennen von Problemen im Zusammenhang mit bestimmten Versionen von Abhängigkeiten, aber auch die Durchführung von Migrationen von einer Abhängigkeitsversion zur nächsten. Wir freuen uns darauf, von Ihnen zu hören, welche Anwendungen Sie für diese Funktion sehen.
Wie bei allen Funktionen von Sensei finden Sie weitere Informationen über den Umfang der Bibliothek in der Referenzdokumentation.

Abhängigkeiten flexibel managen
Die Scope-Funktionalität von Sensei war schon immer ein Favorit der Entwickler. Mit der Möglichkeit, den Anwendungsbereich eines Rezepts zu erweitern oder einzuschränken, konnten Entwicklungsteams die Verwendung des Rezepts an einzelne Projekte und Branchen innerhalb ihrer Organisationen anpassen - was den Entwicklern die Möglichkeit gab, ihre Erfahrung zu personalisieren.
Und verständlicherweise steht sie im Mittelpunkt der kontinuierlichen Innovationsprozesse von Sensei. Während eines Innovations-Brainstormings zur Erweiterung des "Scope" (ja, Wortspiel beabsichtigt) kam eine Frage auf:
"Ich habe versucht, ein Rezept für ... zu erstellen, aber seit Version x hat das Framework die Funktion veraltet. Ich bin mir nicht sicher, ob es noch sinnvoll ist, ein Rezept zu erstellen. Was denken Sie?"
Natürlich ist dies nicht das erste Mal, dass wir gezögert haben, ein Rezept zu erstellen. Während das Rezept als Bereitstellung redundanter Informationen angesehen werden könnte, glauben wir, dass es wertvoll ist, etwas zu erstellen, das auf eine begrenzte Anzahl von Versionen der beteiligten Abhängigkeit anwendbar ist. Und deshalb haben wir den Library-Bereich erstellt.
Mit dem Bibliotheksumfang können wir prüfen, ob eine Abhängigkeit im Projekt vorhanden ist und Sensei Rezepte bedingt anwenden. Dies bietet große Flexibilität, wenn Teams durch Legacy-Code und Abhängigkeiten navigieren.
Viele von Ihnen kennen vielleicht den Bibliotheksbereich, der bereits unter Allgemeine Einstellungen verfügbar ist. Was ist das also, fragen Sie? Wir haben dafür gesorgt, dass der Bibliotheksbereich in YAML vorhanden ist, genau wie die Suche. Dies schafft ein besseres Benutzererlebnis und unterbricht nicht den Fluss beim Erstellen des Rezepts, bei dem Sie sonst zu den Allgemeinen Einstellungen und zurück navigieren müssten, um die Metadaten zu aktualisieren. Weitere dieser Scopes werden in YAML Einzug halten, aber wir haben mit dem Library Scope begonnen.
Lassen Sie uns also anhand eines Beispiels ein wenig tiefer in die Funktionsweise eintauchen.
Bibliotheksumfang, der auf hibernate-jpamodelgen angewendet wird
Stellen Sie sich den folgenden Fall vor:
Wir möchten eine Spring Web REST-API erstellen, mit der wir einige Daten abfragen können. Gemäß den Best Practices erstellen wir ein Modell für die Entität, die wir abfragen wollen. Als Nächstes fügen wir eine Abhängigkeit zum Hibernate ORM hinzu, damit wir uns nicht mit der Datenbankstruktur herumschlagen müssen. Der ORM übernimmt das für uns. Außerdem müssen wir einen Dienst erstellen, der die Daten aus der Datenzugriffsschicht (CRUD-Repositories usw.) für den Controller bereitstellt. Schließlich erstellen wir die Controller-Klasse für unsere API, in der wir die zulässigen Abfragen als Endpunkte bereitstellen.
Um zu vermeiden, dass wir für jedes abfragbare Feld unterschiedliche Endpunkte bereitstellen müssen, entscheiden wir uns stattdessen für die Verwendung von JPA 2-Spezifikationen. Dazu erstellen wir eine Spezifikation im Controller aus der Anfrage-URL. Diese Spezifikation beschreibt, wie die Entitäten, nach denen wir suchen, aussehen sollen. In der Klasse `Specification` selbst implementieren wir die Methode `toPredicate`, um anzugeben, wie die Spezifikation validiert werden kann.
Aber wir stehen vor einem Problem in der Methode "toPredicate". Um das Prädikat zu konstruieren, müssen wir die Namen der zu vergleichenden Spalten in der Datenbank kennen. Da wir aber ein ORM verwenden, haben wir diese Spalten nicht in einem separaten Modell. Also kommt der JPA 2 Metamodel Generator() von Hibernate zur Rettung! Dieser hilft dabei, ein Metamodell für die Entitäten zu generieren, die wir angefordert haben. Diese Metamodelle ermöglichen es uns, die Spaltennamen als Eigenschaften zu referenzieren, anstatt sie hart zu kodieren.
Erstellen des Rezepts Sensei
Jetzt, wo wir die Metamodelle generiert haben, wollen wir sie sinnvoll einsetzen. Sensei kann jedem, der an dem Projekt arbeitet, helfen, indem es ihn daran erinnert, das Metamodell zu verwenden, und sicherstellt, dass die Spaltennamen nirgendwo hardcodiert sind. Lassen Sie uns das also in die Praxis umsetzen.
Zunächst werfen wir einen Blick auf die Methode `toPredicate`.

Dieses einfache Prädikat vergleicht nur den Namen unserer Entität. Wir können es mit "und"-Klauseln erweitern, aber für den Zweck dieses Rezepts ist diese "einfache" Prüfung ausreichend.
Für die Suchkomponente des Rezepts wollen wir die Methode `get()` des Root-Parameters aufrufen, also wählen wir die Option `methodcall` aus dem Dropdown. Als nächstes wollen wir die Suche auf einen Methodenaufruf mit dem Namen `get` beschränken, dessen Signatur in der Schnittstelle `Path` des Pakets `javax.persistence.criteria` deklariert ist. Da die Methode überladen wurde, müssen wir der Suche auch mitteilen, dass unser Rezept nur für die Variante gilt, die einen einzelnen String als Argument nimmt. Um das Problem mit den Spaltennamen im Code zu beheben, möchten wir stattdessen ein Argument vom Typ `SingularAttribute` verwenden, demselben Typ, der vom Metamodell-Generator bereitgestellt wird.

Das Rezept, das wir bisher erstellt haben, wird auf jeder Codebasis ausgelöst, die die JPA 2 `Path`-Schnittstelle verwendet, unabhängig davon, ob die Codebasis für die Verwendung des Hibernate Model Generator eingerichtet ist. Wenn diese Bibliothek im Projekt vorhanden ist, möchten wir dem Benutzer anzeigen, dass sie verwendet werden soll, also fügen wir dem Rezept einen Bibliotheksbereich hinzu.

Und schließlich ist unser Rezept nun fertig.

Mit diesem Rezept wird jedes Auftreten von `Path#get`, das einen String-Wert als Argument verwendet, gekennzeichnet. Wie Sie an dem hervorgehobenen Beispielcode im obigen Screenshot erkennen können, funktioniert dieses Rezept auch dann, wenn der literale Name des Spaltennamens in einer Zwischenvariablen gespeichert ist.
Hinweis - Wir können den Bibliotheksbereich auch invertieren, um den Fall zu behandeln, dass die Bibliothek nicht verfügbar ist, indem wir dem Bereich eine "not"-Klausel voranstellen.
Fazit
Wie wir im obigen Beispiel gesehen haben, können wir mit dieser neuen Funktion nützlichere Rezepte erstellen, indem wir sie basierend auf dem Vorhandensein von Abhängigkeiten im Projekt anwenden. Um die Leistungsfähigkeit noch weiter zu erhöhen, haben wir mehr Optionen als im Beispiel gezeigt aufgenommen, wie z. B. nicht nur zu prüfen, ob die Abhängigkeit vorhanden ist, sondern auch Bedingungen auf die spezifische Version der Abhängigkeit anzuwenden.
Die Hauptanwendungsfälle, die wir für diese Funktion sehen, sind das Verhindern, dass Rezepte doppelte Informationen bereitstellen, das Erkennen von Problemen im Zusammenhang mit bestimmten Versionen von Abhängigkeiten, aber auch die Durchführung von Migrationen von einer Abhängigkeitsversion zur nächsten. Wir freuen uns darauf, von Ihnen zu hören, welche Anwendungen Sie für diese Funktion sehen.
Wie bei allen Funktionen von Sensei finden Sie weitere Informationen über den Umfang der Bibliothek in der Referenzdokumentation.

Klicken Sie auf den unten stehenden Link und laden Sie die PDF-Datei dieser Ressource herunter.
Secure Code Warrior ist für Ihr Unternehmen da, um Sie dabei zu unterstützen, Ihren Code über den gesamten Lebenszyklus der Softwareentwicklung hinweg zu sichern und eine Kultur zu schaffen, in der Cybersicherheit an erster Stelle steht. Ganz gleich, ob Sie AppSec-Manager, Entwickler, CISO oder ein anderer Sicherheitsverantwortlicher sind, wir können Ihrem Unternehmen helfen, die mit unsicherem Code verbundenen Risiken zu reduzieren.
Bericht ansehenDemo buchenNick ist ein engagierter Sicherheitsforscher bei Secure Code Warrior, mit Erfahrung sowohl in der Softwareentwicklung als auch in der Sicherheit. Neben einer Leidenschaft für Sicherheit hat er einen Msc. Ir. in Computerwissenschaften von der Universität Gent. Er ist auf einer Mission, Software für uns alle sicherer zu machen.
Abhängigkeiten flexibel managen
Die Scope-Funktionalität von Sensei war schon immer ein Favorit der Entwickler. Mit der Möglichkeit, den Anwendungsbereich eines Rezepts zu erweitern oder einzuschränken, konnten Entwicklungsteams die Verwendung des Rezepts an einzelne Projekte und Branchen innerhalb ihrer Organisationen anpassen - was den Entwicklern die Möglichkeit gab, ihre Erfahrung zu personalisieren.
Und verständlicherweise steht sie im Mittelpunkt der kontinuierlichen Innovationsprozesse von Sensei. Während eines Innovations-Brainstormings zur Erweiterung des "Scope" (ja, Wortspiel beabsichtigt) kam eine Frage auf:
"Ich habe versucht, ein Rezept für ... zu erstellen, aber seit Version x hat das Framework die Funktion veraltet. Ich bin mir nicht sicher, ob es noch sinnvoll ist, ein Rezept zu erstellen. Was denken Sie?"
Natürlich ist dies nicht das erste Mal, dass wir gezögert haben, ein Rezept zu erstellen. Während das Rezept als Bereitstellung redundanter Informationen angesehen werden könnte, glauben wir, dass es wertvoll ist, etwas zu erstellen, das auf eine begrenzte Anzahl von Versionen der beteiligten Abhängigkeit anwendbar ist. Und deshalb haben wir den Library-Bereich erstellt.
Mit dem Bibliotheksumfang können wir prüfen, ob eine Abhängigkeit im Projekt vorhanden ist und Sensei Rezepte bedingt anwenden. Dies bietet große Flexibilität, wenn Teams durch Legacy-Code und Abhängigkeiten navigieren.
Viele von Ihnen kennen vielleicht den Bibliotheksbereich, der bereits unter Allgemeine Einstellungen verfügbar ist. Was ist das also, fragen Sie? Wir haben dafür gesorgt, dass der Bibliotheksbereich in YAML vorhanden ist, genau wie die Suche. Dies schafft ein besseres Benutzererlebnis und unterbricht nicht den Fluss beim Erstellen des Rezepts, bei dem Sie sonst zu den Allgemeinen Einstellungen und zurück navigieren müssten, um die Metadaten zu aktualisieren. Weitere dieser Scopes werden in YAML Einzug halten, aber wir haben mit dem Library Scope begonnen.
Lassen Sie uns also anhand eines Beispiels ein wenig tiefer in die Funktionsweise eintauchen.
Bibliotheksumfang, der auf hibernate-jpamodelgen angewendet wird
Stellen Sie sich den folgenden Fall vor:
Wir möchten eine Spring Web REST-API erstellen, mit der wir einige Daten abfragen können. Gemäß den Best Practices erstellen wir ein Modell für die Entität, die wir abfragen wollen. Als Nächstes fügen wir eine Abhängigkeit zum Hibernate ORM hinzu, damit wir uns nicht mit der Datenbankstruktur herumschlagen müssen. Der ORM übernimmt das für uns. Außerdem müssen wir einen Dienst erstellen, der die Daten aus der Datenzugriffsschicht (CRUD-Repositories usw.) für den Controller bereitstellt. Schließlich erstellen wir die Controller-Klasse für unsere API, in der wir die zulässigen Abfragen als Endpunkte bereitstellen.
Um zu vermeiden, dass wir für jedes abfragbare Feld unterschiedliche Endpunkte bereitstellen müssen, entscheiden wir uns stattdessen für die Verwendung von JPA 2-Spezifikationen. Dazu erstellen wir eine Spezifikation im Controller aus der Anfrage-URL. Diese Spezifikation beschreibt, wie die Entitäten, nach denen wir suchen, aussehen sollen. In der Klasse `Specification` selbst implementieren wir die Methode `toPredicate`, um anzugeben, wie die Spezifikation validiert werden kann.
Aber wir stehen vor einem Problem in der Methode "toPredicate". Um das Prädikat zu konstruieren, müssen wir die Namen der zu vergleichenden Spalten in der Datenbank kennen. Da wir aber ein ORM verwenden, haben wir diese Spalten nicht in einem separaten Modell. Also kommt der JPA 2 Metamodel Generator() von Hibernate zur Rettung! Dieser hilft dabei, ein Metamodell für die Entitäten zu generieren, die wir angefordert haben. Diese Metamodelle ermöglichen es uns, die Spaltennamen als Eigenschaften zu referenzieren, anstatt sie hart zu kodieren.
Erstellen des Rezepts Sensei
Jetzt, wo wir die Metamodelle generiert haben, wollen wir sie sinnvoll einsetzen. Sensei kann jedem, der an dem Projekt arbeitet, helfen, indem es ihn daran erinnert, das Metamodell zu verwenden, und sicherstellt, dass die Spaltennamen nirgendwo hardcodiert sind. Lassen Sie uns das also in die Praxis umsetzen.
Zunächst werfen wir einen Blick auf die Methode `toPredicate`.

Dieses einfache Prädikat vergleicht nur den Namen unserer Entität. Wir können es mit "und"-Klauseln erweitern, aber für den Zweck dieses Rezepts ist diese "einfache" Prüfung ausreichend.
Für die Suchkomponente des Rezepts wollen wir die Methode `get()` des Root-Parameters aufrufen, also wählen wir die Option `methodcall` aus dem Dropdown. Als nächstes wollen wir die Suche auf einen Methodenaufruf mit dem Namen `get` beschränken, dessen Signatur in der Schnittstelle `Path` des Pakets `javax.persistence.criteria` deklariert ist. Da die Methode überladen wurde, müssen wir der Suche auch mitteilen, dass unser Rezept nur für die Variante gilt, die einen einzelnen String als Argument nimmt. Um das Problem mit den Spaltennamen im Code zu beheben, möchten wir stattdessen ein Argument vom Typ `SingularAttribute` verwenden, demselben Typ, der vom Metamodell-Generator bereitgestellt wird.

Das Rezept, das wir bisher erstellt haben, wird auf jeder Codebasis ausgelöst, die die JPA 2 `Path`-Schnittstelle verwendet, unabhängig davon, ob die Codebasis für die Verwendung des Hibernate Model Generator eingerichtet ist. Wenn diese Bibliothek im Projekt vorhanden ist, möchten wir dem Benutzer anzeigen, dass sie verwendet werden soll, also fügen wir dem Rezept einen Bibliotheksbereich hinzu.

Und schließlich ist unser Rezept nun fertig.

Mit diesem Rezept wird jedes Auftreten von `Path#get`, das einen String-Wert als Argument verwendet, gekennzeichnet. Wie Sie an dem hervorgehobenen Beispielcode im obigen Screenshot erkennen können, funktioniert dieses Rezept auch dann, wenn der literale Name des Spaltennamens in einer Zwischenvariablen gespeichert ist.
Hinweis - Wir können den Bibliotheksbereich auch invertieren, um den Fall zu behandeln, dass die Bibliothek nicht verfügbar ist, indem wir dem Bereich eine "not"-Klausel voranstellen.
Fazit
Wie wir im obigen Beispiel gesehen haben, können wir mit dieser neuen Funktion nützlichere Rezepte erstellen, indem wir sie basierend auf dem Vorhandensein von Abhängigkeiten im Projekt anwenden. Um die Leistungsfähigkeit noch weiter zu erhöhen, haben wir mehr Optionen als im Beispiel gezeigt aufgenommen, wie z. B. nicht nur zu prüfen, ob die Abhängigkeit vorhanden ist, sondern auch Bedingungen auf die spezifische Version der Abhängigkeit anzuwenden.
Die Hauptanwendungsfälle, die wir für diese Funktion sehen, sind das Verhindern, dass Rezepte doppelte Informationen bereitstellen, das Erkennen von Problemen im Zusammenhang mit bestimmten Versionen von Abhängigkeiten, aber auch die Durchführung von Migrationen von einer Abhängigkeitsversion zur nächsten. Wir freuen uns darauf, von Ihnen zu hören, welche Anwendungen Sie für diese Funktion sehen.
Wie bei allen Funktionen von Sensei finden Sie weitere Informationen über den Umfang der Bibliothek in der Referenzdokumentation.
Inhaltsübersicht
Nick ist ein engagierter Sicherheitsforscher bei Secure Code Warrior, mit Erfahrung sowohl in der Softwareentwicklung als auch in der Sicherheit. Neben einer Leidenschaft für Sicherheit hat er einen Msc. Ir. in Computerwissenschaften von der Universität Gent. Er ist auf einer Mission, Software für uns alle sicherer zu machen.

Secure Code Warrior ist für Ihr Unternehmen da, um Sie dabei zu unterstützen, Ihren Code über den gesamten Lebenszyklus der Softwareentwicklung hinweg zu sichern und eine Kultur zu schaffen, in der Cybersicherheit an erster Stelle steht. Ganz gleich, ob Sie AppSec-Manager, Entwickler, CISO oder ein anderer Sicherheitsverantwortlicher sind, wir können Ihrem Unternehmen helfen, die mit unsicherem Code verbundenen Risiken zu reduzieren.
Demo buchenHerunterladenRessourcen für den Einstieg
Sicher durch Design: Definition von Best Practices, Befähigung von Entwicklern und Benchmarking von präventiven Sicherheitsergebnissen
In diesem Forschungspapier werden die Mitbegründer von Secure Code Warrior , Pieter Danhieux und Dr. Matias Madou, Ph.D., zusammen mit den Experten Chris Inglis, ehemaliger US National Cyber Director (jetzt strategischer Berater der Paladin Capital Group), und Devin Lynch, Senior Director, Paladin Global Institute, die wichtigsten Erkenntnisse aus mehr als zwanzig ausführlichen Interviews mit Sicherheitsverantwortlichen in Unternehmen, darunter CISOs, ein VP of Application Security und Software-Sicherheitsexperten, offenlegen.
Benchmarking von Sicherheitskompetenzen: Optimierung von Secure-by-Design im Unternehmen
Aussagekräftige Daten über den Erfolg von Secure-by-Design-Initiativen zu finden, ist bekanntermaßen schwierig. CISOs stehen oft vor der Herausforderung, den Return on Investment (ROI) und den Geschäftswert von Sicherheitsprogrammen sowohl auf Mitarbeiter- als auch auf Unternehmensebene nachzuweisen. Ganz zu schweigen davon, dass es für Unternehmen besonders schwierig ist, Erkenntnisse darüber zu gewinnen, wie ihre Organisation im Vergleich zu aktuellen Branchenstandards abschneidet. Die Nationale Cybersicherheitsstrategie des Präsidenten forderte die Beteiligten auf, "Sicherheit und Widerstandsfähigkeit durch Design" zu erreichen. Der Schlüssel zum Erfolg von Secure-by-Design-Initiativen liegt nicht nur darin, Entwicklern die nötigen Fähigkeiten zu vermitteln, um sicheren Code zu gewährleisten, sondern auch darin, den Aufsichtsbehörden zu versichern, dass diese Fähigkeiten vorhanden sind. In dieser Präsentation stellen wir eine Vielzahl von qualitativen und quantitativen Daten vor, die aus verschiedenen Primärquellen stammen, darunter interne Daten von über 250.000 Entwicklern, datengestützte Kundeneinblicke und öffentliche Studien. Auf der Grundlage dieser gesammelten Daten wollen wir eine Vision des aktuellen Stands von Secure-by-Design-Initiativen in verschiedenen Branchen vermitteln. Der Bericht zeigt auf, warum dieser Bereich derzeit nicht ausreichend genutzt wird, welche erheblichen Auswirkungen ein erfolgreiches Schulungsprogramm auf die Minderung von Cybersecurity-Risiken haben kann und welches Potenzial zur Beseitigung von Schwachstellen in einer Codebasis besteht.
Professionelle Dienstleistungen - Beschleunigen Sie mit Fachwissen
Das PSS-Team (Program Strategy Services) von Secure Code Warriorunterstützt Sie beim Aufbau, der Verbesserung und der Optimierung Ihres Programms für sichere Codierung. Ganz gleich, ob Sie neu anfangen oder Ihren Ansatz verfeinern möchten, unsere Experten bieten Ihnen maßgeschneiderte Beratung.
Themen und Inhalte der Schulung zu sicherem Code
Unsere branchenführenden Inhalte werden ständig weiterentwickelt, um sie an die sich ständig verändernde Softwareentwicklungslandschaft anzupassen und Ihre Rolle zu berücksichtigen. Die Themen reichen von KI bis XQuery Injection und werden für eine Vielzahl von Rollen angeboten, von Architekten und Ingenieuren bis hin zu Produktmanagern und QA. Verschaffen Sie sich einen kleinen Überblick über die Inhalte, die unser Katalog nach Thema und Rolle bietet.
Ressourcen für den Einstieg
Aufgedeckt: Wie die Cyber-Industrie "Secure by Design" definiert
In unserem neuesten Whitepaper haben sich unsere Mitbegründer Pieter Danhieux und Dr. Matias Madou, Ph.D., mit über zwanzig Sicherheitsverantwortlichen in Unternehmen, darunter CISOs, AppSec-Leiter und Sicherheitsexperten, zusammengesetzt, um die wichtigsten Teile dieses Puzzles herauszufinden und die Realität hinter der Secure by Design-Bewegung aufzudecken. Die Sicherheitsteams haben ein gemeinsames Ziel, aber kein gemeinsames Regelwerk.
Wird Vibe Coding Ihre Codebasis in eine Verbindungsparty verwandeln?
Vibe Coding ist wie eine College-Verbindungsparty, und AI ist das Herzstück aller Festivitäten, das Fass. Es macht eine Menge Spaß, sich auszutoben, kreativ zu werden und zu sehen, wohin die eigene Fantasie einen führen kann, aber nach ein paar Bierfässern ist das Trinken (oder die Verwendung von KI) in Maßen zweifellos die sicherere langfristige Lösung.