Ich nehme derzeit an einer Akademie zum Java Fullstack Software Engineer teil. In den vergangenen Wochen bis heute habe ich meine Mitschrift, so gut es geht, aufgezeichnet und mitgeteilt. Hier ist das, was ich vom letzten Tag unseres Kurses gelernt und behalten habe:
Beim Pull oder Rebase wird das lokale Repository und der local workspace geupdated
Beim Fetch werden nur die Metadaten auf das locale Repository übertragen. Aber es gibt keine Datenänderung in den lokalen Stage (Index) noch im Workspace.
Ein git pull führt ein git fetch und anschließend ein git merge aus.
Letztendlich sind mein lokales Repository und der remote (origin) Repository zwei unterschiedliche Branches, auch wenn beide den gleichen Namen (z.B. "main") haben.
Es ist eine gute Angewohnheit, spätestens vor dem Feierabend ein git commit und ein git push durchzuführen:
Beim git pull --rebase schleppe ich den zeitstrahl nicht mit. Damit werde ich schneller:
- https://mixable.blog/git-unterschied-zwischen-git-pull-und-git-fetch/
- https://stackoverflow.com/questions/292357/what-is-the-difference-between-git-pull-and-git-fetch
---------------------------------------------------------------
Um den Tomcat-Server https-fähig zu machen, muss der Java Key-Store mit eingebunden werden. Dies geschieht hier:
Tomcat server.xml (*.war deployment von einer Rest-Applikation) -> Connector
Es gibt von Baeldung ein Beispiel, welches wir uns hier anschauen:
https://www.baeldung.com/spring-boot-https-self-signed-certificate
Siehe auch im Block 11/security/ssl-tls-tomcat-client-server-token. Dort liegt auch einiges an Doku.
Um Zertifiate in Java einzuspielen oder anzuschauen nutzen wir das Tool: KeyStore Explorer : https://keystore-explorer.org/
Die TLS Client-Serveraufrufe mit Zertifikaten für verschlüsselte Restfull Kommunikation sieht so aus:
StartParameter: java -Djavax.net.ssl.keyStore=C:\my.jks
-Djavax.net.ssl.keyStorePassword=secret
-Djava.protocol.handler.pkgs=com.sun.net.ssl.internal.www.protocol
-Djavax.net.debug=ssl,handshake
EchoServer
Hier ein Auszug aus dem Quellcode des Clients:
Die Startparameter sind in diesem Projekt schon gesetzt:
Im Log sieht man den Handshake:
Siehe Projekt Tomcat-safeuser/WEB-INF/web.xml. Dort finden wir die Einstellungen für die Security-Constrains:
Zu den Rollen gibt es User und Passwort-Zuordnungen (z.B. in der tomcat-user.xml oder einer DB oder LDAP-Server oder Windows Active Directory Service. Diese Config steckt in der server.xml-Datei.
Ein Server (Port 8080) möchte sich mit einem anderen Server (Response-Server, Port 8090) unterhalten. Der Auth-Server (z.B. OAuth2-Server) lauscht z.B. auf Port 9000.
Der Response-Server erwartet einen Authentifizierungstoken den er akzeptiert. Diesen gibt es vom Auth-Server. Daher erhält der Client (nach erfolgreichem Anmelden am OAuth2-Server) den Token.
Sobald der Client den Token an den Responsserver übergibt, checkt dieser beim Auth-Server, ob der Token gültig ist.
Google und Facebook können auch als Auth-Server dienen. Keycloak ist ein freier Authentifierungsserver.
Wir haben auch ein Projektbeispiel dazu. Das Beispiel stammt von: https://www.baeldung.com/spring-security-oauth-auth-server:
Dies ist eine Spring-Lösung die KeyCloak nachstellt.
Inhalt von readme.txt:
Wir starten den spring-auth-Server. Hier der Inhalt der pom.xml:
Application.yml:
DefaultSecurityConfig.java:
AuthorizationServerConfig: Sie legt die Reihenfolge der Request-Verarbeitung fest:
Wir starten den Resource-Server:
pom.xml:
application.yml:
ResoureceServerConfig:
Hier setzen wir den Filter für die URI um den Tokenzugriff zu kontrollieren:
ArticlesController.java:
Wir starten den Client
pom.xml:
Application.yml
Hier wird festgelegt, wo der Auth-Server liegt und wo der Ziel-Server liegt:
ArticlesController.java:
SecurityConfig.java:
WebClientConfig:
OAuth2ClientApplication.java:
Wir greifen zu auf http://127.0.0.1
Wir werden weiter geleitet auf:
Username: admin, Password: password
Alles was ich mitschrieb und verstanden habe ist ohne Gewähr. Die Bilder stammen teilweise aus dem Internet und wir haben keine Urheberansprüche darauf.
Besten Dank an unseren sehr empfehlenswerten
So!
Dieses war dann wohl mein letzter Beitrag zu der Seminar-Serie. Vielleicht kommen noch ein paar Artikel zu Erkenntnissen hinterher. Aber Ich bin jetzt soweit fertig mit der Akademie.
Diese Woche haben wir noch eine Recap-Phase und ein Abschlussprojekt.
Ab nächster Woche wird es ernst für mich, dann werde ich produktiv eingesetzt. Mal schauen was ich denn schon so kann ;-)
Im November letzten Jahres haben wir mit Java Programmierung angefangen. Dann lernten wir Spring, Javascript, React (NodeJS) und zum Schluss Devopsthemen wie Git, Docker und Kubernetes.
Java ist für mich einigermaßen nachvollziehbar; kompliziert - aber erlernbar.
Spring und React sind für mich große magische Geheimnisse - mal schauen wie ich in der Zukunft damit klar komme.
Devops ist mehr oder weniger eine alte Heimat für mich. Damit habe ich kaum Bauchschmerzen.
Ich habe sehr viel gelernt in den letzten fünf Monaten - und stehe doch ganz am Anfang.
Wir konnten jedes Thema nur oberflächlich ankratzen. Die Übungszeiten nutzte ich, um mich jeweils auf ein Thema zu konzentrieren - Aber gelernt haben wir 10 bis 20 Themen, je Block.
Wir haben ein großen Baukasten an Werkzeugen bekommen. Wir haben zahlreiche Beispiele, die ich jederzeit nachstellen kann. Ich denke, damit - und mit Hilfe der anderen Kollegen aus dem Team, sollte ich, etwas Zeit vorausgesetzt, die ersten Aufgaben zumindest angehen können.
Als Java fullstack Software Engineer sehe ich mich damit noch nicht, aber wenn ich am Ball bleibe (was ich vor habe) sollte ich in ein bis zwei Jahren doch vernünftig was auf die Beine stellen können.
Wir werden sehen.
Und zum Schluss noch:
Allerbesten Dank an den Trainer und die Kollegen der AKademie. Ihr habt einen tollen Job gemacht und Eure Arbeit hat sich wirklich gelohnt!!!
Achim Mertens