Updating Changelog
This commit is contained in:
@@ -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/).
|
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
|
## [0.17.0] - 2026-09-14
|
||||||
|
|
||||||
### Added
|
### Added
|
||||||
|
|||||||
Reference in New Issue
Block a user