Updating Changelog

2026-09-15 16:02:20 +03:00
parent 8472649905
commit 409e8204f6
1 changed files with 32 additions and 0 deletions
@@ -4,6 +4,38 @@ All notable changes to this project will be documented in this file.
 The format is based on [Keep a Changelog](https://keepachangelog.com/en/1.1.0/).
 ## [Unreleased]
 ### Added
 - Customer-portal backend groundwork — no routes/controllers/views yet (a storefront-facing UI is
  3dealer's job once a frontend designer picks it up), but the boboko-owned services it needs to
  call now exist:
  - `Modules\Core\Auth\Services\UserOtpService::validate()` now actually logs the shopper in
    (`Auth::login()`, `web` guard) — previously it only returned the `User` model with no session
    established and no route/controller anywhere ever called it (the checkout page's "Login" tab
    was a disabled placeholder). `Auth::login()` alone is enough to merge/associate any active
    guest cart too — it fires `Illuminate\Auth\Events\Login`, which Lunar's own
    `Lunar\Listeners\CartSessionAuthListener` (registered unconditionally in core, no opt-in
    needed) already reacts to, honoring `config('lunar.cart.auth_policy')` (`'merge'` by default).
    An earlier draft of this also called `Cart::associate()` directly from this service — removed
    as redundant and actually wrong: it ran a second, separate association with a hardcoded
    `'merge'` policy that ignored whatever a consumer had actually set `auth_policy` to. Also fixed
    an unbounded brute-force window: a 6-digit code (1M combinations, was guessable for its full
    10-minute expiry with no attempt cap) now invalidates itself after 5 wrong guesses
    (`users.otp_attempts`, new column), forcing a fresh code request rather than leaving a live one
    guessable indefinitely.
  - `Modules\Core\Auth\Events\CustomerLoggedIn` — dispatched on every successful OTP login (new
    user or returning), for a storefront to hook into (e.g. post-login redirect, analytics).
  - `Modules\Core\Customer\Services\CustomerAccountService` — the storefront-facing "My Account"
    API (mirrors `CartService`/`CheckoutService`'s shape): `orders()` (paginated, placed orders
    only), `order()`, `addresses()`, `createAddress()`/`updateAddress()`/`deleteAddress()`,
    `updateProfile()`. Every method is scoped to the given user's own
    `latestCustomer()` — there is no method that accepts a bare order/address id without also
    requiring the owning user, so a controller built on top of this can't leak one customer's data
    to another by trusting a client-supplied id alone (verified live: a second customer attempting
    to read/edit the first's address or order gets `AddressNotFoundException`/
    `OrderNotFoundException`, not the record).
 ## [0.17.0] - 2026-09-14
 ### Added