fix(privacy): apply noindex+mask policy to machine-readable outputs (#173) - #183
LyuboslavLyubenov wants to merge 52 commits into
Conversation
lyubomir-bozhinov
left a comment
lyubomir-bozhinov
left a comment
There was a problem hiding this comment.
Добре структуриран — маскирането е на query слой преди R2, noindex-gate-ът на .json е чист, тестовете са солидни. Но тезата на PR-а („noindex+mask на всички machine-readable изходи") не е изпълнена докрай:
🔴 .data single-fetch payload е непокрита machine-readable повърхност. При ssr:true RRv7 сервира всеки loader и на GET /<път>.data. company.tsx loader-ът връща eik + displayName немаскирани, а headers() е publicCache(...) → отговорът минава през hardenResponse (само baseSecurityHeaders, без X-Robots-Tag) и се кешира на edge. Значи /companies/:eik.data връща немаскиран ЕИК на физическо лице, кеширан, без noindex — точно експозицията от #173, на повърхността, която PR-ът не изброява. (Потвърдих reachability-то на .data живо на публичния prod; robots.txt не покрива /*.data.) Поправка: приложи предиката/маската и за .data, или централизирай X-Robots-Tag в hardenResponse вместо per-route.
🟠 Sitemap-ът ползва по-тесния предикат. sitemaps.ts филтрира с isNaturalPersonProfileName (само по име), не с разширения isNaturalPersonBidder (+legal_form), който PR-ът ползва навсякъде другаде. ЕТ, разпознат само по legal_form, се маскира/noindex-ва навсякъде, но пак се рекламира в /sitemap-companies — каним crawl на страница, която политиката де-индексира.
За проверка (не потвърдено срещу данни): премахнатият consortium guard в isNaturalPersonBidder — нито един caller не филтрира kind==='consortium', та консорциум с водещ „ЕТ …" в името може да се over-маскира като „Частно лице". Струва си да се потвърди срещу корпуса, преди да се третира като дефект.
lyubomir-bozhinov
left a comment
lyubomir-bozhinov
left a comment
There was a problem hiding this comment.
Инлайн котви към горния преглед — .data single-fetch privacy gap.
|
Прегледах PR #183 изцяло — целия diff (24 файла, +1882/−45), всички коментари по ревюто, issue #173, както и текущото състояние на кода в работното дърво ( ОбобщениеЦентрализацията на Сигурност / SQL / OWASP
🔴 Съществени пропуски (data-integrity / поверителност)1. Подизпълнителят ( 2. Sitemap-ът ползва по-тесния предикат (незатворена забележка от предишното ревю). 3. HTML профилът скрива ЕИК на физическите лица — противоречи на собствената документация в PR-а. Споделеният loader прави 🟠 По-малки бележки4. 5. Възможно over-маскиране на консорциум. Съответствие с issue #173Ядрото на issue-то (bulk-indexable ЕИК на ЕТ в Бележки
Вердикт: Заявка за промени (Request changes) — блокиращо е т.1 (немаскиран ЕИК/име на подизпълнител-физическо лице в Благодаря за прегледната работа по маркерния договор и тестовете — след затварянето на горните пропуски PR-ът ще е в много добра форма. |
|
Блокерът е затворен — ре-проверих на връх
Точно това затваря находката ми (немаскиран ЕИК на физ. лице, кеширан, без noindex, изтичащ през Единствено: branch-ът е в конфликт с main ( |
…mber worker adr to 0008 Rebase of midt-bg#183 onto upstream/main (post-midt-bg#182 ADR reorganization) restructured the privacy-policy and worker-level X-Robots-Tag ADRs to live in docs/adr/ rather than inline in docs/architecture.md: - New docs/adr/0007-privacy-masking.md — content extracted from the inline ADR-0002 in architecture.md; relative paths adjusted (../ → ../../) for the new adr/ location; cross-link to the worker ADR now points to 0008. - docs/adr/0003-centralized-x-robots-tag-worker.md → docs/adr/0008-centralized-x-robots-tag-worker.md — renumbered to free the 0003 slot taken by upstream's value-flag ADR; internal cross-link from architecture.md#adr-0002-... to 0007-privacy-masking.md. - docs/adr/README.md — index extended with the two new entries. - docs/architecture.md — adopted upstream's short summary form; the inline ADR-0001+0002 contents are removed (the rendering ADR lives at adr/0001-rendering-and-security.md and the privacy policy at adr/0007-privacy-masking.md); Решения (ADR) section now also points to 0007 and 0008. - docs/privacy-masking.md — cross-link from architecture.md#adr-0002-... to adr/0007-privacy-masking.md; ADR-0003 to ADR-0008. No code changes; verified pnpm check:docs (docs-integrity gate from midt-bg#182) passes.
The three files modified by PR midt-bg#183 carried pre-existing prettier debt that the original review flagged (`pnpm lint` exit 1 with `contract.json.test.ts`, `companies.test.ts`, `companies.ts`). The repo's CI is configured as blocking lint (`2d93cd5`, comment in .github/workflows/ci.yml), so this would have blocked the PR from merging. Run `pnpm prettier --write` on the three files — no semantic changes.
|
Прегледах отново новия връх 1) Списък „Фирми" ( 2) Начална страница ( 3) Страница на договора ( 4) Подизпълнител.
Корен (altitude): маскирането е на leaf routes/exports, не на споделените проекции. Устойчивият фикс: маскирай в PR-ът затваря буквата на #173 (.json/.csv), но не и духа — ЕТ ЕИК на индексираните HTML страници. Блокер до фикса на споделените проекции. |
nedda76
left a comment
nedda76
left a comment
There was a problem hiding this comment.
Прегледах PR-а спрямо #173. Механиката marker→header е добре построена и тествана: CSV се маскира преди записа в R2, worker-ът слага X-Robots-Tag: noindex и трие marker-а преди edge cache (cache-safe — app.nofollow.test.ts го покрива). Но маската не покрива всяка machine-readable повърхност и на места е обезсилена — има потвърдени пътища, по които суровият ЕИК на физическо лице все още изтича. Тоест PR-ът още не затваря #173.
Блокиращи — потвърдени течове на суров ЕИК
-
slugпресейва ЕИК-а. Маската нулираeik, но оставяslug— а за eik-базирани субектиslugе самият нормализиран ЕИК (companySlug('eik:222222222') === '222222222'). Тоестbidder.slug/company.slugв/contracts/:id.jsonи/companies/:eik.dataносят точно идентификатора, който маската маха. ADR-0007 („slug-ът не е PII") не важи за физически лица — а те са именно маскираната популация. -
/contracts/:id.dataне е маскиран. HTML маршрутътcontract.tsxе недокоснат; приssr:truesingle-fetch/contracts/:id.dataсервира payload-а на loader-а машинно четимо —bidder.eikиsubcontractor.eik, без noindex..jsonе маскиран, но.dataблизнакът му — не (точно класът повърхности, заради който съществува ADR-0008). -
Подизпълнителят не се маскира.
maskContractForPrivacyпипа самоbidder+sourceNames.bidder;subcontractorминава непокътнат, а подизпълнителят може да е ЕТ/физическо лице → ЕИК изтича. Рядко (~0.8% от договорите), но реален непокрит път. -
/companies.data(списък) не е маскиран./companies.csvе, но.dataблизнакът на списъчния маршрут връщаCompanyListItemсъс суровeik+ име за физически лица → точно „bulk searchable/downloadable" вредата от #173, само през.dataвместо.csv.
За обсъждане — по-нисък приоритет
- Мрежовият граф в маскирания
company.dataноси node id-таeik:<ЕИК>→ физическо лице като възел изтича ЕИК. Частично фундаментално за eik-базираните id-та (като #1). - Регресия за легитимни фирми: предикатът пада към name-евристика (
ЕТ/ETпрефикс) дори при реаленlegal_form(ООД) → фирма с име „ET Engineering" получава скрит валиден ЕИК (нарушава изискване #5). Евристиката е заварена, но сега тя контролира скриване на ЕИК, не само мек noindex — цената на false positive расте. - Несъгласуваност:
.json/.csvзаменят името с етикет, ноcompany.data/HTML пазят ЕТ името дословно. Трите machine-readable пътя маскират различни полета.
Чисто (за фокус)
marker→header плъмбингът и cache safety; обединеният предикат isNaturalPersonBidder (и двата source() клона проектират legal_form); запазеното показване на юридически лица по покритите пътища; authorities.csv (публични органи — умишлено без body-маска).
Коренът на #1/#2/#4 е един: маската покрива .json/.csv, но не и .data близнаците и не пипа slug. Докато .data повърхностите и slug не се покрият, #173 остава отворен.
ydimitrof
left a comment
ydimitrof
left a comment
There was a problem hiding this comment.
Преглед на PR #173 — „fix(privacy): noindex + маскиране за машинно-четими изходи"
Какво прави PR-ът
Прилага политика за поверителност върху машинно-четимите изходи (turbo-stream .data, JSON, CSV), така че идентификаторите и имената на физически лица/ЕТ да бъдат маскирани, а не само маркирани с noindex. Архитектурата е чиста и с ясно разделение на отговорностите: route-овете маркират чрез markPrivacyMaskApplied, worker-ът превежда маркера в X-Robots-Tag: noindex чрез applyPrivacyMaskHeaders и го изтрива преди кеш/клиент. Въвежда се единен предикат isNaturalPersonBidder и константа MASKED_NATURAL_PERSON_LABEL в @sigma/shared, преизползвани в streamCompaniesCsv и streamContractsCsv; legal_form се прокарва коректно през двата клона на source() и през getContract.
Сигурност (Фаза 0)
ЧИСТО и в двете партиди — няма зашити тайни/ключове, нови зависимости, нови или подозрителни URL адреси, нито зловредни шаблони. Промяната всъщност намалява изтичането на лични данни. Тестовото покритие е силно и смислено: покрити са MISS/HIT/dynamic, идемпотентност, edge-cache инвариантите, негативните случаи, двата клона на source(), name-евристиката при legal_form=null и таблица на истинност на предиката. Документацията (ADR-0007, ADR-0008, privacy-masking.md) е изчерпателна и синхронизирана с кода.
Блокираща забележка
- (Средно — поверителност/консистентност) Машинно-четимият близнак
/companies/:eik.dataизчиства самоcompany.eik, но връща пълното име на физическото лице (displayName) буквално — за разлика от/contracts/:id.jsonи CSV, които заменят името сMASKED_NATURAL_PERSON_LABEL. Тъй като.dataе машинно-четим изход, а самата обосновка на PR-а (ADR-0007) гласи, чеnoindexе недостатъчен срещу ботове, оставянето на суровото име само задnoindexпротиворечи на декларираната цел. Тестътcompany.data.test.tsдори утвърждава това като очаквано. Нужно е явно решение: да се маскира името и в.data, или изрично да се документира защо.dataостава немаскиран.
Некритични забележки
- (Ниско — поверителност) При маскиране
bidder.slug/company.slugсе запазват. Ако slug-овете се извеждат от името на субекта, URL-фрагментът може да разкрие идентичността въпреки маскирането наname/eik. ADR-0007 приема slug като „URL фрагмент, не PII", но не адресира случая на slug, изведен от име. - (Ниско — точност на маскирането)
isNaturalPersonBidderсе вика без предварителна проверка заbidder_kind, въпреки че документацията му възлага филтрирането на консорциумите на викащия. Консорциум с име, започващо с „ЕТ ", ще бъде over-маскиран като „Частно лице" — privacy-safe, но с загуба на информация. - (Ниско — DB/производителност) Клонът по подразбиране на
source()вече винаги правиLEFT JOIN bidders, а това е и hot path заlistCompanies. Да се потвърди, чеcompany_totalsняма собствена колонаlegal_form(иначеct.*+b.legal_formдава двусмислена дублирана колона) и че има индекс поbidders.id. - (Ниско — дублиран/мъртъв код) Няколко случая на дублиране, противоречащи на правилото „NO CODE DUPLICATION": излишните предварителни извиквания на
markPrivacyMaskAppliedвresponseFromR2Object(csv-export.ts), коитоmarkCsvCacheведнага презаписва; и inline вариант на правилата заlegal_formвapps/web/app/routes/company.tsx. - (За потвърждение)
details.tsпрокарваbidder_legal_formбез маскиране и без тест в прегледаната партида — да се потвърди, че JSON маскирането се извършва другаде.
Вердикт
Промяната е висококачествена и без изтичане на данни в прегледаните файлове. Единствената блокираща точка е несъответствието в поверителността при /companies/:eik.data (т.1) в PR, чиято цел е именно защита на лични данни — тя трябва да бъде адресирана или изрично обоснована преди одобрение. Останалите забележки са некритични.
lyubomir-bozhinov
left a comment
lyubomir-bozhinov
left a comment
There was a problem hiding this comment.
Благодаря — маскирането на .json и CSV е издържано. Но остава отворена точно най-чувствителната machine-readable повърхност, заради която е #173: detail страницата на договора и нейният .data twin.
apps/web/app/routes/contract.tsx — loader-ът (:62-67) връща { contract } суров; файлът не се пипа в този PR и няма нито маска, нито noindex. getContract селектира b.eik_normalized AS bidder_eik (packages/db/src/queries/details.ts:440) и го отдава суров (:583 eik: r.bidder_eik, :595 eik: r.subcontractor_eik). contract.tsx ги рендира без маска — :221 ЕИК на изпълнителя, :261 ЕИК на подизпълнителя. Worker-ът прилага само applyPrivacyMaskHeaders(headers) (header-only, noindex) — няма body маска на ниво worker.
Ефект (prod е публичен, unauthenticated):
GET /contracts/<slug>.data→ turbo-stream body сbidder.eik/subcontractor.eikна физическо лице (ЕТ), немаскиран и безX-Robots-Tag.GET /contracts/<slug>(HTML) → същият ЕИК, индексируем.
Същата политика, различно прилагане и на списъците:
/companies.data:toCompanyListItem(packages/db/src/queries/rows.ts:58) връщаeik: r.eikбезisNaturalPersonBidderпроверка, докато/companies.csvго маскира./contracts.data:toItemвcontracts.tsдава немаскирани имена на физически лица (CSV пътят вече маскира).
Предложение: маскирай в споделения слой — в getContract, или в loader-а на contract.tsx огледално на company.tsx:77-85 — за да го наследят HTML, .data и .json, вместо per-route. Същото за toCompanyListItem (редът вече носи legal_form) и за подизпълнителя в maskContractForPrivacy.
Докато .data twin-ът не минава през същата маска като .json, #173 не е затворен. Проверих горните редове на HEAD (468a116). Блокиращо за merge.
…port The R2-body branch (responseFromR2Object) and the 304 branch each called markPrivacyMaskApplied directly, then handed the response to markCsvCache, which calls it again internally. The marker was applied twice on MISS/HIT/304 paths — idempotent in effect, but dead code that hid markCsvCache as the single source of truth for the privacy marker on every CSV path (PR midt-bg#183 review T-004, "NO DEAD CODE / NO CODE DUPLICATION"). Drop the direct calls; rely solely on markCsvCache. Add a TDD guard that spies on markPrivacyMaskApplied and asserts exactly one call per response path (MISS/HIT/dynamic/304), so a future duplicate cannot sneak back in.
…ortium over-masking isNaturalPersonBidder's docstring delegates consortium filtering to the caller — a JV is a legal entity even if a lead member's name / legal_form matches a sole-trader signal. But streamContractsCsv and streamCompaniesCsv both invoked it WITHOUT a bidder_kind guard, so a consortium such as "ЕТ Иван Петров; Строй ООД" (or any consortium whose legal_form collided with a sole-trader form) was masked to MASKED_NATURAL_PERSON_LABEL with its ЕИК cleared. The result was privacy-safe (over-masking, no leak) but a behavioral change that dropped the lead member's name + ЕИК and contradicted the predicate's contract. Add an early bidder_kind/kind !== 'consortium' guard in both streamers so consortium rows keep the "… и др." shape and their ЕИК. TDD: failing tests first (consortium with ЕТ lead name + ЕТ legal_form, and the leading-ЕТ name heuristic with legal_form null), then the guard (PR midt-bg#183 T-006).
…ne duplication) The docstring claimed the legal_form rules were "carried inline in apps/web/app/routes/company.tsx until the route migrates" — but ADR-0007 §1 already removed the legacy inline isSingleNaturalPersonProfile, and company.tsx now calls this shared predicate directly (verified: no legal_form string- matching exists outside packages/shared). The stale claim created exactly the divergence risk the PR midt-bg#183 reviewer flagged under "NO CODE DUPLICATION": a future reader could believe a second copy still lives in the route and maintain it separately. Rewrite the docstring to state the predicate is the single source of truth and enumerate the downstream surfaces that consume it (HTML noindex, CSV masking, JSON masking), with a pointer to the bidder_kind/kind consortium guards added in the CSV streamers (PR midt-bg#183 T-006). No behavior change.
…6, §7) Two PR midt-bg#183 review threads asked for explicit product decisions on the company profile masking surface. Both are recorded here as policy. §6 — displayName stays visible in the HTML profile and its `.data` twin; only the ЕИК is masked. The trading name is PUBLIC (rendered verbatim on the HTML page and in <title>); the sensitive natural-person identifier is the ЕИК. The `.data` turbo-stream is React Router v7's single-fetch transport for client-side navigations, NOT a standalone export like /contracts/:id.json — masking the name there would break client-rendered pages. Consistent policy: name = public, ЕИК = sensitive. company.tsx loader comment now states this; the company.data.test.ts assertion locks displayName-verbatim + eik-null as the contract. §7 — the name-keyed natural-person slug (n + base64url(name)) is a tracked limitation, not changed in this PR. The name is public (§6), the sitemap already filters these records, and reworking the slug scheme is cross-cutting (URL stability, internal links, identity system) and out of scope for a masking PR. No behavior change.
|
Прегледах #183 на дълбочина срещу head Силната част (потвърдено):
MAJOR 1 — JSON masker-ът НЯМА consortium guard-а, който CSV пътят има. MAJOR 2 — най-изложената повърхност остава отворена: страницата на договора + MAJOR 3 (test-gap + архитектура) — препращането на маркера към worker-а за MINOR — не-ЕТ физически лица могат да минат немаскирани. NIT — PR-ът е CONFLICTING спрямо main — нужен е rebase (отделно от горното). Насоката е правилна; двата masker-а — consortium guard в JSON и покриване на страницата/ |
… path The `/contracts/:id.json` masker (`maskContractForPrivacy`) lacked the `bidder_kind !== 'consortium'` guard that the CSV streamer already has (`contracts.ts:459`). A consortium whose display name begins with „ЕТ " (first member is a sole trader, e.g. „ЕТ Иван Петров; Строй ООД") was over-masked to „Частно лице" — losing the „… и др." shape, the consortium ЕИК, and gaining an unearned `noindex`. `isNaturalPersonBidder`'s docstring delegates consortium filtering to the caller; this adds the caller guard, mirroring the CSV path exactly. Flagged as MAJOR 1 in the PR midt-bg#183 review of head a9b18ae. TDD: failing consortium cases first (name-based + legal_form-based, plus a loader-level marker-omission case), then the guard.
`contract.tsx` was the most-indexable surface still open: its loader returned
`{ contract }` raw with no privacy marker, `robots.txt` does not block
`/contracts/:id` (or its `.data` twin), and the page rendered `c.bidder.eik`
verbatim — so a sole-trader's ЕИК was indexable on both the HTML page and the
RRv7 single-fetch `.data` payload. That is a worse exposure than the already-
closed `.json`/`.csv` paths.
Masking + signalling in the SHARED loader covers both surfaces at once (the
`.data` twin reuses the same loader), mirroring `company.tsx:89` exactly:
ЕИК (the sensitive natural-person ID) → null on the returned object, the
trading displayName stays PUBLIC (ADR-0007 §6), and the `X-Privacy-Mask:
applied` marker is translated to `X-Robots-Tag: noindex` by the worker. The
`kind === 'consortium'` guard matches the JSON masker (MAJOR 1) and the CSV
streamer so a JV is never over-masked/noindexed. `headers()` forwards the
marker onto the HTML response (RR does not auto-propagate loader headers).
Flagged as MAJOR 2 in the PR midt-bg#183 review of head a9b18ae.
TDD: failing loader/headers/pipeline cases first, then the loader change.
…eal worker The PR midt-bg#183 review (MAJOR 3) noted the marker→`.data`→`X-Robots-Tag` forwarding was only proven through fixtures that INJECT the marker by hand in the stubbed RR handler — which proves the worker CAN translate a marker, not that a real loader's marker survives the pipeline to the final `.data` HTTP response. That left a „green tests, hidden gap" risk on the most-indexable surface. Add four cases driving the REAL `worker.fetch` (→ handleRequest → hardenResponse → applyPrivacyMaskHeaders → edgeCache.put) against `/contracts/<x>.data`: masked sole-trader → noindex + marker stripped + masked body preserved; cached entry carries noindex (HIT-path invariant); second request HITs and serves noindex verbatim; legal-entity negative (no marker → no noindex). The handler returns the exact shape `contract.tsx`'s masked loader branch now produces (MAJOR 2), so this is an honest end-to-end proof of the forwarding guarantee. Note: the review's suggested path-based worker match (the weekly-digest `DIGEST_DETAIL_PATH` precedent) does not exist in this codebase — the worker does no path-based matching; the marker-based design (ADR-0008) is the established architecture and is sound, so this keeps it.
|
@lyubomir-bozhinov Благодаря за задълбочения adversarial pass — трите MAJOR забележки са затворени в три фокусирани комита върху MAJOR 1 — consortium guard в JSON masker-а ( MAJOR 2 — маскиране на страницата на договора + MAJOR 3 — end-to-end доказателство, че маркерът достига Забележка към предложението ти за path-based worker match (седмичният digest За останалите ти точки (не са код-промени в този PR):
Rebase: PR-ът е Пълна локална проверка: |
…-Mask marker The literal X-Robots-Tag header is no longer set anywhere in apps/web; it is now written by exactly one helper (applyPrivacyMaskHeaders in apps/web/app/lib/security.ts), called by the worker hardenResponse after the base security headers and before the cacheable-HTML branch. A new internal marker X-Privacy-Mask: applied is the route-side signal that the response carries masked natural-person data. Route handlers (csv-export.ts markCsvCache + 304 branch, contract.json.tsx loader) and the worker consume that marker; it is deleted unconditionally before the response is returned or stored in edgeCache.put so it never reaches clients. The HIT path in handleRequest (apps/web/workers/app.ts) is unchanged: it copies cached.headers verbatim, and the cached entry is the post-hardenResponse response, so the header survives the edge cache by construction. apps/web/workers/app.nofollow.test.ts (T-005 + T-008) exercises the end-to-end worker flow for the .data twin of /companies/:eik and the contract.json natural-person branch. No edits to packages/db or to the public API contract; bidders.legal_form stays server-only and company.eik stays on the CompanyRecord type (masked to null by the loader, not removed).
…ough headers()
The single-fetch .data twin of the company profile now clears company.eik to null
on the natural-person branch (per isNaturalPersonBidder) and signals the
worker via the internal X-Privacy-Mask: applied header on the Response.json
return. The route's headers() export now destructures { loaderHeaders } from
Route.HeadersArgs and forwards the marker explicitly so the worker
hardenResponse can translate it into X-Robots-Tag: noindex on the HTML
response (getDocumentHeadersImpl only auto-propagates Set-Cookie).
Legal-entity records keep the plain-object return unchanged — no marker, no
mutation, no Response.json wrap. The not-found short-circuit (throw new
Response('Not Found', ...)) runs before the masking gate, so 404s never
carry the marker.
The HTML meta() noindex branch is unchanged — natural-person pages
continue to emit <meta name="robots" content="noindex"> via the existing
seoMeta + isNaturalPersonBidder gate. The new headers() forward adds a
redundant X-Robots-Tag: noindex HTTP header alongside the meta tag, which
is acceptable (the worker translates the marker for all responses).
apps/web/app/routes/company.data.test.ts is the focused new test suite
(7 tests across 5 describe blocks): natural-person loader return asserts
company.eik === null and X-Privacy-Mask: applied; legal-entity loader
return asserts a plain object with eik unchanged and no marker; headers()
test exercises both branches (marker present → forwarded + Cache-Control;
marker absent → Cache-Control only); meta() test covers the natural-person
noindex HTML tag; the worker-pipeline describe calls applyPrivacyMaskHeaders
on the loader return and asserts X-Robots-Tag: noindex is set while
X-Privacy-Mask is stripped, proving the worker translate end-to-end.
…rage
ADR-0002 (docs/architecture.md): the Решение section now describes the
centralized X-Robots-Tag: noindex write site (hardenResponse in
apps/web/workers/app.ts, via the applyPrivacyMaskHeaders helper in
apps/web/app/lib/security.ts). The bullet on per-route CSV/contract-json
writes is replaced by a single sentence naming hardenResponse, the marker
flow, and the deletion pre-edgeCache.put.
The Засегнати повърхности list grows to explicitly enumerate:
- the .data twin of /companies/:eik (React Router v7 single-fetch,
automatic via the shared loader in company.tsx)
- apps/web/workers/app.ts (hardenResponse) as the centralized
enforcement point under a new 'Worker — централизирана точка за
прилагане' sub-heading
- apps/web/app/lib/security.ts as the policy helper home, with
PRIVACY_MASK_APPLIED as the literal-typed constant.
The privacy page (apps/web/app/routes/privacy.tsx) #natural-person-data
section grows to enumerate /companies/:eik.data alongside the existing
/contracts/:id.json and the three CSV exports. A follow-up paragraph in
Bulgarian prose explains that the X-Robots-Tag: noindex policy is now
applied uniformly at the worker edge so future machine-readable surfaces
inherit it automatically — without naming the X-Privacy-Mask marker or
the helper functions (user-facing wording only).
No edits to package.json, pnpm-lock.yaml, or the public API contract.
Daily autonomous review — ydimitrof 2026-08-31 batch (9 нишки)Пропуснах тези 9 нови нишки в предишния си дневен преглед (те бяха публикувани в 18:36 EEST, ~8 часа след моя Aug-31 pass). Днес адресирах всичките. Имплементирано (6 commit-а, fast-forward на
|
| Commit | Нишки | Промяна |
|---|---|---|
e9e9f36 feat(db): surface masked boolean and lock eikValid with eik on the leaderboard list |
companies.tsx:84, rows.ts:80 | CompanyListItem.masked: boolean от toCompanyListItem; eikValid lock-step с eik |
5939b10 fix(web): drop privacy-mask forwarding to leaderboard HTML and unlink masked rows |
companies.tsx:61, rows.ts:74 | headers() не форвардва X-Privacy-Mask към HTML; маскирани редове рендерират <span> не <Link> |
13fca7b fix(web): zero eikValid and hasEik on masked company profile loader |
company.tsx:114 | Loader-ът занулява eikValid/hasEik заедно с eik |
e7c55a1 fix(web): strip server-only bidder_legal_form on contract page loader |
contract.tsx:139 | stripServerOnlyFields паритет с contract.json.tsx на двете повърхности |
fed1c24 fix(web): stamp privacy marker in contract.json.tsx per ADR-0040 |
contract.json.tsx:91 | markPrivacyMaskApplied вместо директен X-Robots-Tag |
4b352ae refactor(db): drop redundant bidder_legal_form projection in CSV streamer |
contracts.ts:466, contracts.ts:448 | Мъртъв дублиран SELECT и излишно поле в CsvRow |
Тестове
pnpm --filter @sigma/db exec vitest run src/queries/rows.test.ts→ 19/19 (1 нов)pnpm --filter @sigma/db exec vitest run src/queries/contracts.test.ts→ 16/16pnpm --filter @sigma/web exec vitest run --config vitest.config.ts→ 585/585 (нови:companies.render.test.tsx, разширениcompany.data.test.ts,contract.data.test.ts,contract.json.test.ts)apps/web/test/integration/(sqlite3-зависими) не се пуснаха в тази среда — липсваsqlite3binary, инфраструктурно ограничение, не е регрес.
Дизайн решения
- Thread Add OG/Twitter meta, JSON-LD schema, sitemap #1 (companies.tsx:61) — ydimitrof е прав: маскираните редове рендерират само „Частно лице“ + null ЕИК в HTML, което не разкрива лични данни. Noindex на цялата публична страница е SEO регрес. Маркерът остава САМО на
.dataблизнака (RRv7 single-fetch), HTML-ът е чист. Политиката: privacy сигналът принадлежи на машинно-четимата повърхност, не на публичната HTML. - Thread Грешка при опит за зареждане на "още X институции - виж всички договори" #2 (companies.tsx:84) —
masked: booleanе новият единствен източник на истина за маскиращия сигнал;c.name === MASKED_NATURAL_PERSON_LABELе премахнат. - Thread fix(security): harden CI, deps, and agent config #6 (rows.ts:74) — Маскираните редове не се свързват (не рендерират
<Link>); ЕИК-ът не се появява в нито единhrefна публичната HTML. Маскираният профил остава достъпен от договорната страница (noindex-ната), не от лидерборда. - Thread fix(web): retry transient D1 read failures on entity loaders #5 (contract.json.tsx:91) — Спазвам ADR-0040 буквално: route-ът маркира, работникът превежда.
Финално състояние
mergeable: MERGEABLE,mergeStateStatus: BLOCKED(branch-protection, очаквано за fork PR)- Head:
4b352ae - 24 review threads, 0 нерезолювани.
- Остава: чакаме maintainer одобрение за rebase-merge (последен блокер е branch-protection re-approval на новия head).
lyubomir-bozhinov
left a comment
lyubomir-bozhinov
left a comment
There was a problem hiding this comment.
Прегледах делтата на #183 (6 комита, 16b4a5c8..4b352ae6) — по същия строг праг (моя PR, без изключения). Пет от шест са чисти; един реален пропуск в маскирането на списъка.
MAJOR — маскираните ЕТ реда още сериализират голия ЕИК в slug на индексируема повърхност.
toCompanyListItem маскира name/displayName/eik/eikValid/hasEik за физически лица (коректно, in lock-step), и render-ът показва маскирания ред като не-линк <span> (companies.tsx:174) — цитирам коментара (companies.tsx:168-170): „companySlug за eik:<digits> връща цифрите дословно, тъй че <Link> би издал ЕИК-а." НО slug полето остава немаскирано: rows.ts:86 slug: companySlug(r.bidder_id) → за eik:-ключиран ЕТ това е голият ЕИК (identity.ts:27 bidderId.slice(4)). Полето влиза в loader payload-а, който RRv7 сериализира на ДВЕ индексируеми места:
/companies.data—headers()(companies.tsx:48-61) връща самоCache-Control, не пре-емитваX-Privacy-Mask. При RR 7.18 headers-ите на.dataна нормален route идват отheaders()export-а (не от суровия loader Response — това важи за resource routes); потвърдено от sibling-итеcompany.tsx:59/contract.tsx:111, които ПРЕ-емитват маркера. Значи.dataняма noindex.- SSR hydration-а на самата HTML страница (нарочно индексируема —
companies.tsx:49-58).
Резултат: скрейпър, четящ view-source или/companies.data, връзва натурален ЕИК ↔ „Частно лице" — точно линкът, който маската съществува да пресече. Визуалният render е окей; пропускът е че маската е на name/eik, но не и наslug.
Fix: не емитвай реалния ЕИК-slug за маскирани редове (те са non-navigable — не водят към detail). Внимание:getKey={(c) => c.slug}(companies.tsx:249) е вързан за slug, тъй че за маскираните дай opaque, не-ЕИК ключ (неnull— ще колапсира ключовете). След това slug е ЕИК-чист и „индексируем leaderboard" дизайнът е съгласуван (въпросът за .data noindex отпада).
Чисто (потвърдено): company.tsx detail (13fca7b) — маскиран клон нулира eik/eikValid/hasEik, headers() пре-емитва маркера (:59) → /companies/:eik.data noindex; contract.json.tsx (fed1c24) resource route, маскира + strip bidder_legal_form на трите клона + маркер; contract.tsx (e7c55a1) strip на двата клона; CSV drop (4b352ae) наистина беше redundant (base SELECT вече проектира legal_form, contracts.ts:117), маската държи. listCompanies проектира legal_form и на двата пътя (companies.ts:103/127) — предишният no-such-column bug е затворен.
Verdict: един MAJOR (slug=ЕИК на маскирани редове), останалото чисто.
… rows
For a masked sole-trader / natural-person row, the list mapper used to return
the bare ЕИК in `slug` (e.g. `'121817309'`), because `companySlug('eik:121817309')`
returns the digits verbatim. The slug is serialised on `/companies.data` (RRv7
single-fetch turbo-stream, machine-readable twin of the leaderboard) and on the
HTML hydration payload of the public indexable leaderboard — so even though masked
rows render as a non-link `<span>` in companies.tsx already, the ЕИК still leaks
through the JSON payload and is reachable by any consumer reading the response
body (curl, a search-engine scraper, an attacker snapshotting the leaderboard).
`getKey` on companies.tsx:249 uses the slug as the React row key, so the slug
must remain unique per row, but it no longer needs to round-trip to a bidder_id
for masked rows — those are not linkable from the public leaderboard by design.
Add `maskedCompanySlug(bidderId)` in identity.ts — a one-way `m<base64url(bidder_id)>`
token that is stable across rebuilds (depends only on the bidder id), does NOT
contain the ЕИК or the raw name, and does NOT round-trip via `bidderIdFromSlug`
(the `m` prefix is not handled by the decoder — masked slugs return null). The
`m` prefix keeps opaque tokens separate from `n` (name-keyed, round-trippable)
and bare ЕИК digits. Wire it through `toCompanyListItem` so the masked branch of
the mapper produces the opaque form; the legal-entity and consortium branches
are untouched and still return the round-trippable `companySlug`.
TDD:
- New test in rows.test.ts asserts masked rows produce a slug that does NOT
decode via bidderIdFromSlug and does NOT contain the bare ЕИК digits, while
legal-entity and consortium rows keep the bare ЕИК (round-trippable).
- New describe in identity.test.ts covers maskedCompanySlug directly:
prefix-is-`m`, non-round-trippable, no ЕИК digits in the output, stable and
unique per bidder id, and handles name-keyed ids the same way (no key/name
leaks in the slug).
- companies-rollup-sql.test.ts updated to find the masked list row by its
masking signal (`i.masked && i.eik === null`) — the slug is opaque now and
cannot be grepped by ЕИК digits.
lyubomir-bozhinov review 2026-09-02, thread on packages/db/src/queries/rows.ts:86.
Verification:
- pnpm --filter @sigma/db exec vitest run src/queries/ → 24 files / 230 tests green.
- pnpm --filter @sigma/shared exec vitest run → 4 files / 60 tests green.
- pnpm --filter @sigma/web exec vitest run → 49 files / 588 tests green.
- pnpm exec prettier --check (touched files) → clean.
The home top-10 (`/topCompanies`) is the public indexable summary page that
mirrors the leaderboard. Before this fix, masked sole-trader rows rendered as
`<Link to={`/companies/${c.slug}`}>` with `c.slug` being the bare ЕИК —
tying the masked name to its identifier on the most public surface of the site
(both via the clickable href and the inline "ЕИК …" / "непотвърден ЕИК"
subtitle). The previous fix to companies.tsx (ydimitrof review 2026-08-31) only
covered the /companies leaderboard; home.tsx kept the same leak.
After the sibling commit that makes masked slugs opaque (`m<base64url(bidder_id)>`,
non-round-trippable), this leak turned into a 404 — clicking the masked row
would land on a URL that does not resolve. So the home top-10 must mirror the
leaderboard's branch: render masked rows as a non-link `<span>`, drop the
"ЕИК …" / "непотвърден ЕИК" subtitle (the masked row has no valid ЕИК to
display, and the "непотвърден ЕИК" fallback is wrong for masked sole traders
— they are neither unconfirmed nor legal), and drop the OwnershipChip.
Masked rows are reachable via direct URL or via the noindexed contract-page
backlink — never via a clickable href on the public homepage. The summary is
indexable, so this is the same CWE-359 leak that PR midt-bg#183 / ADR-0040 close
everywhere else.
TDD (apps/web/app/routes/home.render.test.tsx — new, jsdom + createRoutesStub,
mirrors the conflicts.render.test.tsx pattern):
1. Masked top-10 row renders as <span>, not as <a href="/companies/<slug>"> —
fails on the pre-fix `<Link>` and on the post-fix opaque-slug form.
2. Subtitle for a masked row omits both "непотвърден ЕИК" and the bare ЕИК —
fails on the pre-fix "ЕИК ${c.eik}" / "непотвърден ЕИК" ternary.
3. `headers()` returns the constant Cache-Control and never stamps the
privacy-mask marker on the HTML home page — the home is public and
indexable, a single masked row is too narrow a signal to noindex the
whole homepage.
lyubomir-bozhinov review 2026-09-02, thread on packages/db/src/queries/rows.ts:86
(the "summary" in the original comment).
Verification:
- pnpm --filter @sigma/web exec vitest run → 49 files / 588 tests green
(including the new home.render.test.tsx — 3 tests).
- pnpm --filter @sigma/db exec vitest run src/queries/ → 24 files / 230 tests green.
- pnpm --filter @sigma/shared exec vitest run → 4 files / 60 tests green.
- pnpm exec prettier --check (touched files) → clean.
Note: pnpm typecheck reports one pre-existing error in
apps/web/app/routes/companies.render.test.tsx:119 that predates this PR
(verified by `git stash`-ing the patch and re-running `tsc -b --force`);
unrelated to the privacy fix and out of scope.
Daily autonomous review — lyubomir-bozhinov 2026-09-02 MAJOR: masked rows still leaked the ЕИК in the leaderboard slugCommit-и (на върха
Решено
Новият
Юридическите лица и обединенията остават с round-trippable „Виж summary" — home top-10
Маскираният профил остава достъпен от TDD (commit-ите)
Верификация (local, на post-fix върха
|
lyubomir-bozhinov
left a comment
lyubomir-bozhinov
left a comment
There was a problem hiding this comment.
Прегледах отговора на предната бележка при HEAD 93086725. Оценявам бързата реакция, но fix-ът не защитава ЕИК-а — maskedCompanySlug е обратимо кодиране, не маскиране.
maskedCompanySlug(bidderId) = 'm' + b64urlEncode(bidderId) (identity.ts:40-42). base64url е ЕNCODING, не hash — тривиално обратимо. Емпирично:
bidder_id = eik:131071587
maskedCompanySlug = mZWlrOjEzMTA3MTU4Nw
атакуващ: махни 'm', base64url-decode → eik:131071587 → ЕИК 131071587
Слугът пак се сериализира в /companies.data (turbo-stream) и в hydration payload-а на индексируемия leaderboard — така че ЕИК-ът на физическото лице пак е възстановим оттам, само че base64-обвит. Един ред Python и линкът ЕИК ↔ „Частно лице" е налице; кодът е open-source, тъй че схемата не е тайна.
Коментарът/докстрингът твърди „one-way token … non-round-trippable" — това е вярно САМО спрямо собствения рутер (bidderIdFromSlug връща null за m), НЕ криптографски. Спрямо scraper няма разлика от голия ЕИК; печелим само че не е като литерални цифри (помага на search-индексирането, не и срещу насочен scraper).
Fix: маскираните редове са non-navigable (span, не Link; bidderIdFromSlug→null), тъй че slug-ът им трябва само стабилен уникален ключ — не бива да ДЕРИВИРА от bidder_id обратимо. Ползвай еднопосочен трансформ: напр. 'm' + sha256hex(bidder_id).slice(0,16) (стабилно, не-обратимо, без ЕИК/име). Ако някога потрябва да е resolvable за backlink — keyed HMAC със сървърна тайна, но не plain base64.
Severity: MAJOR (същият клас — натурален ЕИК възстановим на индексируема повърхност; сведен до „обратим с base64", но не затворен). Останалото от делтата — чисто (потвърдено предния път).
|
Прегледах двата комита, които кацнаха след ревюто ( MAJOR от ревюто ( Допълнителни follow-up-и от същия клас (в същата итерация, за да не се връща пак):
Verification (всичко вървя преди push):
Verdict: Имаше един MAJOR в ревюто + три MAJOR-class follow-up-а от същия клас на същите повърхности. Всичките пет повърхности ( |
Daily review (2026-09-03) — addressed MAJOR thread on
|
ydimitrof
left a comment
ydimitrof
left a comment
There was a problem hiding this comment.
Преглед на PR: политика noindex+mask за машинно-четими изходи (#173)
Какво прави PR-ът
Промяната прилага единна политика за поверителност (noindex + маскиране) към машинно-четимите повърхности на приложението. Механизмът е чист и добре обмислен: маршрутите поставят вътрешен маркер X-Privacy-Mask: applied, а worker-ът (hardenResponse) го превежда в X-Robots-Tag: noindex и го изтрива, преди отговорът да достигне edge/клиента. Разделянето „HTML индексируем / .data близнак noindex“ за листингите, guard-овете за консорциуми (пренесени и в JSON masker-а, и в contract.tsx), както и свалянето на сървър-only полето bidder_legal_form по всички пътища, изглеждат коректни. Тестовото покритие е задълбочено (вкл. реален SQLite за регресията с legal_form).
Не открихме зловреден код, prompt injection, скрити мрежови извиквания или промени по auth/CI/зависимости. Коментарите и ADR-текстовете описват решения, не се опитват да управляват ревюто.
Блокиращи проблеми (изискват промяна)
Целта на PR-а — маскиране на машинно-четимия изход — е подкопана от няколко течения на идентификатора (ЕИК) през полето slug:
-
Изтичане на ЕИК през
bidder.slugв маскирания JSON.maskContractForPrivacyнулираeik, но запазваbidder.slugчрез...record.bidder. Според фикстурата вhome.render.test.tsxslug-ът на маскиран запис еm<base64url("eik:<ЕИК>")>— обратимо кодиране (а често самият ЕИК). Тестът маскира проблема с изкуствен slug ('bidder-1'). -
Изтичане на ЕИК през
bidderSlugв списъка с договори. Вcontracts.tstoItemмаскираbidderName/bidderDisplayNameза едноличен търговец, но оставяbidderSlug= суровия ЕИК (companySlug('eik:…')връща голите цифри). Списъкът има същия RRv7.dataблизнак като/companies, така че ЕИК-ът пак изтича. Повърхността е непоследователна с/companies, където беше въведенmaskedCompanySlug. -
Невярно публично изявление за поверителност. Страницата изброява
/companies/:eik.dataсред форматите, в които „оригиналното име се заменя с етикет“, но по ADR-0039 §6 и реалния код.dataблизнакът НЕ маскира името — само нулира ЕИК.
Допълнителни бележки
- Сигурност на
maskedCompanySlug. Използва FNV-1a-64, а docstring-ът твърди „unrecoverable“. За ЕИК ключовото пространство е ~10⁹ и FNV-1a е бърз/нехеширан — груба атака (fnv1a64('eik:'+кандидат)) възстановява ЕИК-а за секунди. По-добро от предишния base64, но не е „невъзстановимо“ — преоценете заплахата или смекчете формулировката. - Дребно:
contract.tsxмутира обекта от loader-а на място (contract.bidder.eik = null) вместо да прави копие, за разлика от JSON пътя. - Между-batch зависимостта worker-ът винаги да вика
applyPrivacyMaskHeadersпо всички пътища (вкл. CSV и.data) и ПРЕДИ edge кеша не може да се потвърди в прегледаните файлове — струва си да се верифицира.
Заключение
REQUEST_CHANGES. Основата на PR-а е стабилна и добре тествана, но множеството течения на ЕИК през полетата slug в маскираните JSON и .data изходи анулират самата цел на промяната и трябва да се отстранят преди сливане. Препоръчваме и да се приведе в съответствие публичното изявление за поверителност, както и да се преоцени твърдението „unrecoverable“ за хеша.
lyubomir-bozhinov
left a comment
lyubomir-bozhinov
left a comment
There was a problem hiding this comment.
Прегледах slug-fix-а при HEAD a6063a76. FNV-1a затваря тривиалния base64 decode от предната бележка — благодаря за бързата реакция. Но ЕИК-ът пак е възстановим: unsalted бърз hash на публично изброим идентификатор се обръща с precompute-lookup.
MAJOR (още отворен) — maskedCompanySlug = 'm' + fnv1a64Hex(bidderId) е precompute-recoverable.
fnv1a64Hex (identity.ts:61-72) е FNV-1a 64-bit — БЪРЗ, UNSALTED, некриптографски hash, без сървърна тайна. Входът eik:<ЕИК> идва от ПУБЛИЧНО ИЗБРОИМ keyspace: множеството ЕИК на спечелилите договори е СОБСТВЕНИЯТ публичен dataset на sigma (OCDS /contracts, немаскираните /companies редове, CSV експортите). ЕТ е маскиран точно защото е спечелил договор — значи ЕИК-ът му по дефиниция е в публичните данни.
Атака: precompute fnv1a64Hex('eik:'+e) за всеки ЕИК e от публичното множество участници (≤ няколкостотин хиляди; FNV-1a ~GB/s → милисекунди), reverse lookup таблица, и всеки m<hash> slug на /companies.data, /contracts.data, /flows, /competition се резолвва мигновено → връща ЕИК-а → де-анонимизира „Частно лице". Схемата е open-source, тъй че не е тайна. Класическото „hash-ване на нискоентропиен идентификатор не го анонимизира" (както hash-нат ЕГН/телефон/имейл).
Коренът: стойност от малък, публично изброим keyspace НЕ може да се анонимизира с никакъв unkeyed детерминистичен трансформ (base64, FNV, дори SHA-256 падат на precompute-lookup).
Дефинитивен fix (избери едно):
(a) Не деривирай slug-а от ЕИК-а изобщо. Маскираните редове са non-navigable — bidderIdFromSlug връща null за m<...> (identity.ts:78-91), никой backlink не го резолвва; slug-ът е само React getKey. Ключ трябва да е уникален в списъка, НЕ стабилен между отговори — тъй че позиционен/ordinal ключ или per-response opaque token върши работа, без ЕИК информация да напуска сървъра. Най-простото, без тайна.
(b) Ако наистина трябва стабилен, сървърно-резолвваем token — keyed HMAC със сървърна тайна: 'm' + HMAC-SHA256(SECRET, bidder_id) — атакуващ не може да precompute-не без тайната.
Забележка: maskedCompanySlug е споделен — същият helper се ползва от #344 (contracts bidderSlug, contracts.ts:247) и #345 (flows/competition). Поправка в identity.ts затваря и трите повърхности.
Останалото от маскирането е коректно (потвърдено): видимият render е не-линк <span>, name/eik/eikValid/hasEik in lock-step. Само slug-ът остава. Severity: MAJOR — ЕИК ↔ „Частно лице" още възстановим на индексируема повърхност (по-висока цена от base64, но не затворено).
lyubomir-bozhinov
left a comment
lyubomir-bozhinov
left a comment
There was a problem hiding this comment.
MINOR (doc-drift на споделения DTO) — packages/api-contract/src/index.ts:72: CompanyListItem.name носи коментар // source name (verbatim), но toCompanyListItem вече го маскира (name = isNaturalPerson ? MASKED_NATURAL_PERSON_LABEL : cleanName(...)) — за физическо лице name е „Частно лице", НЕ verbatim. Поведението е безопасно (кодът маскира), но stale коментар на security-маскирано поле е footgun: бъдещ консуматор, доверил се на „verbatim", може да въведе отново leak (wrong canonical reference е по-лошо от липсващ). Едноредова поправка на коментара.
…lPersonProfileName null-safe
|
Автономен обзор на ревютата — ежедневен cron pass, 2026-09-04 (EEST). Адресирани неща в този pass (ydimitrof 2026-09-03 batch — 9 нерезолнати нишки; lyubomir-bozhinov 2026-09-04 — 1 нерезолната):
Комити в този branch:
Верификация:
Нерезолнати/отворени нишки: няма — всичките 9 thread-а на ydimitrof и 1 MAJOR thread на lyubomir-bozhinov са резолнати. Общо 35 review thread-а в PR-а, 0 нерезолнати. Непроследено (out-of-scope за този PR, follow-up): |
…upstream Conflict resolution: kept both sides — the privacy describe block (servedCsvExport privacy) added by this branch lives alongside the upstream describe blocks (csv-export — remaining branches, putStreamMultipart — abort on failure, servedCsvExport — R2 range shapes). Test imports merged: MASKED_NATURAL_PERSON_LABEL + FakeD1 type + upstream contracts helpers (contractsSummary, listSingleOfferContracts, getCompanyFacets, normalizeCompanySort).
|
Daily autonomous review (2026-09-05) — rebase to keep mergeable. State of action items from prior review. All 26 review threads remain What I did this pass (rebase only):
Conflict resolution (3 files, all test-side):
No production code touched. No force-push. No Co-Authored-By trailers. Verification (local, on the post-merge tip
State:
Coordination note with PR #177 (lyubomir-bozhinov 2026-07-28): the integration-lane follow-up to add |
This branch has not been deployed
4 participants
Какво и защо
HTML профилът на фирма вече прилага
noindexза разпознати физически лица / еднолични търговци (ЕТ),но същите идентификатори остават достъпни от машинно-четливите повърхности — JSON записът
на договора (
/contracts/:id.json) и трите CSV експорта (/contracts.csv,/companies.csv,/authorities.csv). Те връщат ЕИК и оригиналното име от източника безX-Robots-Tag: noindexи без маскиране, edge-кешират се (
Cache-Control: public, max-age=3600) и попадат в индекситена търсачките и ботовете.
Несъответствието прави идентификаторите, които HTML умишлено държи извън търсачките,
търсещи се и изтегляеми накуп — класът CWE-359, описан в issue #173.
Решение
Прилага се политика „
noindexплюс маскиране" с един общ предикат отpackages/shared/src/format.ts, който заменя досегашната дублирана логика вcompany.tsx:isNaturalPersonBidder(name, legalForm)комбинираlegal_form LIKE 'ЕТ%'(вкл. латинското
ET, разширените формиЕДНОЛИЧЕН ТЪРГОВЕЦ,SOLE TRADER,INDIVIDUAL)с водещия
ЕТсуфикс в името (който вече беше вisNaturalPersonProfileName).MASKED_NATURAL_PERSON_LABEL('Частно лице') е константа, която се внася по символ отвсеки консуматор — преименуването ѝ не чупи нито един тест. Inline
isSingleNaturalPersonProfileе премахнат от
company.tsx.packages/db/src/queries/{contracts,companies}.tsправятSELECT b.legal_formи маскиратcontractor_eik/eikиcontractor/nameпредибайтовете да стигнат до R2 — edge кешът не може никога да сервира немаскиран
естествено-личностен ред.
apps/web/app/lib/csv-export.tsдобавяX-Robots-Tag: noindexна четирите клона: 200/206 HIT, dynamic (филтриран) и 304.
packages/db/src/queries/details.tsразширяваgetContractсbidder_legal_form(server-only, не изтича към клиента —ContractRecordостава непроменен).apps/web/app/routes/contract.json.tsxизнася чистmaskContractForPrivacy(record, bidderLegalForm)помощник, който слагаX-Robots-Tag: noindexсамо когато маскиранетореално е приложило — reference-equality гейт
masked !== recordправи повторнотоизвикване на предиката ненужно.
#natural-person-dataвapps/web/app/routes/privacy.tsxописва кои полета се маскират, кои повърхностиносят
noindex-а и че HTML профилът остава непокътнат. Кадърът е инженерно ръководство,не правен съвет — същият disclaimer носи и ADR-0002.
docs/architecture.md(български, огледало на ADR-0001):Контекст / Решение / Последствия / Засегнати повърхности / Доказателство. Цитираните exit code-овеса от реален пост-едит прогон в чисто и замърсено дърво, не оценки.
Юридическите лица (
legal entity) са непроменени — ЕИК и имената им остават видимивъв всички повърхности.
Валидация (реални данни)
pnpm typecheck— exit 0 (7/7 turbo задачи).pnpm test --force— exit 1, заради 3 пред-съществуващи повреди в@sigma/db(
integrity-checks.test.tsreconciliation gate + 2 таймаута вrefresh-slice.test.ts).Същият набор е налице и в предишния
main, не е въведен от този PR.Всичките 38 нови теста минават — пост-едит и пре-едит прогонът показват същия набор
пред-съществуващи повреди, без нови въведени от този PR.
pnpm lint— exit 1, 6 prettier warnings: 2 пред-съществуващи (RiskIndicators.tsx,riskLogic.test.ts) + 4 нововъведени (contract.json.test.ts,privacy.tsx,companies.test.ts,companies.ts). Няма нови lint-видове — само пренасяне на редовезаради български / EN текст в JSX.
@sigma/shared42/42,@sigma/db(
contracts.test.ts+companies.test.ts+details.test.ts) 26/26,@sigma/web(contract.json.test.ts+csv-export.test.ts) 33/33.Извън обхвата
bidders.legal_formвече присъстваше вmigrations/0000_init.sql.ContractRecord(API contract) е непроменен от страна на клиента; полетоbidder_legal_formостава server-only (добавя се в
details.ts, използва се от route-а, не се изпраща на клиента).noindexмета-етикет минава през същия споделен предикат.Чеклист
Co-Authored-By:trailermidt-bg/sigma:mainpnpm typecheckминава; пред-съществуващитеpnpm test/pnpm lintповреди садокументирани като baseline в секция „Валидация (реални данни)" по-горе
Closes #173