feat(tenant): give a tenant pair to the children reachable by a request uuid
Phase 7 concluded that aggregate children needed no column of their own,
because every repository query anchors to its root. That was true of the
repositories, and it missed the case where the anchor never happens:
$item = $this->serviceItemRepo->findByUuid($data['service_item_uuid']);
A lookup by uuid is itself an unanchored query, and TenantFilter cannot help
when the table has no column to filter on. All three leaks phase 7 found had
exactly this shape, including the one that put another environment's service
price on a patient's invoice.
Measuring which children are actually loaded that way gives eight of the
twenty-five — service_items (15 call sites), patient_sessions (7),
session_payments, patient_notes, patient_calls, patient_messages,
patient_attachments, patient_medical_records. They now carry their own pair
and leave AGGREGATE_CHILDREN; the other seventeen are only ever traversed
from their root and stay as they were.
The pair is derived from the root inside the constructor rather than passed
in, so no creation site can forget it and the value has one source. A root
never changes environment, so the copy is written once and cannot drift.
This is defence at the data layer rather than at the entry point: a forgotten
guard now returns nothing instead of another environment's row. The existing
TenantOwnershipChecker guards stay as the outer layer.
Verified against an imported production database: 8 tables backfilled, zero
rows unmatched, zero rows inconsistent with their root. Dropping the column
again turns the leak test red.
Tests: 911 backend (+5). PHPStan unchanged at 17.
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
This commit is contained in:
@@ -100,9 +100,37 @@ clinic_uuid صریحِ درخواست > UserActiveContext ذخیرهشده
|
||||
|
||||
### ⚠️ فرزندان aggregate تور ایمنی ندارند
|
||||
|
||||
فیلتر روی آنها اعمال نمیشود. کوئری مستقیم روی `patient_attachments` بدون JOIN به `patient_records`، cross-tenant است. `TenantSchemaCoverageTest` فقط تضمین میکند زنجیرهٔ اعلامشده به ریشهای با جفت tenant میرسد — نه اینکه کوئریها واقعاً از ریشه شروع میشوند.
|
||||
فیلتر روی آنها اعمال نمیشود. کوئری مستقیم روی `service_item_consumables` بدون JOIN به ریشه، cross-tenant است. `TenantSchemaCoverageTest` فقط تضمین میکند زنجیرهٔ اعلامشده به ریشهای با جفت tenant میرسد — نه اینکه کوئریها واقعاً از ریشه شروع میشوند.
|
||||
|
||||
فرزندی که لازم است مالکیتش سنجیده شود، جفت ارثیاش را expose میکند؛ `ServiceItem` این کار را با delegate به `ServiceSection` انجام میدهد.
|
||||
**قاعدهٔ مرزبندی (فاز ۸):** فرزندی که uuidش از خودِ درخواست میآید، حق ندارد فرزند بماند.
|
||||
|
||||
```php
|
||||
$item = $this->serviceItemRepo->findByUuid($data['service_item_uuid']);
|
||||
```
|
||||
|
||||
این **خودش** یک کوئری بیلنگر است. فاز ۷ نتیجه گرفته بود فرزندان ستون لازم ندارند چون «هر کوئری repository به ریشه لنگر میزند» — که دربارهٔ DQLهای repository درست بود و همین حالت را ندید. هر سه نشتی فاز ۷ دقیقاً همین شکل بودند.
|
||||
|
||||
پس هشت فرزندِ قابلدسترس با uuid جفت محیط **خودشان** را گرفتند و دیگر در `AGGREGATE_CHILDREN` نیستند:
|
||||
|
||||
```
|
||||
service_items · patient_sessions · session_payments · patient_notes
|
||||
patient_calls · patient_messages · patient_attachments · patient_medical_records
|
||||
```
|
||||
|
||||
جفت در **سازنده** از ریشه مشتق میشود، نه از ورودی:
|
||||
|
||||
```php
|
||||
public function __construct(ServiceSection $section, ...) {
|
||||
$this->section = $section;
|
||||
$this->assignTenantPair($section->getEntityType(), $section->getEntityId());
|
||||
}
|
||||
```
|
||||
|
||||
دو خاصیت مهم دارد: هیچ نقطهٔ ساختی نمیتواند فراموشش کند، و چون محیطِ یک ریشه هرگز عوض نمیشود، این کپی write-once است و واگرا نمیشود.
|
||||
|
||||
۱۷ فرزند باقیمانده هیچکدام با uuid از درخواست لود نمیشوند (اندازهگیریشده، نه فرض) و فقط از ریشه پیمایش میشوند.
|
||||
|
||||
`RequestReachableChildTenantTest` این را **بدون هیچ گارد دستی** میسنجد: فقط خودِ فیلتر. با برداشتن ستون، همان نشتی مالی فاز ۷ برمیگردد و تست قرمز میشود.
|
||||
|
||||
### uuid از درخواست — خطرناکترین الگو
|
||||
|
||||
@@ -241,3 +269,5 @@ php bin/console app:tenant:dump --tenant=clinic:12 --output=/tmp/clinic12.sql
|
||||
| `tests/Settlement/FinancialChainTenantTest.php` | زنجیرهٔ مالی از راه لنگر به `payments` جدا میشود؛ کیف پول عمداً سراسری میماند |
|
||||
| `tests/PaymentMethod/PaymentMethodTenantTest.php` | کارتها per-محیطاند؛ ردیف بیمحیط دیده میشود ولی تا انتساب قابل ویرایش نیست |
|
||||
| `tests/Patient/PatientWalletTenantTest.php` | دفتر کیف پول per-محیط است ولی موجودی سراسری میماند |
|
||||
| `tests/Shared/RequestReachableChildTenantTest.php` | فرزندانِ قابلدسترس با uuid را **خودِ فیلتر** میبندد، بدون گارد دستی |
|
||||
| `tests/Auth/MultiClinicOwnerContextTest.php` | مالک چند کلینیک به هرکدام میتواند سوییچ کند |
|
||||
|
||||
Reference in New Issue
Block a user