Übungsaufgaben zum Change Request Authentifizierung: Die Mitfahrgesuche absichern

Übungsaufgaben zum Change Request Authentifizierung: Die Mitfahrgesuche absichern

https://bildung.social/@oerinformatik/

https://oer-informatik.de/spring-boot-change-request-authentifizierung-uebungsaufgaben

Change Request, Auswirkungsanalyse, Regressionstest, Spring Security, HTTP Basic, Authentifizierung, Autorisierung, WithMockUser, Übungsaufgaben

tl/dr; (ca. 34 min Lese- und Bearbeitungszeit): Übungen zum Änderungsantrag „Anmeldung statt Nutzer-ID“ im Mitfahr-Backend: Du ordnest Anfragen den Statuscodes 401 und 403 zu, analysierst die Auswirkungen auf die Mitfahrgesuche, ergänzt die Regeln der SecurityFilterChain, lässt nur eigene Gesuche zurückziehen, testest den Controller mit @WithMockUser und bewertest HTTP Basic gegenüber OAuth2 [AI-Assisted]. (Zuletzt geändert am 11.11.2026)

Dieser Artikel ist Teil einer Artikelreihe über ein REST-Backend mit Spring Boot: Überblick und Fahrplan / 01 Anforderungen und API-Vertrag / 02 Projekt anlegen / 03 Codegenerierung / 04 Fachlogik und Komponententest / 05 Build-Qualität und CI / 06 Persistenz mit JPA / 07 Repository-Integrationstest / 08 Service und Dependency Injection / 09 REST-API und Fehlerbehandlung / 10 Controller-Integrationstest / 11 System- und Abnahmetest / 12 Change Request Authentifizierung / Übungsaufgaben zu 12

Diese Übungsaufgaben gehören zum Artikel Change Request: Anmeldung mit Spring Security nachrüsten und alle Testebenen als Regressionstest nutzen und setzen den Übungsstrang zu den Mitfahrgesuchen fort. Ausgangspunkt ist das Projekt im Ordner src/12-change-request-authentifizierung des Repositorys mit Anmeldung per HTTP Basic (Passwort aller Demo-Konten: mitfahren), ergänzt um die Klassen aus den bisherigen Übungen: die Entity Gesuch mit zieheZurueck(), GesuchRepository, NeuesGesuch, GesuchService, GesuchController und den Vertrag mit POST /v1/gesuche und PATCH /v1/gesuche/{gesuchId}.

Der Änderungsantrag CR-01 aus dem Artikel gilt auch für die Gesuche:

Wer ein Gesuch einstellt, ist die angemeldete Person; die mitfahrerId steht nicht mehr im Body, sondern nur noch in der Antwort. Ein Gesuch zurückziehen darf nur, wer es eingestellt hat. Das Organisationsteam (Rolle ORGA, Pseudonym Admin-AW) stellt keine Gesuche ein. Der Flurmonitor bleibt ohne Anmeldung lesbar.

Hinweise zur Bearbeitung: Bis zur Teil-1-Prüfung der IT-Berufe solltest Du die Basiskompetenz beherrschen, also Aufgabe 1.1 und Aufgabe 1.2. Als FIA, FIDP oder FIDV musst Du zur Teil-2-Prüfung Aufgaben auf Kernkompetenz-Ebene lösen können, das sind Aufgabe 2.1, Aufgabe 2.2 und Aufgabe 2.3. Von FIA wird zusätzlich erwartet, dass ihnen Aufgaben auf Profilkompetenz-Ebene (Aufgabe 3.1) keine Probleme bereiten. Notiere Deine Antworten zuerst vollständig, bevor Du die Beispiellösung aufklappst. Code und Tests kannst Du anschließend im Projekt aus dem Repository mit dem Build ausführen; andere fachlich richtige Lösungen sind ebenso richtig.

Du möchtest eigene Aufgaben zum Üben von einem KI-Sprachmodell generieren lassen? Prompt ein-/ausblenden

Erstelle neue Übungsaufgaben zum Thema „Change Request
Authentifizierung: Die Mitfahrgesuche absichern“.

Bauplan: Halte Dich an Aufbau, Kompetenzstufen, Operatoren,
Anforderungsbereiche, Punkte und Zeitschätzung, die im Artikel
https://oer-informatik.de/aufgaben-aufbau beschrieben sind.

Fachliche Grundlage:
- https://oer-informatik.de/spring-boot-change-request-authentifizierung
- https://oer-informatik.de/authentifizierung
- https://oer-informatik.de/passwort-mfa
- https://oer-informatik.de/v-modell
- Stilbeispiel: https://oer-informatik.de/spring-boot-change-request-authentifizierung-uebungsaufgaben

Die Aufgaben sollen Inhalte zu diesen Schlagwörtern abdecken:
- Change Request
- Auswirkungsanalyse
- Regressionstest
- Spring Security
- HTTP Basic
- Authentifizierung
- Autorisierung
- WithMockUser

Kompetenzstufe: Kernkompetenz (alternativ: Basiskompetenz, Profilkompetenz, Expertise)
Anzahl: 1 Aufgabe mit Teilaufgaben
Bearbeitungszeit in Minuten ca.: <5 bis 30 min>
Szenario: eines der Szenarien aus dem Bauplan

Vorgehen:
1. Lies zuerst die verlinkten Artikel. Kannst Du keine Webseiten
   abrufen, sag mir das, statt zu raten.
2. Steht bei einer Angabe noch ein Platzhalter in <…>, frag mich
   zuerst danach. Richte Punkte und Zahl der Teilaufgaben nach der
   Bearbeitungszeit (ca. 0,9 min je Punkt).
3. Gib je Aufgabe Titel mit Kompetenzstufe, Ausgangssituation und
   Teilaufgaben mit Operator und Punktzahl aus, dazu die geschätzte
   Bearbeitungszeit.
4. Gib die Beispiellösungen mit Punkteverteilung erst aus, wenn ich
   danach frage.

Aufgabe 1.1: 401, 403 oder Erfolg? (Basiskompetenz)

Gib für jede Anfrage an das Backend nach CR-01 den Statuscode an und begründe kurz. Oksana (Pseudonym Kaffeetasse, Nutzerin 3) hat Gesuch 1 eingestellt; es ist offen. Lukas hat das Pseudonym Bassline. (6 Punkte)

Aufgabe 1.2: Auswirkungsanalyse für die Gesuche (Basiskompetenz)

Die Auswirkungsanalyse im Artikel hat die Gesuche noch nicht berücksichtigt.

1. Nenne vier Artefakte des Gesuch-Strangs (Vertrag, Klassen, Tests), die CR-01 ändert, und je die Änderung. (4 Punkte)

2. Ist die Änderung von POST /v1/gesuche für ein Frontend kompatibel? Begründe und nenne die Folge für die Versionsnummer des Vertrags. (2 Punkte)

Aufgabe 2.1: Regeln in der SecurityFilterChain ergänzen (Kernkompetenz)

Ausgangspunkt ist die SicherheitsKonfiguration aus dem Artikel:

http.authorizeHttpRequests(regeln -> regeln
        .requestMatchers(HttpMethod.GET, "/v1/haltepunkte/**", "/v1/monitor/**").permitAll()
        .requestMatchers(HttpMethod.POST, "/v1/angebote", "/v1/angebote/*/buchungen").hasRole("NUTZER")
        .requestMatchers("/error", "/h2-console/**").permitAll()
        .anyRequest().authenticated())

1. Ergänze die Zeile, mit der nur die Rolle NUTZER Gesuche einstellen darf, und gib an, wo sie stehen muss. (2 Punkte)

2. Ein Teammitglied hängt die neue Zeile hinter .anyRequest().authenticated() an. Was passiert beim Start der Anwendung bzw. der Controller-Tests, und warum ist das sinnvoll? (2 Punkte)

3. Was würde passieren, wenn die Zeile aus a) ganz fehlt? Welcher Test findet das? (2 Punkte)

        .requestMatchers(HttpMethod.POST, "/v1/gesuche").hasRole("NUTZER")

Caused by: java.lang.IllegalStateException: Can't configure requestMatchers after anyRequest

Aufgabe 2.2: Nur eigene Gesuche zurückziehen (Kernkompetenz)

Bisher sieht zieheZurueck im GesuchService so aus:

@Transactional
public Gesuch zieheZurueck(Long gesuchId) {
    Gesuch gesuch = gesuchRepository.findById(gesuchId)
            .orElseThrow(() -> new NichtGefundenException("Gesuch", gesuchId));
    gesuch.zieheZurueck();
    return gesuch;
}

1. Ändere die Methode so, dass nur die Person, die das Gesuch eingestellt hat, es zurückziehen darf. Andernfalls soll eine KeineBerechtigungException mit der Meldung „Nur wer das Gesuch 1 eingestellt hat, darf es zurückziehen.“ (für Gesuch 1) entstehen. Die Klasse Anmeldung aus dem Artikel steht zur Verfügung. (3 Punkte)

2. Schreibe zwei Komponententests mit Mockito: Oksana zieht ihr Gesuch zurück, und Lukas versucht es vergeblich. Prüfe im zweiten Test auch, dass das Gesuch offen bleibt. Das Gesuch legst Du im Test mit new Gesuch(oksana, guetersloh, Fahrtrichtung.ZUR_SCHULE, LocalDate.of(2026, 11, 23), LocalTime.of(6, 45), LocalTime.of(7, 15)) an. (4 Punkte)

@Transactional
public Gesuch zieheZurueck(Long gesuchId, Anmeldung anmeldung) {
    Gesuch gesuch = gesuchRepository.findById(gesuchId)
            .orElseThrow(() -> new NichtGefundenException("Gesuch", gesuchId));
    if (!gesuch.getNutzer().getId().equals(anmeldung.nutzerId())) {
        throw new KeineBerechtigungException("Nur wer das Gesuch " + gesuchId + " eingestellt hat, darf es "
                + "zurückziehen.");
    }
    gesuch.zieheZurueck();
    return gesuch;
}

@ExtendWith(MockitoExtension.class)
class GesuchServiceTest {

    private static final Anmeldung OKSANA = new Anmeldung(3L, Rolle.NUTZER);
    private static final Anmeldung LUKAS = new Anmeldung(4L, Rolle.NUTZER);

    @Mock
    private GesuchRepository gesuchRepository;

    @InjectMocks
    private GesuchService gesuchService;

    private Gesuch gesuch;

    @BeforeEach
    void oksanasGesuch() {
        var oksana = new Nutzer("Kaffeetasse", "Oksana", "Melnyk", LocalDate.of(2003, 4, 28), null, false);
        ReflectionTestUtils.setField(oksana, "id", 3L);
        var guetersloh = new Haltepunkt("Hauptbahnhof, ZOB Steig 3", "Gütersloh", new BigDecimal("18.6"));
        gesuch = new Gesuch(oksana, guetersloh, Fahrtrichtung.ZUR_SCHULE, LocalDate.of(2026, 11, 23),
                LocalTime.of(6, 45), LocalTime.of(7, 15));
        when(gesuchRepository.findById(1L)).thenReturn(Optional.of(gesuch));
    }

    @Test
    void eigenesGesuchZurueckziehen() {
        gesuchService.zieheZurueck(1L, OKSANA);

        assertThat(gesuch.getStatus()).isEqualTo(Gesuchstatus.ZURUECKGEZOGEN);
    }

    @Test
    void fremdesGesuchBleibtOffen() {
        assertThatThrownBy(() -> gesuchService.zieheZurueck(1L, LUKAS))
                .isInstanceOf(KeineBerechtigungException.class)
                .hasMessage("Nur wer das Gesuch 1 eingestellt hat, darf es zurückziehen.");
        assertThat(gesuch.getStatus()).isEqualTo(Gesuchstatus.OFFEN);
    }
}

Aufgabe 2.3: Den GesuchController mit Anmeldung testen (Kernkompetenz)

Schreibe eine Klasse GesuchControllerTest mit @WebMvcTest und drei Tests für POST /v1/gesuche mit dem Body {"haltepunktId": 1, "richtung": "zur-schule", "datum": "2026-11-24", "zeitVon": "06:45", "zeitBis": "07:15"}: (6 Punkte)

1. Oksana ist angemeldet: Antwort 201, mitfahrerId 3 in der Antwort, und der Service bekommt ein NeuesGesuch mit Nutzer-ID 3.
2. Ohne Anmeldung: 401, der Service wird nicht aufgerufen.
3. Angemeldet mit der Rolle ORGA: 403, der Service wird nicht aufgerufen.

Ein Hilfsobjekt gesuch4() (Gesuch 4 von Oksana am 24.11.2026) darfst Du voraussetzen; Importe musst Du nicht notieren.

@WebMvcTest(GesuchController.class)
@Import(SicherheitsKonfiguration.class)
class GesuchControllerTest {

    private static final String NEUES_GESUCH = """
            {"haltepunktId": 1, "richtung": "zur-schule", "datum": "2026-11-24",
             "zeitVon": "06:45", "zeitBis": "07:15"}
            """;

    @Autowired
    private MockMvcTester mvc;

    @MockitoBean
    private GesuchService gesuchService;

    @MockitoBean
    private AktuelleAnmeldung aktuelleAnmeldung;

    @Test
    @WithMockUser(username = "Kaffeetasse", roles = "NUTZER")
    void gesuchGehoertDerAngemeldetenPerson() {
        when(aktuelleAnmeldung.anmeldung()).thenReturn(new Anmeldung(3L, Rolle.NUTZER));
        when(gesuchService.stelleEin(any())).thenReturn(gesuch4());

        assertThat(mvc.post().uri("/v1/gesuche").contentType(MediaType.APPLICATION_JSON).content(NEUES_GESUCH))
                .hasStatus(HttpStatus.CREATED)
                .bodyJson().extractingPath("$.mitfahrerId").isEqualTo(3);
        verify(gesuchService).stelleEin(new NeuesGesuch(3L, 1L, Fahrtrichtung.ZUR_SCHULE,
                LocalDate.of(2026, 11, 24), LocalTime.of(6, 45), LocalTime.of(7, 15)));
    }

    @Test
    @WithAnonymousUser
    void ohneAnmeldungErgibt401() {
        assertThat(mvc.post().uri("/v1/gesuche").contentType(MediaType.APPLICATION_JSON).content(NEUES_GESUCH))
                .hasStatus(HttpStatus.UNAUTHORIZED);
        verifyNoInteractions(gesuchService);
    }

    @Test
    @WithMockUser(username = "Admin-AW", roles = "ORGA")
    void orgaStelltKeineGesucheEin() {
        assertThat(mvc.post().uri("/v1/gesuche").contentType(MediaType.APPLICATION_JSON).content(NEUES_GESUCH))
                .hasStatus(HttpStatus.FORBIDDEN);
        verifyNoInteractions(gesuchService);
    }
}

Aufgabe 3.1: HTTP Basic bewerten (Profilkompetenz)

In einem Mitschnitt des Netzwerkverkehrs im Schul-WLAN findet sich bei einer Anfrage an das Mitfahr-Backend über http:// diese Zeile:

Authorization: Basic S2FmZmVldGFzc2U6bWl0ZmFocmVu

1. Was lässt sich aus der Zeile ablesen, und was folgt daraus für den Betrieb? (2 Punkte)

2. Die Schulleitung möchte das Backend an der Schule einsetzen. Nenne zwei Schwächen von HTTP Basic für diesen Einsatz, die auch HTTPS nicht behebt. Beschreibe dann, was sich am Backend ändert, wenn die Anmeldung auf Keycloak mit OAuth2/OpenID Connect umgestellt wird, und was gleich bleibt. (4 Punkte)

Links und weitere Informationen

• zum Lehrartikel: Change Request: Anmeldung mit Spring Security nachrüsten

• als Grundlage: Authentifizierung, Passwörter und MFA, V-Modell

• als Nachschlagewerk: Spring Security – Autorisierung von HTTP-Anfragen, Spring Security – Testen mit @WithMockUser, RFC 7617 – The „Basic“ HTTP Authentication Scheme

Hinweis zur Nachnutzung als Open Educational Resource (OER)

Dieser Artikel und seine Texte, Bilder, Grafiken, Code und sonstiger Inhalt sind - sofern nicht anders angegeben - lizenziert unter CC BY 4.0. Nennung gemäß TULLU-Regel bitte wie folgt: “Übungsaufgaben zum Change Request Authentifizierung: Die Mitfahrgesuche absichern” von oer-informatik.de (H. Stein), Lizenz: CC BY 4.0. Der Artikel wurde unter https://oer-informatik.de/spring-boot-change-request-authentifizierung-uebungsaufgaben veröffentlicht, die Quelltexte sind in weiterverarbeitbarer Form verfügbar im Repository unter https://gitlab.com/oer-informatik/java-springboot/Backend. Erstellt mit KI-Assistenz; von mir umfassend redaktionell überarbeitet, geprüft und freigegeben. Stand: 11.11.2026.

[Kommentare zum Artikel lesen, schreiben] / [Artikel teilen] / [gitlab-Issue zum Artikel schreiben]