Configure and verify max-http-request-header-size: 32KB #529
Conversation
|
muss das für den admin-service und vorfaelleundvorkommnisse-service auch umgesetzt werden? |
ja, soll ich das gleich hier mit machen? Ich finde das würde zum PR passen. Dann stimmt der Branchname zwar nicht mehr aber den kann ich anpassen und den PR neustellen. |
|
ich habe keinen neuen Branch aufgemacht aber in der Merge-Commit-Nachricht den Titel auf meinen lokalen Branchnamen angepasst: fix-and-verify-request-header-size-settings |
MrSebastian
changed the title
There was a problem hiding this comment.
warum gibt es die application-test.yml in manchen services zwei mal? ich denke es sollte sie nur ein mal geben, weil wenn man zum beispiel eine konfiguration nachsehen möchte muss man immer an mehreren stellen suchen. außer in beiden steht das gleiche, das wäre aber noch ein grund mehr nur eine zu haben.
There was a problem hiding this comment.
Ist mir auch aufgefallen dass es manchmal ein application-test.yml in den main-Resourcen gibt und manchmal in den test-Ressourcen. Meine Intension war aber kein zweites File aufzumachen wenn es bereits eins gibt. Ich schaue nochmal durchen. Für die Vereinheitlichung mache ich ein Ticket auf. In dem Zuge können wir auch die anderen yml-Files die ursprünglich für Umgebungen gedacht waren aufräumen.
There was a problem hiding this comment.
Ich habe es korrigiert: In den Fällen wo es bereits eine application-yml gab und ich frische neue eingefügt hatte, habe ich meine Daten in den existierende Datei übertragen.
Das Issue zur Bereinigung der yml-Files ist #539
There was a problem hiding this comment.
kann man das certsStubbing.json und userinfoStubbing.json in wls.common auslagern, um die duplicated files zu minimieren?
There was a problem hiding this comment.
habe ich nicht probiert. Würde aber ein neues Release von Wls-common erfordern. Ich mache dazu ein Issue auf.
|
|
||
| val result = restTemplate.exchange(request, Void.class); | ||
|
|
||
| Assertions.assertThat(result.getStatusCode()).isEqualTo(HttpStatus.UNAUTHORIZED); //unauthorized cause token is expired |
There was a problem hiding this comment.
wo in dem test wird sichergestellt, dass die max-header-size gesetzt ist?
Wenn die Property nicht gesetzt kommt es zu einem BadRequest und nicht zu unauthorized
müsste man nicht einen test hinzufügen der die Assertion ...isEqualTo(HttpStatus.BAD_REQUEST); hat?
There was a problem hiding this comment.
wenn der Header nicht gesetzt kommt es zu dem Bad-Request. Ich hatte überlegt ob ich den negativ Test schreiben. Allerdings müsste dann der Header in einer seperaten yml-Datei gesenkt werden. Dadurch dass die Settings in application.yml vorliegen greift der max-http-request-header-size immer, solange es nicht überschrieben wird. Ich habe mich daher dafür entschieden zu prüfen ob unsere Headgröße ausreichend ist. Daher keinen negativen Test.
|
nachdem die erstellen Tests keine Aussagekraft haben und es auf Änderung nur an den Settings zum Auth-Service hinausläuft wird der PR eingestellt. |
Beschreibung:
Definition of Done (DoD):
Referenzen1:
Verwandt mit Issue #318
Closes #
Footnotes
Nicht zutreffende Referenzen vor dem Speichern entfernen ↩