[kilfor.ru](https://kilfor.ru/) is an active website and internal system of the Kilfor business center.

The project runs on MODX. This version of the system has been in use on-site since 2016; its foundation was previously developed in 2009 for the business center at 21 Novy Arbat.

The project encompasses a public website, a user account dashboard, and application logic related to pass requests, vehicle entry, utilities, and other internal business center processes.

MODX remains the backend of the active system. The public part of the project is being developed separately on a new frontend.

The general state, history, and development of the project are documented in the [main concept](https://fi1osof.ru/concepts/kilfor-modernizatsiya-legacy-modx-proekta).

Kilfor.ru is an active website and internal system of the Kilfor business center. The public-facing part runs on MODX, while the backend maintains the application logic for the user account, pass requests, vehicle entry, utilities (housing and communal services), and other internal processes. Main project concept: https://fi1osof.ru/concepts/kilfor-modernizatsiya-legacy-modx-proekta

Kilfor.ru

Conduct an audit of the current [kilfor.ru](https://kilfor.ru/):

- resource and public page structure;
- templates, chunks, snippets, and frontend dependencies;
- data used and methods of retrieving it;
- forms and public interaction points with the backend;
- login and transitions to the personal account;
- current URLs, redirects, metadata, and indexed pages;
- images, documents, and other public materials;
- outdated data and traces of the previous owner/name;
- external integrations and counters.

The result is needed as an actual map of the public layer before creating the new frontend. Do not rewrite the internal MODX business logic as part of this task.

Document the current state of the public part of the website and dependencies on MODX.

Conduct a technical and content audit of the current kilfor.ru

Determine what data and actions the new public frontend should receive from the existing MODX, and implement the necessary integration layer.

Do not transfer internal business logic to the frontend and do not rewrite the backend without a separate necessity.

Pay special attention to ensuring that the existing user account, passes, vehicle entry, utilities, and other internal processes continue to work without changes for users.

Define and implement a secure interaction layer between the new frontend and MODX data and functions.

Organize integration of the new frontend with the existing MODX backend

Сейчас заявки на посетителей и заявки на внос/вынос - это разные сущности (на то были отдельные бизнес-требования со стороны заказчика, а так же отдельные права можно/нельзя). И исторически для работы с разными типами заявок были разные страницы и формы. Бизнес-логику и архитектору мы конечно же менять не будем, но вот интерфейсы можно и нужно унифицировать. Форму на создания делаем универсальную, просто добавляем переключатель Материальная или Просто на посетителя (просто чтобы корректней проверять заполненность формы, чтобы не получилось, что пользователь создал просто на посетителя, забыв указать что хочет занести или вынести, а фотма ему не подсветила). И на вывод можно использовать один интерфейс с использованием union-объекты в GraphQL.

Унифицировать интерфейсы заявок

## Контекст

Сессии пользователей Kilfor сейчас хранятся и обслуживаются MODX. Новый frontend на haih-agent уже реализует часть прикладной логики самостоятельно, поэтому ему периодически нужна детальная информация о текущем авторизованном пользователе.

В MODX есть внутренний PHP API для работы с текущим пользователем внутри MODX runtime, но штатного внешнего HTTP endpoint уровня `current user` для frontend-контекста из коробки нет. В modSociety существует собственный endpoint для получения пользователя, однако новый frontend не должен зависеть от этого legacy-компонента.

## Цель

Реализовать в haih-agent инфраструктурный слой, который умеет по существующей MODX session cookie определить пользователя, авторизованного в заданном frontend-контексте (`web` или другом), и предоставить нормализованные данные пользователя прикладному коду нового frontend.

## Что исследовать и реализовать

- Разобраться с фактическим форматом хранения frontend-сессий в используемой версии MODX и на Kilfor.
- Определить, как из session id и данных `modx_session` получить пользователя для конкретного context key.
- Корректно разбирать PHP session serialization, не привязываясь к regex-хаку.
- Получать необходимые данные пользователя из `modUser`, `modUserProfile` и проектных связей.
- Сделать MODX-specific реализацию отдельным адаптером/провайдером, чтобы прикладной код работал с абстракцией `currentUser`, а не знал структуру MODX session.
- Не зашивать `web` в низкоуровневый parser: context key должен задаваться конфигурацией или вызывающим auth-слоем.
- Учесть истечение/инвалидность сессии и отсутствие авторизации в запрашиваемом контексте.
- Не переносить целиком MODX ACL/security runtime без отдельной необходимости; на первом этапе задача — достоверно определить пользователя и его данные.
- Предусмотреть возможность другого session storage/handler в будущем, не связывая весь auth-код напрямую с SQL к `modx_session`.
- Покрыть parser и определение пользователя fixture/integration-тестами на реальных примерах MODX frontend-сессий.

## Ожидаемый результат

В GraphQL/request context haih-agent доступен нормализованный текущий пользователь для указанного frontend-контекста, полученный напрямую из существующей MODX-сессии. Для этого не требуется отдельный запрос к legacy endpoint modSociety или bootstrap MODX на каждый запрос нового frontend.

Научить новый frontend Kilfor определять текущего пользователя напрямую по существующей MODX-сессии без зависимости от legacy HTTP endpoint.

Tasks

Интегрировать MODX frontend-сессии в auth-контекст haih-agent

Унифицировать интерфейсы заявок

Organize integration of the new frontend with the existing MODX backend

Conduct a technical and content audit of the current kilfor.ru