Jacek Pyziak
7b29fd9e02
Phase 3 complete: - Zmieniono _csrf_token -> _token w OrdersController (1x), ShipmentController (2x) - Zmieniono name="_csrf_token" -> name="_token" w orders/show.php (1x), shipments/prepare.php (2x) - Usunięto concern z .paul/codebase/CONCERNS.md Co-Authored-By: Claude <noreply@anthropic.com>
6.0 KiB
6.0 KiB
phase, plan, type, wave, depends_on, files_modified, autonomous
| phase | plan | type | wave | depends_on | files_modified | autonomous | ||||
|---|---|---|---|---|---|---|---|---|---|---|
| 03-tech-debt | 01 | execute | 1 |
|
true |
Uzasadnienie
OrdersController i ShipmentController czytają pole formularza _csrf_token, podczas gdy wszystkie pozostałe kontrolery (Settings, Auth, Users) używają _token. Widoki zamówień i przesyłek wysyłają token pod nazwą _csrf_token, co jest niezgodne z resztą aplikacji. Rozbieżność stwarza ryzyko użycia złej nazwy przy dodawaniu nowych formularzy i cichego złamania ochrony CSRF.
Wynik
Wszystkie formularze i kontrolery w aplikacji używają jednolitej nazwy _token dla pola CSRF. Concern usunięty z CONCERNS.md.
Pliki źródłowe
@src/Modules/Orders/OrdersController.php @src/Modules/Shipments/ShipmentController.php @resources/views/orders/show.php @resources/views/shipments/prepare.php
## Wymagane skille (z SPECIAL-FLOWS.md)| Skill | Priorytet | Kiedy wywołać | Załadowany? |
|---|---|---|---|
| sonar-scanner (CLI) | required | Po APPLY, przed UNIFY | ○ |
| /code-review | optional | Po implementacji, przed UNIFY | ○ |
BLOKUJĄCE: sonar-scanner MUSI być uruchomiony po APPLY, przed UNIFY.
Checklist
- sonar-scanner uruchomiony (po APPLY)
- /code-review (opcjonalnie)
<acceptance_criteria>
AC-1: Kontrolery używają _token
Given OrdersController i ShipmentController czytają pole CSRF
When aplikacja przetwarza POST z formularza zamówień lub przesyłki
Then kontrolery odczytują pole pod nazwą `_token` (nie `_csrf_token`)
AC-2: Widoki wysyłają _token
Given widoki orders/show.php i shipments/prepare.php renderują formularze
When strona zostanie wczytana
Then pola hidden mają atrybut name="_token" (nie name="_csrf_token")
AC-3: Ochrona CSRF działa po zmianie
Given aplikacja jest uruchomiona lokalnie
When użytkownik prześle formularz z widoku zamówień lub przesyłki
Then walidacja CSRF przechodzi i akcja wykonuje się poprawnie
</acceptance_criteria>
Zadanie 1: Zmień nazwę pola CSRF w kontrolerach src/Modules/Orders/OrdersController.php, src/Modules/Shipments/ShipmentController.php W obu plikach zamień wszystkie wywołania `$request->input('_csrf_token', '')` na `$request->input('_token', '')`.OrdersController.php: 1 wystąpienie (ok. linia 202)
ShipmentController.php: 2 wystąpienia (ok. linie 153 i 270)
Nie zmieniaj niczego poza samą nazwą pola — logika walidacji, zmienne, komunikaty błędów pozostają bez zmian.
Nie zmieniaj SESSION_KEY w Csrf.php — to jest klucz sesji (wewnętrzny), nie nazwa pola formularza.
resources/views/orders/show.php: 1 wystąpienie (ok. linia 67)
resources/views/shipments/prepare.php: 2 wystąpienia (ok. linie 108 i 141)
Nie zmieniaj niczego poza atrybutem name w tagach input hidden.
DO NOT CHANGE
src/Core/Security/Csrf.php— klasa Csrf nie jest zmieniana;SESSION_KEY = '_csrf_token'to wewnętrzny klucz sesji, nie nazwa pola HTTP- Wszystkie inne widoki i kontrolery korzystające już z
_token— nie wymagają zmian - Logika walidacji CSRF — zmieniamy tylko nazwę pola, nie algorytm
SCOPE LIMITS
- Ten plan dotyczy wyłącznie ustandaryzowania nazwy pola
_csrf_token→_token - Nie naprawiamy przy okazji innych problemów CSRF (rotacja tokenu, middleware) — to osobne concerny
- Nie modyfikujemy żadnych innych plików poza wymienionymi w
files_modified
<success_criteria>
- Wszystkie zadania ukończone
- 0 wystąpień
_csrf_tokenw src/ i resources/views/ (poza SESSION_KEY w Csrf.php) - Aplikacja działa poprawnie — formularze zamówień i przesyłek przechodzą walidację CSRF
- Concern usunięty z CONCERNS.md
- Brak nowych błędów PHP </success_criteria>