api_v1: typowane viewsety publikacji nie używają scope_rekord_api (dryf polityki widoczności)

[mpasternak]

Problem

W /api/v1/ współistnieją dziś dwie różne polityki widoczności dla tych samych danych, w zależności od tego, przez który endpoint się do nich sięga.

Pełną politykę stosuje api_v1/scoping.py::scope_rekord_api — trzy warstwy: zawężenie do uczelni (scope_rekord_do_uczelni), wykluczenie ukrytych statusów korekty oraz nie_eksportuj_przez_api. Używają jej:

• /api/v1/szukaj/ (api_v1/viewsets/szukaj.py)
• /api/v1/zapytanie/rekord/ (api_v1/viewsets/zapytanie.py)
• endpointy „recent" (api_v1/viewsets/recent_publications_common.py)

Typowane viewsety publikacji stosują tylko dwie z tych trzech warstw — mają UkryjStatusyKorektyMixin i wykluczenie nie_eksportuj_przez_api, ale nie wołają scope_rekord_do_uczelni:

• api_v1/viewsets/wydawnictwo_ciagle.py
• oraz analogicznie: wydawnictwa zwarte, patenty, prace doktorskie i habilitacyjne

Dlaczego to jest ten sam problem, który już raz naprawialiśmy

Docstring api_v1/scoping.py opisuje dokładnie tę klasę rozjazdu jako powód swojego powstania:

Jedno źródło reguły dla /api/v1/szukaj/ i /api/v1/zapytanie/rekord/ — oba endpointy MUSZĄ egzekwować ten sam zestaw ograniczeń. Wcześniejszy dryf (szukaj egzekwował, zapytanie nie) był luką bezpieczeństwa (uwaga #1 reviewera): token redaktora widział rekordy innej uczelni, ukryte statusy oraz rekordy oznaczone nie_eksportuj_przez_api.

Helper powstał, ale objął tylko trzy endpointy. Typowane viewsety publikacji zostały poza nim — czyli ten sam dryf istnieje dalej, tylko wzdłuż innej granicy.

Skutek

W instalacji wielouczelnianej polityka widoczności zależy od wyboru endpointu, a nie od danych. Dotyczy to zwłaszcza filtra ukrytych statusów korekty, który jest stosowany według uczelni wynikającej z bieżącego Host, podczas gdy zbiór rekordów nie jest do tej uczelni zawężony.

W instalacji jednouczelnianej różnicy nie ma — scope_rekord_do_uczelni jest tam no-op.

Skąd to wyszło

Znalezione przy recenzji #804 (hostowany serwer MCP). Ten PR nie wprowadza problemu — korzysta z istniejących endpointów bez zmian. Wystawia je natomiast jako kuratorowane narzędzia dla asystentów AI, więc rozjazd staje się bardziej widoczny. Specyfikacja tamtego PR-a została w związku z tym sprostowana, żeby nie deklarowała izolacji, której na tej ścieżce nie ma.

Propozycja

Zastosować scope_rekord_api (albo przynajmniej scope_rekord_do_uczelni) w typowanych viewsetach publikacji, tak jak robią to szukaj, zapytanie i „recent" — plus testy wielohostowe pilnujące, że wszystkie endpointy oddają ten sam zbiór dla tego samego hosta.

Wymaga osobnej decyzji, bo zmienia zachowanie publicznego API dla dotychczasowych konsumentów: kto polega dziś na liście międzyuczelnianej, zobaczy węższy wynik.