47 lines
3.4 KiB
Markdown
47 lines
3.4 KiB
Markdown
# Task: POS Login & Access Control Hardening
|
|
|
|
## Background
|
|
The user wants to ensure that `POS_TERMINAL` accounts, which are children of a `STORE_MANAGER`, can:
|
|
1. Access the POS for the store managed/owned by their parent.
|
|
2. NOT access the POS or data of other stores outside their parent's hierarchy.
|
|
3. NOT access features "above" their role (already partially handled by RBAC, but needs verification).
|
|
|
|
## Requirements
|
|
- [ ] **RBAC Verification**: Verify that `POS_TERMINAL` role contains the necessary permissions but doesn't overreach into `STORE_MANAGER` or `STORE_OWNER` territory.
|
|
- [ ] **Cross-Store Access Control**: Ensure `PosController` methods (`startSession`, `getTodayStats`, `getCustomers`, `getPosSessions`, `listHistory`) explicitly check if the authenticated user (especially `POS_TERMINAL`) is authorized for the requested `store_hash`.
|
|
- [ ] **Hierarchy Boundary**: Ensure `POS_TERMINAL` cannot access administrative pages or data that their parent (`STORE_MANAGER`) is restricted from (already base logic, but needs testing).
|
|
- [ ] **Testing Suite**: Create a comprehensive feature test to simulate the hierarchy and verify access attempts across multiple stores.
|
|
|
|
## Technical Approach
|
|
1. **Store Access Logic**:
|
|
- Create a static method in `UserPermissions` or a trait to check `isUserAllowedToAccessStore(User $user, Store $store)`.
|
|
- Logic:
|
|
- IF Ultimate user -> Allow.
|
|
- IF $user->id is $store->owner_id or $store->manager_id -> Allow.
|
|
- IF $user is an ancestor of $store->owner or $store->manager -> Allow.
|
|
- IF $user is a child of the store manager/owner AND role is `POS_TERMINAL` or `RIDER` -> Allow.
|
|
2. **Controller Hardening**:
|
|
- Update `app/Http/Controllers/Market/PosController.php` to use this check in all methods receiving a `store_hash`.
|
|
3. **Test Case**:
|
|
- `tests/Feature/PosAccessTest.php` will be created to automate these checks.
|
|
|
|
## Impact Analysis
|
|
- Refines security for multi-store environments.
|
|
- Ensures data isolation among different franchises or store locations.
|
|
## Verified Findings (as of 2026-04-03)
|
|
Based on the audit report in @[docs/tasks/pos-access-control-test-report.md], the following findings have been verified and need to be addressed:
|
|
|
|
- [x] **RBAC Status**: `POS_TERMINAL` has the necessary base permissions (`ViewPosReports`, `ViewCustomers`, `ViewUserInfo`, `ManageUserInfo`).
|
|
- [x] **Permission Gap**: `STORE_MANAGER` is missing the `CreateUserPOSTerminal` action permission in `UserPermissions::roles()`.
|
|
- [x] **Missing Helper**: `isUserAllowedAccessToStore` is not implemented in `UserPermissions.php`.
|
|
- [x] **Controller Security Gaps**:
|
|
- `PosController@startSession`: No store-level check or authentication for non-terminal logins.
|
|
- `PosController@getSession`: No store-level check.
|
|
- `PosController@getPosSessions`: Missing ALL permission/store-level checks.
|
|
- `PosController@getTodayStats`: Missing store-level check.
|
|
- `PosController@getCustomers`: Missing store-level check.
|
|
- [x] **Missing Infrastructure**: `isAncestorOf` helper is missing (needed for hierarchical store access).
|
|
- [x] **Missing Tests**: `tests/Feature/PosAccessTest.php` does not exist.
|
|
- [x] **UI Security**: `PosMain.vue` is functional but lacks any store-level authorization checks or error handling for unauthorized access.
|
|
- [x] **Performance Optimization**: `PosController` already uses `CacheHelper` and raw DB queries in some areas, but these need to be maintained during hardening.
|