Da hast du recht! Gut aufgepasst, die Version ist tatsächlich ein wenig veraltet. Korrekt wäre die jjwt-api der Version 0.11.2 (Stand jetzt). Siehe github.com/jwtk/jjwt Danke für den Hinweis :)
@@NoelLang Bei der Version verändert sich aber auch dann die API, Intellij wird darauf aber hinweisen und ist relativ einfach das zu ändern. Nur anstatt eines Strings muss nun ein Key/SecretKey Objekt übergeben werden.
Ich habe gute Javakenntnisse. Bisher habe ich mir meine MySQL Queries alle selbst zusammengebastelt... Was ja auch funktioniert. Nun bin ich auf OpenAPI gestoßen und habe auch schonmal was von Hibernate gehört... Dass das alles SO EINFACH geht, habe ich nicht erwartet ;) Es ist echt bemerkenswert, was alles geht und vor allem, dass man sich auf das eigentliche Projekt konzentrieren kann... Die fertige API dann noch in einem Docker Container und los gehts ;) Danke für das gute Tutorial... Ich werde mir doch mal einen Kurs mit Spring Boot zulegen, wenn sie wieder im Sale sind...
Beim Verfolgen dieses Tutorials habe ich einen Knoten reinbekommen. Ich bin bisher davon ausgegangen, dass man beim Erstellen des JWT Tokens zunächst den Nutzer mit seinem Username und Password authentifiziert, den Token erstellt, welcher nun als Ersatz für die Datenbank genutzt werden kann. Wenn ich also einen Token bekomme, diesen erfolgreich parse, so würde ich davon ausgehen, dass der Username im Token legitim ist und ich die in den Claims kodierten Authorities so verwenden kann. Warum hast du hier 18:38 Zeile 31 die Datenbank bemüht? Wäre das nicht redundant?
Welchen Hintergrund hat die Nutzung eines extra Objekts als @RequestBody (hier AuthRequest), anstatt direkt nach zwei Strings (email, password) zu fragen, wie dies beispielsweise in Springs eigenem Tutorial der Fall ist? Die Konsequenz wäre ja, für jede Anfragekombination, wenn eine neue Ressource angelegt wird, ein eigenes Objekt wie AuthRequest zu schreiben, oder? Die Nutzung von ResponseEntity vertehe ich - hier scheint mir der Vorteil einer einfacheren Arbeit mit JSON sehr direkt offensichtlich.
Insomnia ist ein wenig leichtgewichtiger, kann nicht unbedingt mehr, ist aber dafür nicht so vollgepackt. Ist mein Tool der Wahl, wenn ich einfach mal paar Requests schicken möchte :)
Hier ein interessanter Post, warum es vermieeden werden sollte @Data für Entities zu verwenden. TLDR: JPA Specification sagt du brauchst ein no-argument constructor, @Data erzeugt aber nur einen @RequiredArgsConstructor equals()/hashCode()/toString() laden alle felder und können versehentlich lazy attributes nachladen. Sprich ein @OneToMany kann alle Entitäten aus der DB nachladen. Entities sind mutable, da selbst die ID oft erst nach dem erstellen der entity gesetzt wird (von DB). Dadurch existieren u.U. keine verlässlichen Felder zur Berechnung eines Hashes Ansonsten gutes Tutorial 👍
Hey, danke dir für den wichtigen Hinweis! Würde es auch gerne anpinnen, aber lasse lieber mal die veraltete Lib stehen. :D Hatte ich so nicht im Kopf, dass @Data keinen no-args-constructor erstellt - wieder was gelernt!
Hi, vielen Dank für das super Video! Das ist wirklich sehr verständlich und nachvollziehbar! Du gibst ca. bei Minute 9 an, dass die Ablaufzeit realitätsfern ist. Was wäre denn aus deiner Sicht eine sinnvolle Zeit für den Ablauf des Tokens? Gruß Daniel Edit: Ich würde sagen der WebSecurityConfigurerAdapter ist ebenfalls veraltet.
Diese JWT Tutorials gehen alle immer einen Schritt zu kurz. Bei einem Microservice ist das alles perfekt, aber wie verhält es sich, sobald man ein Mix aus mehreren Microservices hat. Muss ich diesen Code in jeden Service einbauen oder was wäre die bessere Lösung für eine Enterprise Application? In meinen Augen, sollte das API Gateway eigentlich diese Prüfung machen und nur valide JWTs weiterleiten, aber wie verhält es sich dann mit Private/Public Keys für das Secret, also z.B. RSA? Und diese müssen natürlich auch rotieren. Dafür gibt es im JWT Header ein kid (KeyID) Feld, welches die Version sein könnte. Hier wäre ein etwas ausführlicheres Tutorial wirklich super.
![Spring Boot 3.0 Security | Authentication and Authorization | [New Changes] | javaTechie](http://i.ytimg.com/vi/R76S0tfv36w/mqdefault.jpg)
Ist die benutzte JWT-Lib nicht etwas veraltet und mit möglicher Gefahren verbunden?
Da hast du recht! Gut aufgepasst, die Version ist tatsächlich ein wenig veraltet. Korrekt wäre die jjwt-api der Version 0.11.2 (Stand jetzt). Siehe github.com/jwtk/jjwt
Danke für den Hinweis :)
@@NoelLang Bei der Version verändert sich aber auch dann die API, Intellij wird darauf aber hinweisen und ist relativ einfach das zu ändern. Nur anstatt eines Strings muss nun ein Key/SecretKey Objekt übergeben werden.
Super Video, genau richtig für Beginner, die sich vorher noch gar nicht mit Authentifizierung auseinandergesetzt haben und einen Startpunkt suchen.
Danke für dein Feedback! :)
Wirklich gutes Zeug, ohne Quatsch.
Danke dir!
Ich habe gute Javakenntnisse. Bisher habe ich mir meine MySQL Queries alle selbst zusammengebastelt... Was ja auch funktioniert. Nun bin ich auf OpenAPI gestoßen und habe auch schonmal was von Hibernate gehört... Dass das alles SO EINFACH geht, habe ich nicht erwartet ;) Es ist echt bemerkenswert, was alles geht und vor allem, dass man sich auf das eigentliche Projekt konzentrieren kann... Die fertige API dann noch in einem Docker Container und los gehts ;) Danke für das gute Tutorial... Ich werde mir doch mal einen Kurs mit Spring Boot zulegen, wenn sie wieder im Sale sind...
Beim Verfolgen dieses Tutorials habe ich einen Knoten reinbekommen. Ich bin bisher davon ausgegangen, dass man beim Erstellen des JWT Tokens zunächst den Nutzer mit seinem Username und Password authentifiziert, den Token erstellt, welcher nun als Ersatz für die Datenbank genutzt werden kann. Wenn ich also einen Token bekomme, diesen erfolgreich parse, so würde ich davon ausgehen, dass der Username im Token legitim ist und ich die in den Claims kodierten Authorities so verwenden kann. Warum hast du hier 18:38 Zeile 31 die Datenbank bemüht? Wäre das nicht redundant?
Bei 11:00 kopierst du die Exceptions für den Try-Catch Block rein. Wie hast du das gemacht?
Bei IntelliJ kannst du mit "Alt + Eingabe" Klassen importieren :)
Welchen Hintergrund hat die Nutzung eines extra Objekts als @RequestBody (hier AuthRequest), anstatt direkt nach zwei Strings (email, password) zu fragen, wie dies beispielsweise in Springs eigenem Tutorial der Fall ist? Die Konsequenz wäre ja, für jede Anfragekombination, wenn eine neue Ressource angelegt wird, ein eigenes Objekt wie AuthRequest zu schreiben, oder?
Die Nutzung von ResponseEntity vertehe ich - hier scheint mir der Vorteil einer einfacheren Arbeit mit JSON sehr direkt offensichtlich.
Hi. Danke für das tolle Tutorial. Man findet ja selten jemanden auf deutsch :) Find ich klasse mach weiter so!
Insomnia ist ein wenig leichtgewichtiger, kann nicht unbedingt mehr, ist aber dafür nicht so vollgepackt. Ist mein Tool der Wahl, wenn ich einfach mal paar Requests schicken möchte :)
Hier ein interessanter Post, warum es vermieeden werden sollte @Data für Entities zu verwenden.
TLDR:
JPA Specification sagt du brauchst ein no-argument constructor, @Data erzeugt aber nur einen @RequiredArgsConstructor
equals()/hashCode()/toString() laden alle felder und können versehentlich lazy attributes nachladen. Sprich ein @OneToMany kann alle Entitäten aus der DB nachladen.
Entities sind mutable, da selbst die ID oft erst nach dem erstellen der entity gesetzt wird (von DB). Dadurch existieren u.U. keine verlässlichen Felder zur Berechnung eines Hashes
Ansonsten gutes Tutorial 👍
Hey, danke dir für den wichtigen Hinweis! Würde es auch gerne anpinnen, aber lasse lieber mal die veraltete Lib stehen. :D
Hatte ich so nicht im Kopf, dass @Data keinen no-args-constructor erstellt - wieder was gelernt!
Hi, vielen Dank für das super Video! Das ist wirklich sehr verständlich und nachvollziehbar! Du gibst ca. bei Minute 9 an, dass die Ablaufzeit realitätsfern ist. Was wäre denn aus deiner Sicht eine sinnvolle Zeit für den Ablauf des Tokens? Gruß Daniel
Edit: Ich würde sagen der WebSecurityConfigurerAdapter ist ebenfalls veraltet.
Diese JWT Tutorials gehen alle immer einen Schritt zu kurz. Bei einem Microservice ist das alles perfekt, aber wie verhält es sich, sobald man ein Mix aus mehreren Microservices hat. Muss ich diesen Code in jeden Service einbauen oder was wäre die bessere Lösung für eine Enterprise Application?
In meinen Augen, sollte das API Gateway eigentlich diese Prüfung machen und nur valide JWTs weiterleiten, aber wie verhält es sich dann mit Private/Public Keys für das Secret, also z.B. RSA? Und diese müssen natürlich auch rotieren. Dafür gibt es im JWT Header ein kid (KeyID) Feld, welches die Version sein könnte. Hier wäre ein etwas ausführlicheres Tutorial wirklich super.
Jay-Wieh-Tay ... genau... Heartly luckwish, your languageknowledge is the yellow from the egg