pomysloweprezenty.pl/change.md

Zmiana: Fix przekierowania w summaryView

Plik

autoload/front/Controllers/ShopBasketController.php

Problem

Po złożeniu pierwszego zamówienia, próba złożenia drugiego zamówienia powodowała przekierowanie na stronę poprzedniego zamówienia (/zamowienie/{hash}) zamiast na stronę podsumowania koszyka (/koszyk-podsumowanie).

Przyczyna

W metodzie summaryView() był guard sprawdzający sesyjny klucz order-submit-last-order-id. Jeśli istniał (a istniał po każdym złożonym zamówieniu), metoda od razu redirectowała na stronę starego zamówienia — nigdy nie dochodziło do createOrderSubmitToken(), które czyści ten klucz.

Co usunięto

Usunięto blok (dawne linie 279-290):

$existingOrderId = isset( $_SESSION[ self::ORDER_SUBMIT_LAST_ORDER_ID_SESSION_KEY ] )
  ? (int)$_SESSION[ self::ORDER_SUBMIT_LAST_ORDER_ID_SESSION_KEY ]
  : 0;
if ( $existingOrderId > 0 )
{
  $existingOrderHash = $this->orderRepository->findHashById( $existingOrderId );
  if ( $existingOrderHash )
  {
    header( 'Location: /zamowienie/' . $existingOrderHash );
    exit;
  }
}

Zabezpieczenie double-submit

Ochrona przed podwójnym wysłaniem formularza pozostaje nienaruszona w metodzie basketSave() — tam ten sam mechanizm działa poprawnie.

---

Zmiana 2: Logowanie błędów w basketSave + naprawa tokena zamówienia

Plik

autoload/front/Controllers/ShopBasketController.php

Problem

Klientka nie mogła złożyć zamówienia — komunikat "Podczas składania zamówienia wystąpił błąd". Brak logowania uniemożliwiał diagnozę. Dodatkowo token zamówienia był jednorazowy i nadpisywany przy każdym wejściu na podsumowanie — otwarcie drugiej karty, użycie "wstecz" w przeglądarce lub odświeżenie strony unieważniało token i blokowało złożenie zamówienia.

Dodane logowanie do logs/logs-order-{data}.log

Dodana prywatna metoda logOrder() zapisująca do pliku logs/logs-order-YYYY-MM-DD.log (schemat jak logs-db-*).

Logowanie w 4 miejscach w basketSave():

1. Double-submit (pusty koszyk + istnieje stare zamówienie) — log: Double-submit detected, redirecting to existing order id=...
2. Token nieprawidłowy — log: Token validation failed. formToken=...
3. createFromBasket rzucił wyjątek — log: createFromBasket exception: ...
4. createFromBasket zwróciło falsy order_id — log: createFromBasket returned falsy order_id. client_id=... email=...

Naprawa tokena — z jednorazowego na czasowy (TTL 30 min)

Stare zachowanie

• createOrderSubmitToken() generował nowy token przy KAŻDYM wejściu na podsumowanie
• Każde otwarcie nowej karty/odświeżenie nadpisywało token w sesji
• Formularz w starej karcie miał stary token → walidacja failowała
• Przy nieudanej walidacji tokena redirect na /koszyk (użytkownik tracił cały kontekst)

Nowe zachowanie

• Dodana stała ORDER_SUBMIT_TOKEN_TTL = 1800 (30 minut)
• Token przechowywany jako ['token' => '...', 'created_at' => time()]
• createOrderSubmitToken(): jeśli istnieje ważny token (< 30 min), zwraca ten sam zamiast generować nowy
• isValidOrderSubmitToken(): sprawdza czy token nie wygasł + backward compatibility ze starymi stringowymi tokenami
• consumeOrderSubmitToken(): bez zmian — po złożeniu zamówienia token jest usuwany
• Przy nieudanej walidacji tokena redirect na /koszyk-podsumowanie (nowy token się generuje, użytkownik może od razu ponowić)
• Dodany osobny guard na double-submit: pusty koszyk + istniejące zamówienie w sesji → redirect na stronę zamówienia

Efekt

• Wiele kart z podsumowaniem → ten sam token → wszystkie działają
• Przycisk "wstecz" → token nadal ważny
• Odświeżenie strony → token nadal ważny
• Po 30 minutach token wygasa → redirect na podsumowanie, nowy token, ponów
• Po złożeniu zamówienia token jest konsumowany + koszyk czyszczony → double-submit chroniony
• Błąd tokena nie wyrzuca na /koszyk tylko na /koszyk-podsumowanie