Версия 0.1.1 выпускалась до удаления OAuth: приводим номер в соответствие с
состоянием кода (в 0.1.2 входа через внешние провайдеры уже нет, схема БД — 27).
- VERSION, tauri.conf.json, Cargo.toml, Cargo.lock → 0.1.2;
- состав изменений с 0.1.1: удалён OAuth целиком (D-084), миграция 00027
убирает таблицу oauth_accounts, зависимость golang.org/x/oauth2 убрана.
Решение владельца 27.09.2026 (D-084): сервис ставится на сервер конкретного
человека, и ему всё равно нужен свой OAuth у провайдера — поддержка общего
входа только создаёт трение (регистрация приложений, redirect URI, модерация,
чужие ключи в конфиге). Способы входа остаются: пароль + 2FA и ключи доступа
(WebAuthn).
Удалено:
- сервер: internal/auth/oauth.go, internal/server/oauth.go, internal/store/oauth.go
и их тесты; поля и методы конфига OAuth*; oauthLimiter и регистрация ручек;
отображение ошибок oauth.*; features.oauth_enabled/oauth_providers в /meta;
- клиент: web/src/api/oauth.ts, раздел «Вход через внешние сервисы», кнопки
провайдеров на странице входа, ключи i18n (ru/en), тесты и фикстуры;
- установщик: переменные OAUTH_* из .env, .env.example и шаблона (хелпер
чтения существующих значений переименован в existing_value — он остался нужен
для VAPID_SUBJECT);
- зависимость golang.org/x/oauth2 (go mod tidy).
Схема: миграция 00027 удаляет таблицу oauth_accounts (00019 не переписываем —
она применена на стендах). Откат миграции возвращает структуру; тест
TestOAuthRemovalMigration проверяет накат, откат и повторный накат.
AGENT.md (локальный) помечает пункты про OAuth как отменённые.
Публичному приложению VK ID сервисный ключ не нужен: обмен кода защищает PKCE,
и VK выдаёт токен по одному client_id. Раньше провайдер включался только при
заполненных id и секрете, то есть публичный вариант был недоступен.
- у провайдера появился флаг SecretOptional (у VK ID — true);
- включение провайдера и каталог учитывают флаг;
- тест TestOAuthVKPublicAppWithoutSecret: вход работает без секрета, в запросе
обмена нет ни client_secret, ни service_token.
Владельцу нужны VK и Яндекс (Google/Discord/GitHub остаются в каталоге и
включаются своими ключами).
VK ID (id.vk.ru, OAuth 2.1):
- обязательный PKCE: code_challenge в запросе авторизации, code_verifier при
обмене; верификатор выводится из подписанного state (HMAC), хранить нечего;
- device_id из callback уходит в обмен кода;
- для конфиденциальных приложений секрет передаётся как service_token, а не
client_secret (и обмен идёт параметрами в теле, не Basic);
- профиль: POST /oauth2/user_info с client_id и access_token; права email и
vkid.personal_info.
Яндекс ID:
- права login:email и login:info; секрет — в теле запроса обмена;
- профиль: GET login.yandex.ru/info?format=json с заголовком
"Authorization: OAuth <токен>" (не Bearer).
Общее:
- в профиль добавлено DisplayName: VK отдаёт имя и фамилию, Яндекс — real_name,
раньше они терялись;
- почта считается подтверждённой, если провайдер её отдал (отдельного флага нет,
адрес приходит только по соответствующему праву) — D-083;
- новые переменные OAUTH_VK_* и OAUTH_YANDEX_* в установщике и .env.example;
- тесты: полные флоу обоих провайдеров на мок-серверах, каталог и ручки.
Установка на VPS (Debian 13, 1 vCPU/2 ГБ) с внешним прокси на том же хосте
вскрыла дефекты, которые не проявлялись на стенде:
- compose: с --no-turn порты TURN всё равно публиковались, и стек не стартовал
(«failed to bind host port 0.0.0.0:3478/udp» — порт держит чужой coturn).
Теперь строки портов TURN подставляет установщик (GLCHAT_TURN_PORTS).
- LiveKit: добавлен отдельный адрес публикации медиапортов
(--livekit-media-bind-addr / GLCHAT_LIVEKIT_MEDIA_BIND): сигналинг остаётся
внутренним для прокси, а 7881/tcp и 7882/udp доступны клиентам из интернета.
- external-proxy.conf: адреса апстримов берутся из фактической привязки
(--app-bind-addr/--livekit-bind-addr), а не жёсткого 127.0.0.1.
- при --no-files-subdomain шаблоны внешнего прокси и встроенного Caddy писали
два блока с одним адресом сайта (Caddy отвергает такой конфиг и в embedded
режиме установка ломалась целиком): блок пользовательского контента теперь
появляется только при отдельном домене (GLCHAT_FILES_BLOCK).
- e2e: postWithRetry/repeat429 читают retry_after_ms из конверта ошибки
({"error":{...}}) — без этого хелперы сдавались раньше, чем сервер разрешал
повтор, и регистрация пробных аккаунтов на свежем инстансе падала.
- e2e: voice.spec.ts ищет комнату «Голос» точным именем: пока сайдбар
дорисовывает сервер, видны комнаты предыдущего («Голос A»/«Голос B»).
- .dmg распространяется неподписанным; инструкция для конечного пользователя
(правый клик → «Открыть» или снятие карантина xattr) — в README
- хеш и путь текущего установщика 0.1.1
- сборки Windows/Linux отложены: репозиторий в Gitea, раннеры есть у GitHub
Actions; локальная часть (desktop-check, desktop-release --target) готова
Версия — в одном месте: файл VERSION в корне, из него её берут Makefile,
deploy/install.sh (IMAGE_TAG) и desktop-обёртка (tauri.conf.json, Cargo.toml).
Публикация обновлений (scripts/desktop-release.sh):
- манифесты прошлых релизов удаляются: оставшийся <старая версия>.json
перекрывал новый релиз — обёртка спрашивает манифест своей версии и видела
«обновлений нет»;
- mktemp-каталог раскладки получает 755, каталоги на инстансе
нормализуются: rsync -a переносил режим 0700 на корень каталога обновлений,
и приложение не могло читать манифесты (404 при живых файлах);
- --remote работает без TTY и без sudo, если каталог обновлений записываем;
опции ssh — в GLCHAT_SSH_OPTS;
- предупреждение при публикации версии старше уже опубликованной.
Сервер: HEAD /updates/... (chi не выводит его из GET) — размер и тип артефакта
без скачивания; тест TestUpdatesAnswersHead.
Приёмка на живом канале: 0.1.0 → 0.1.1 на стенде (скачивание, проверка
подписи, установка, перезапуск), /Applications/glchat.app = 0.1.1.
docker compose exec -T подключает stdin и съедал его у скрипта, поданного на
stdin (ssh … bash -s): обёртка обрывала такой скрипт после первой команды.
Найдено живой проверкой build/cli-live-check.sh (create-user выполнялся, дальше
скрипт молча заканчивался). Командам обслуживания stdin не нужен: </dev/null.
Плюс e2e web/e2e/query-retry.spec.ts: живая проверка повтора при 429 — запрос
участников дважды получает 429 с retry_after_ms и проходит с третьей попытки,
раздел «Участники» заполняется без кнопки «Повторить».
- deploy/glchat-cli.sh: reset-password/make-admin/remove-admin больше не
заглушки «появится в фазе 1» (AGENT.md 10.7), добавлены totp-setup,
totp-reset и delete-user; подкоманды обслуживания идут через общий app_cli
- cmd/glchat: команда delete-user (мягкое удаление как в админ-панели,
защита от удаления инстанс-админа и подтверждение --yes), исправлен
потерянный комментарий cliCleanup
- deploy/install.sh: убраны устаревшие формулировки про фазу 1
- web: политика повторов запросов — 429 повторяется с паузой retry_after_ms
(до двух раз, не дольше 5 с), 4xx не повторяются; тесты web/tests/queryRetry.test.ts
- scripts/test-install.sh: проверка, что заглушек в CLI не осталось
- `--update-now` в таблице аргументов и в разделе «Автообновление»: что делает,
как запускать, что подпись проверяется так же, пример записей в журнале;
- «Локальная проверка «поверх старой версии»»: пошаговый рецепт прогона
0.1.0 → 0.1.1 на локальном сервере инстанса и три грабли — http-эндпоинт
требует временного `dangerousInsecureTransportProtocol`, путь приложения не
должен содержать символических ссылок (`/tmp` → `/private/tmp`), в headless
нужен `--update-now`;
- `.dmg`: точные команды — обычным терминалом (`make desktop-build`, с
оформлением окна) и без графической сессии (`bundle_dmg.sh --sandbox-safe`,
проверено: образ монтируется, `hdiutil verify` — VALID);
- «Что не сделано»: автообновление end-to-end проверено локально, открытым
остаётся публикация реального релиза; добавлено наблюдение, что `open --args`
из песочницы агента аргументы не доставляет (проверено на macOS 27).
`make desktop-build` не запускался вовсе: Tauri CLI отвергает `--bundles all`
(«possible values: ios, app, dmg»), а значение по умолчанию в Makefile было
именно `all`. Теперь при `all` флаг не передаётся, и список бандлов берётся из
`bundle.targets` в tauri.conf.json — то есть собирается всё, что положено для
текущей ОС. `make desktop-build-app` (`--bundles app`) работает как раньше.
Обнаружено при попытке собрать `.dmg` (make desktop-build).
Установка обновления всегда спрашивала согласие диалогом, поэтому сквозная
проверка «поверх старой версии» не автоматизировалась (в headless-прогоне
кликнуть некому), а на управляемых машинах обновление ставит оператор, а не
пользователь. С флагом `--update-now` обёртка проверяет обновление сразу при
старте (не через 30 секунд) и ставит найденное без диалога, после чего
перезапускается; при отсутствии обновления работает как обычно.
По умолчанию флаг выключен — трей, страница настроек и фоновая проверка
по-прежнему спрашивают согласие. Подпись артефакта проверяется в обоих
режимах: флаг убирает вопрос, но не проверку. Ход тихого обновления виден в
журнале, а в строку запуска добавлена версия сборки — иначе после перезапуска
не понять, какая версия работает.
Решение — D-077, приёмка — desktop/README.md («Локальная проверка»).
Две проверки на стенде двумя браузерами, без F5 (trackLoads = 0):
* группа из трёх пробных аккаунтов: владелец ставит иконку и переименовывает
беседу через меню в шапке, наблюдатель-участник видит иконку в шапке и в
списке бесед, новое имя — там же, событием DM_CHANNEL_UPDATE; участнику
меню владельца недоступно;
* личные шаблоны: первое устройство сохраняет структуру сервера шаблоном,
второе (свой вход формой) открывает окно создания сервера, видит шаблон в
«Моих шаблонах» и создаёт по нему сервер — комната и роль из шаблона на
месте. У личных шаблонов нет события шлюза: список читается при открытии
окна, перезагрузка страницы не нужна.
Имя беседы сверяется ещё и по REST, тестовые данные убираются (группа
распускается вместе с иконкой, серверы и шаблон удаляются, данные прошлых
прогонов подчищаются в beforeAll).
Пункт «Переименовать» в меню владельца в шапке групповой беседы и диалог с
текущим именем: `PATCH /channels/{id}` (D-075) уже был, интерфейса не было.
Ответ сервера кладём в стор бесед — имя меняется и в шапке, и в списке; при
отказе окно остаётся открытым с причиной, пустое имя отправить нельзя.
Меню владельца было меню иконки: теперь это общее меню беседы (⋯) с
переименованием, загрузкой и снятием иконки — прежние testid иконки смотрят
на те же пункты, поэтому обновлены только ссылки на само меню.
i18n ru/en, Vitest: `web/tests/dmRename.test.tsx` (переименование, пустое имя,
отмена и черновик, отказ сервера, права участника, DM_CHANNEL_UPDATE без
перезагрузки) и обновлённые ссылки в `web/tests/dmIcon.test.tsx`.
Кнопка «Войти по ключу доступа» тоже подходит под /Войти/u, поэтому
Playwright в strict mode находил два элемента и падал на входе — от этого
зависели все спеки, которые логинятся через форму (voice, realtime-social и
другие), когда панель passkeys успевала отрисоваться.
Спека поднимает звонок между двумя реальными клиентами на стенде и
проверяет то, что нельзя проверить юнитами: приглашение приходит событием,
оба браузера обмениваются аудио через LiveKit (входящие байты > 0),
выключенный микрофон виден на сервере, завершение снимает маркер у второго
участника, а в истории остаётся запись.
Сессия берётся из api-контекста (cookie __Host-session): форма входа
упирается в лимит попыток при серии прогонов. Запуск по флагу
GLCHAT_E2E_VOICE=1, как у голосовой спеки.
В шапке беседы — меню звонка: аудио, видео, «Присоединиться» к идущему и
история. Когда голос на инстансе выключен, меню нет вовсе: обещать звонок,
который не поднимется, нельзя.
Входящий звонок показывается карточкой поверх любого экрана с принять и
отклонить и рингтоном; идущий звонок — маркером в списке бесед и в шапке, а
в области переписки вместо ленты открывается панель с плитками участников и
кнопками микрофона, звука, камеры, шаринга и выхода. История звонков — кто
звонил, когда, сколько длился разговор и кто не ответил.
Тесты (vitest): начало звонка из шапки с подключением к комнате LiveKit,
входящий звонок и его принятие, отклонение, маркер «идёт звонок» по событию
и его снятие после завершения, флаги микрофона, камеры и экрана, история с
пропущенными и длительностью, выключенный голос и маркер после
перезагрузки (active_call в READY).
Ручной модуль api/calls.ts повторяет контракт сервера: разбор звонка один
и тот же для REST-ручек, READY-снапшота и событий DM_CALL_*, поэтому
состояние разбирается одним кодом.
Стор dmCall ведёт медиа-сессию поверх общей обёртки lib/livekit: те же
плитки, устройства, качество публикации и продление токена, но без
серверных ролей — мьют и деаф только свои. Рингтон синтезируется Web Audio
(файлов в проекте нет): входящий — пока звонят нам, исходящий — пока ждём
ответа; свёрнутая вкладка замолкает.
Карточка беседы несёт active_call: маркер «идёт звонок» приходит в READY и
в списке бесед, а дальше обновляется событиями DM_CALL_RING/UPDATE/END.
Завершение гасит локальную сессию и играет сигнал тем, кто был в звонке.
Звонки 1:1 и в групповых беседах до 10 участников поверх той же голосовой
инфраструктуры LiveKit: те же токены, что у серверных комнат, но без
серверных ролей — позвонить может участник беседы.
Ручки: POST /channels/{id}/call (создание, в ответе токен и адрес
сигналинга), accept, decline, end, PATCH /call/@me для флагов микрофона,
камеры и шаринга, GET /call (текущий звонок) и GET /calls (история: кто
звонил, когда, сколько длился, кто пропустил). Постороннему — 404,
существование чужой беседы не подтверждаем; в беседе больше десяти
участников звонить нельзя (dm.call_limit); выключенный голос отвечает
voice.disabled.
События: DM_CALL_RING приходит приглашённым, DM_CALL_UPDATE — участникам
при смене состояния, DM_CALL_END — с итогом и причиной. Звонок добавлен в
READY и в карточку беседы (active_call), поэтому «идёт звонок» переживает
перезагрузку. Вебхук LiveKit разбирает комнаты dm_call_* и синхронизирует
состояние, сторож голосовых состояний закрывает гудки без ответа и
опустевшие комнаты.
Тесты: жизненный цикл 1:1, отклонение и пропущенный, отказ постороннему
на всех ручках, предел десяти участников, поведение при выключенном
голосе, события Gateway и active_call в READY.
Звонок в личной и групповой беседе живёт в своей таблице: в voice_states
guild_id обязателен, а у беседы сервера нет. Миграция 00026 добавляет
dm_calls (статус, media, длительность, причина завершения) и
dm_call_participants (состояние участника и флаги микрофона, камеры и
экрана); уникальный частичный индекс держит один идущий звонок на беседу.
В DMParticipantProfiles сравнение с владельцем обёрнуто в COALESCE: у 1:1
dm_owner_id пуст, и NULL нельзя было прочитать в int — ручка звонка в
личной беседе падала на 500.
Тесты: жизненный цикл звонка в хранилище (гудки, active на втором
участнике, история, повторный звонок) и выборка сторожем.
Модалка создания сервера показывает блок «Мои шаблоны» рядом со
встроенными и отправляет template_id=personal:<id>; секция «Шаблоны
сервера» в настройках (видна с MANAGE_GUILD) сохраняет структуру
текущего сервера и удаляет ненужные шаблоны.
- api: fetchMyGuildTemplates, createGuildTemplate, deleteGuildTemplate,
ключ myGuildTemplatesQueryKey и лимит MY_GUILD_TEMPLATE_LIMIT;
- i18n: ключи в ru.json и en.json (паритет);
- тесты: web/tests/guildTemplates.test.tsx.
AGENT.md 7.3: свои шаблоны серверов — сохранить структуру сервера
(роли с правами и цветом, категории и комнаты) и создать по ней новый.
Миграция 00023 создаёт guild_templates (structure_json, source_guild_id,
каскад по владельцу) с индексом владельца.
- store: CRUD личных шаблонов с фильтром по owner_id и защитой лимитов
(20 шаблонов, 16 КиБ structure_json);
- server: POST /guild-templates, GET /guild-templates/mine и
DELETE /guild-templates/{id} (MANAGE_GUILD, чужой шаблон — 404),
создание сервера по template_id=personal:<id> (аудит template=personal:<id>);
- структура шаблона повторяет API ролей (права строкой) и хранит
slowmode_seconds, user_limit и категорию по имени.
D-070: у групповой беседы не было своей иконки — показывались имя и первая
буква аватара, как у 1:1 без аватара. Колонки под файл у канала не было.
Миграция 00024 добавляет `channels.icon_file_id` (REFERENCES files ON DELETE
SET NULL): NULL у 1:1 и комнат сервера, файл — у группы. Store читает и пишет
поле через `Channel`/`UpdateChannelParams` (`IconFileID`/`ClearIcon`), отдаёт
его в `ListDMChannels` и в READY, а уборка сирот больше не считает иконку
беседы мусором. Когда в группе остаётся два участника, беседа снова обычная
личная — иконка сбрасывается вместе с именем и владельцем.
Ручки `POST/DELETE /channels/{id}/icon` принимают multipart (назначение файла
`dm_icon`, аватарный лимит, проверка `image/`) и доступны только владельцу
беседы: участнику-не-владельцу 403 `perm.denied`, посторонним 404 (существование
чужой беседы не подтверждаем), у 1:1 своей иконки нет — 422 `dm.not_group`.
Файл иконки отдаётся только участникам беседы. После изменения участникам
уходит `DM_CHANNEL_UPDATE`, поэтому иконка меняется без перезагрузки
(AGENT.md 7.7, 7.8, 8.3, 11.6; D-042, D-070).
D-070: иконка группы приходит полем `icon_file_id` — у группы это её файл, у
1:1 по-прежнему аватар собеседника. Разбор беседы из REST вынесен в
`parseChannelPayload`: групповые поля и иконка не теряются, а у группы без
иконки поле очищается, чтобы не остался чужой аватар.
`api/dmIcon.ts` грузит и снимает иконку multipart-запросом (FormData уже умеет
общий `request`). В шапке групповой беседы у владельца появилось меню «Иконка
беседы»: загрузить или удалить; ответ сервера сразу кладётся в стор бесед, а
список перечитывается — снятая иконка приходит пустым полем (AGENT.md 7.8,
11.6). Строки добавлены в ru и en.
Новые разделы панели инстанса (AGENT.md 3.2, 7.18):
- вкладка «Статистика»: рост пользователей и сообщений по дням, размеры
данных, топы серверов;
- карточка пользователя из списка: устройства с отзывом, серверы и роли,
события безопасности, аудит по пользователю; отзыв устройства и сброс
второго фактора подтверждаются step-up;
- вкладка «Аудит»: фильтры по действию, актору, цели, серверу и датам,
пагинация и ссылка на выгрузку CSV;
- вкладка «Серверы»: поиск по названию, фильтр по владельцу и главному
серверу, пагинация;
- ключи i18n для новых разделов (ru/en, паритет), тесты панели.
Статистика, карточка пользователя и работа с журналом для администратора
инстанса (AGENT.md 3.2, 7.18):
- GET /instance/stats: рост пользователей и сообщений по дням, активность,
размеры базы и файлов, топы серверов по участникам и сообщениям;
- GET /instance/users/{id}: профиль, активные устройства, серверы с ролями,
события безопасности и аудит по пользователю;
- DELETE /instance/users/{id}/sessions/{sid} и POST .../reset-2fa: отзыв
одного устройства и сброс второго фактора со step-up, аудитом и записью
в события безопасности; чужой ключ администратора не сбрасывается;
- журнал инстанса: фильтры по действию, актору, цели, серверу и датам,
пагинация с общим числом, список действий и выгрузка CSV (лимит 5/мин);
- список серверов: поиск по названию, владелец, главный сервер, пагинация;
- миграция 00025: нормализованное название сервера `name_lower` — SQLite
lower() не знает кириллицу, поэтому регистр приводит приложение (как для
текста сообщений), старые записи дополняются backfill'ом при старте.
Редактор профиля в настройках читает `user.custom_status_emoji` и вызывает
`.trim()` прямо при отрисовке, а ручка это поле не возвращала: открытие
«Настройки → Профиль» падало с «Cannot read properties of undefined (reading
'trim')» (дефект с 22.09, commit 085454d — клиент поле требовал, сервер не
отдавал). Теперь поле приходит всегда, как и `custom_status`.
Найдено живой проверкой на стенде; тест `profile_payload_test.go` проверяет, что
ключ есть в ответе даже с пустым значением, и что PATCH его сохраняет.
`GUILD_EMOJIS_UPDATE` несёт набор эмодзи целиком, но раздел настроек читает
REST-кэш, а клиент на событие запрос инвалидировал. Под нагрузкой повторный
`GET /guilds/{id}/emojis` попадает под лимит частоты (429), а запрос списка идёт
с `retry: 0` — список оставался старым до перезахода. Тот же дефект, что у
раздела «Звуки» (коммит 4175b14), и та же правка: событие кладёт набор в кэш
запроса через `setQueryData`, а ошибка перезапроса больше не прячет уже
полученный список.
Регрессионный тест `web/tests/guildEmojisSettings.test.tsx` («показывает эмодзи
из GUILD_EMOJIS_UPDATE, даже если список по REST не отдался») падает на старом
коде.
Сервер присылал эти события и раньше, но клиент перечитывал список бесед только
по `DM_CHANNEL_CREATE` и READY: добавление участника, переименование группы и
выход из неё не появлялись в сайдбаре до перезагрузки, а удалённая беседа
оставалась открытой.
Теперь все три события перечитывают список (`DM_CHANNEL_UPDATE` меняет состав,
имя и аватар группы сразу), а `DM_CHANNEL_DELETE` дополнительно убирает беседу
из стора сессии и закрывает её, если она была открыта.
Тесты в `web/tests/friends.test.tsx` падают на старом коде: переименование
группы видно второму участнику, удалённая беседа исчезает и закрывается.
Под текстом сообщения показывается карточка: имя сайта, заголовок, описание и
картинка — всё с сервера (`GET /link-previews`), клиент сам в интернет не ходит.
- `web/src/lib/links.ts`: первая ссылка сообщения (markdown и «голая» формы),
блоки кода и инлайновый код игнорируются — `curl https://…` из примера не
должен тянуть чужую страницу;
- `web/src/components/chat/LinkPreviewCard.tsx`: запросов нет, пока
`meta.features.unfurl_enabled` не подтверждён; карточка молчит на
loading/ошибке/статусах empty, blocked и error (превью — украшение, а не
действие); картинка рисуется только по http(s) с
`referrerpolicy=no-referrer`, текст выводится обычными строками без
`dangerouslySetInnerHTML`; компонент монтируется только при найденной ссылке,
поэтому сообщение без ссылок не создаёт ни запроса, ни узла;
- `web/src/api/unfurl.ts`: типизированный клиент и ключ запроса.
Тесты: `web/tests/links.test.ts` (разбор ссылок) и `web/tests/linkPreview.test.tsx`
(карточка, отказ при выключенном unfurl, опасные схемы картинки, ровно один
запрос при 429).
Клиент подписывает устройство на Web Push, а показывает уведомление service
worker — приложение при этом может быть и закрыто.
- `web/public/sw.js`: обработчики `push` (показывает уведомление, иначе браузер
может отозвать подписку) и `notificationclick` (фокусирует окно и переводит
его в комнату, иначе открывает новое). Путь из payload берётся только
внутренний: `//host` и абсолютные адреса отбрасываются;
- `web/src/lib/webPush.ts`: поддержка API, запрос разрешения, подписка и
отписка, преобразование ключей в base64url, слушатель перехода по клику
(`push-navigate` → `history.pushState` без перезагрузки);
- `web/src/api/push.ts`: `GET /push/config`, `GET|POST|DELETE /push/subscriptions`;
- раздел «Push-уведомления» в настройках: тумблер «Включить на этом
устройстве», состояние «включено», объяснение отказа браузера в разрешении и
честная деградация — «браузер не поддерживает» или «на инстансе не настроено»;
- владелец инстанса управляет ключами, клиент только спрашивает публичный.
Тесты: `web/tests/webPush.test.ts` (поддержка API, ключи, подписка, отписка,
отказ в разрешении, переход по клику) и `web/tests/pushSettings.test.tsx`
(раздел настроек: деградация, включение, отключение, ошибка загрузки).
Сервер сам загружает заголовок, описание и картинку страницы по ссылке из
сообщения и отдаёт клиенту готовую карточку.
Безопасность (главное здесь):
- только http/https и без userinfo; запрет петли, частных сетей, link-local
(169.254.169.254), CGNAT, multicast и IPv4-mapped вариантов;
- проверка идёт по адресу, к которому реально открывается TCP
(`net.Dialer.Control`), поэтому подмена DNS между проверкой и соединением
(DNS rebinding) ничего не даёт;
- не больше 3 редиректов, каждый хоп проверяется заново; таймаут 5 с, тело
≤ 512 КБ, только `text/html`; прокси из окружения игнорируются, cookie и
авторизация не отправляются; в логи попадают только хост и код причины;
- картинка по ссылке не скачивается — проверяется лишь её URL: экономия CPU на
1 vCPU и минус класс атак через декодирование.
Кэш: таблица `link_previews` (миграция 00022, ключ — sha256 нормализованного
URL), TTL по статусу (ok — сутки, empty/blocked — час, error — 10 минут).
Ручка `GET /api/v1/link-previews?url=…` отвечает статусом
(ok/empty/blocked/error) и карточкой только при ok; 20 новых загрузок в минуту
на пользователя, кэшированные ответы лимит не тратят. `UNFURL_ENABLED=false`
выключает функцию целиком, `features.unfurl_enabled` виден в `/meta`. Retention
убирает истёкшие записи кэша.
Тесты: 21 в `internal/unfurl` (включая DNS rebinding через локальный
DNS-сервер, редирект во внутреннюю сеть, таймаут, лимиты размера и типа),
ручки, store и миграция.
Уведомления в браузере и на телефоне: сервер сам решает, кому их слать, и
подписывает запрос VAPID-ключом, поэтому уведомление приходит, даже когда
клиент закрыт.
Сервер:
- миграция 00021: `push_subscriptions` (эндпоинт уникален, ключи, счётчик
неудач, время последней доставки);
- `internal/push` — VAPID-ключи (приватный PKCS#8 из конфига, публичный
выводится из него), правила уведомлений повторяют
`web/src/lib/desktopNotifications.ts` (упоминания и личные беседы, без своих
и системных сообщений), очередь доставки, TTL 12 часов, Topic по комнате;
- 404/410 от push-сервиса удаляют подписку сразу, 5 неудач подряд — тоже,
иначе копились бы мёртвые эндпоинты; retention чистит «молчащие» подписки;
- `internal/httpx/safeurl.go` — общий запрет внутренних адресов с проверкой
адреса в момент подключения (DNS rebinding): эндпоинт подписки приходит от
клиента, и без проверки сервер сам себе организует SSRF;
- `internal/gateway/presence.go` — `IsUserOnline`: если получатель в клиенте,
уведомление покажет клиент, дублировать на телефон не нужно;
- ручки `GET /push/config`, `GET|POST|DELETE /push/subscriptions`, лимиты
10 подписок и 20 уведомлений в минуту; ключ p256dh проверяется как настоящая
точка P-256;
- установщик генерирует `VAPID_PRIVATE_KEY` (openssl, PKCS#8 DER в base64) и
`VAPID_SUBJECT`, ключ переиспользуется при переустановке; для ручной установки
есть `glchat vapid-keys`; `features.web_push_enabled` виден в `/meta`.
Тесты: правила и VAPID, доставка с поддельным push-эндпоинтом (шифрование,
заголовки VAPID/TTL/Topic, очистка мёртвых подписок), ручки и лимиты, отправка
при личном сообщении и упоминании, пропуск онлайн-получателей, миграция на
чистой БД.
Беседа на несколько участников живёт в тех же таблицах, что и 1:1
(channels.type = 'dm' + dm_participants), добавляется только владелец
(channels.dm_owner_id, миграция 00020).
Сервер: POST /users/@me/channels/group (2–9 приглашённых, имя необязательно —
собирается из имён), PUT/DELETE /channels/{id}/recipients/{user_id}
(добавляет любой участник, удаляет других и переименовывает только владелец,
выйти может каждый сам), PATCH /channels/{id}. Правила состава: группа — это
3+ участника; при двух беседа снова обычная личная (имя и владелец
сбрасываются), при одном — удаляется вместе с перепиской. Заблокированного
нельзя ни пригласить, ни добавить; посторонним беседа не видна (404).
READY и REST отдают is_group, name, member_count, owner_id и состав;
участники получают DM_CHANNEL_CREATE/DM_CHANNEL_UPDATE, удалённый —
DM_CHANNEL_DELETE.
Клиент: группа в сайдбаре с числом участников (без точки чужого статуса),
шапка беседы с числом участников и именами в подсказке, создание группы из
списка друзей (минимум двое) с переходом в новую беседу.
Тесты: Go — полный жизненный цикл (создание, состав у каждого участника,
добавление, запрет посторонним, удаление владельцем, выход, превращение в
1:1, удаление последней беседы), валидация (меньше трёх, дубликаты,
заблокированный) и группа в READY; web — 4 vitest (сайдбар, шапка, создание,
выключенная кнопка).
Установщик ждал /readyz на 127.0.0.1:8080, хотя во внешнем режиме и на
стенде приложение слушает адрес туннеля (--app-bind-addr): установка
всегда сообщала «приложение не ответило за 60 с» и «готовность не
подтверждена», хотя инстанс был жив.
Логика та же, что в deploy/update.sh, restore.sh и glchat-cli.sh
(0.0.0.0/пусто → 127.0.0.1); адрес печатается в сообщении, чтобы причина
была видна сразу.
После отзыва ключа виртуальный аутентификатор ещё хранит credential и
подписывает challenge, поэтому отказ приходит от сервера
(auth.passkey_unknown): проверяем, что страница входа показывает ошибку и
не пускает в приложение, а не конкретный testid клиентской ошибки.
Живой прогон на стенде: регистрация ключа, вход по нему без пароля и
отзыв — 1 passed (виртуальный аутентификатор Chromium через CDP).
Установщик писал значения OAuth в кавычках, а при повторной установке
снимал их из .env вместе с кавычками и добавлял новые: получалось
`OAUTH_GITHUB_CLIENT_ID=""""`, и docker compose отказывался читать .env
(«unexpected character "\"" in variable name»), из-за чего стек не
поднимался после --reconfigure.
Теперь oauth_value снимает кавычки при чтении, а env_quote ставит их
только значениям со спецсимволами. Заодно уже испорченный .env лечится
сам: кавычки снимаются, значение записывается пустым.
На стенде таблицу oauth_accounts успела создать промежуточная редакция
миграции 00018 (в ней passkeys и OAuth жили одним файлом), при этом версия
00018 записалась, а 00019 — нет: при обновлении инстанс падал в цикле
перезапуска на «table oauth_accounts already exists».
CREATE TABLE/INDEX IF NOT EXISTS делают миграцию идемпотентной: на чистой
базе она по-прежнему создаёт таблицу, на стенде — просто фиксирует версию.
Фаза 7, AGENT.md 7.1: провайдеры включаются переменными окружения
OAUTH_<PROVIDER>_CLIENT_ID/SECRET, привязка внешнего аккаунта идёт по
подтверждённому провайдером email через blind index, вход забаненному на
инстансе запрещён, все входы и привязки попадают в события безопасности,
привязка — ещё и в аудит инстанса.
Внешний идентификатор (subject) хранится только индексом HMAC-SHA-256,
токены провайдеров не сохраняются вовсе; state подписывается ключом сессий
и ограничен по времени, редирект после входа — только внутренний путь.
Если провайдер не настроен, ручка отвечает oauth.provider_not_configured,
а клиент показывает человеческий текст вместо кнопки.
Клиент: кнопки входа по списку включённых провайдеров на экране входа и
раздел «Вход через внешние сервисы» в настройках безопасности; адрес
возврата для настроек приложения виден в GET /auth/oauth/providers.
Миграция 00019 добавляет таблицу oauth_accounts. Установщик и .env.example
знают про OAUTH_* и сохраняют значения при --reconfigure.
Тесты: Go — выключенный провайдер, подписанный state (подмена и чужой
провайдер), создание и повторный вход, привязка к существующему аккаунту,
неподтверждённый email, выключенная регистрация, бан инстанса, mocked
провайдер (httptest) для обмена кода; web — кнопки провайдеров и ошибка
возврата; серверная ручка отдаёт понятный отказ без настроек.
Фаза 7, AGENT.md 7.1: регистрация ключа в настройках безопасности с
обязательным step-up, вход по ключу без пароля (в т.ч. без ввода почты —
обнаруживаемый ключ), несколько ключей на аккаунт, отзыв и переименование,
события безопасности и аудит.
Сервер: github.com/go-webauthn/webauthn (BSD-3-Clause), RP ID и Origin
берутся из конфига домена; если домен — IP-адрес (стенд без домена),
passkeys честно выключены (auth.passkey_unsupported). Церемонии живут в
памяти процесса 5 минут и одноразовые: повторная отправка challenge
отклоняется. Миграция 00018 пересобирает неиспользуемую таблицу
webauthn_credentials под полную запись credential в JSON. Новые ручки
входа ограничены по IP (10/мин).
Клиент: тонкая обёртка над navigator.credentials без тяжёлых SDK,
раздел «Ключи доступа» в настройках безопасности и кнопка «Войти по ключу»
на экране входа; понятные сообщения для браузеров без поддержки WebAuthn
и при отмене диалога.
Тесты: Go — регистрация/вход с эмулятором аутентификатора (реальная
проверка подписи P-256), отказ при чужом challenge, одноразовость
церемонии, обязательный step-up при управлении ключами, запрет входа
забаненному, ограничение allowCredentials при входе с почтой, лимит и
валидация имени; web — 12 vitest с моком navigator.credentials;
Playwright — живой сценарий с виртуальным аутентификатором Chromium.
AGENT.md 7.10 требует, чтобы действия с сообщениями были в журнале сервера, а
§11.5 перечисляет удаление и закрепление как действия инстанс-админа на чужом
сервере. Обе ручки рассылали только события Gateway, записей в аудите не было.
`message.edit` намеренно не пишется: история правок не хранится (7.6), а
правка своего сообщения — не модерационное действие и не входит в §11.5.
Личные беседы в аудит не попадают: у них нет сервера, а журнал ведётся по
серверам (7.10).
Тест: internal/server/audit_messages_test.go — удаление, pin и unpin чужого
сообщения инстанс-админом помечены `actor_instance_admin`, действие владельца
в журнале есть, но без флага; личные сообщения в аудит не пишутся.
`GUILD_SOUNDS_UPDATE` приносит набор звуков целиком, но раздел «Звуки» читает
REST-кэш: клиент инвалидировал запрос вместо того, чтобы положить в кэш сам
payload события. Под нагрузкой повторный `GET /guilds/{id}/sounds` попадает
под лимит частоты (429), а запрос списка идёт с `retry: 0` — список оставался
старым, и новый звук не появлялся в разделе. Так падал пункт 5 матрицы 11.6 в
полной прогонке (build/e2e-all-run8.log, run9): в логах стенда видно
`POST .../sounds 200`, следом `GET .../sounds 200` (первый звук) и
`GET .../sounds 429` (второй) — без единой повторной попытки.
Теперь событие пишет список в кэш запроса, а ошибка перезапроса не прячет уже
полученный список: раздел показывает актуальный набор из снапшота.
Тест: web/tests/soundSettings.test.tsx — звук из `GUILD_SOUNDS_UPDATE`
появляется, когда список по REST отвечает 429.
Клиент играет звук асинхронно: сначала скачивает файл через /files/{id} в
blob, и только потом создаёт Audio и зовёт play(). Подпись о проигрывании
появляется раньше звука, а проверка читала счётчики сразу после неё и ловила
гонку: в прогоне build/e2e-all-run8.log пункт 27 падал с __soundCalls = 0,
хотя сервер отвечал 200 и запрос файла уже шёл. Ждём факт запуска через
expect.poll — проверка снова проверяет воспроизведение, а не скорость сети.
Пункт был недоступен раньше: без медиапути LiveKit тест скипался, поэтому
гонка не проявлялась.
Пункты 3, 10 и 11 матрицы и тест саундборда падали не на продукте, а на
инфраструктуре: ICE через TURN на VPS не поднимается (STUN отвечает, но все
ICE-пары `failed` с `requestsReceived: 0`), и проверка трижды ждала кнопку
входа, после чего падал весь прогон.
В support.ts добавлен общий помощник joinVoiceIfPossible/joinVoiceOrSkip:
- три попытки, как раньше, но при уже показанной клиентом ошибке повтор не
делается, а ожидание ограничено 25 секундами;
- при неудаче проверяется серверная часть входа (POST .../voice/join →
токен LiveKit): живой сервер при мёртвом ICE — блокер среды, проверка
скипается с точной причиной; нерабочая ручка — дефект продукта, тест
падает. Проба ограничена по времени, а ответ 429 считается признаком
живого сервера (лимит частоты к медиапути отношения не имеет);
- п. 11 при недоступном голосе не отменяется: голосовой мьют пропускается
с аннотацией и предупреждением в лог, а тайм-аут, кик, возврат сервера в
рейку и бан по-прежнему проверяются.
Три локальные копии joinVoice заменены одним помощником.
Прогоны на стенде (образ с HEAD): матрица 18 passed / 0 failed / 3 skipped,
§11.5 — 8 passed, два прогона подряд совпали; без правки было 3 failed.
§11.5 требует, чтобы каждое мутирующее действие писалось в журнал сервера
с `actor.instance_admin=true`, но у PATCH /guilds/{id},
PATCH /guilds/{id}/members/{user_id} и у ручек комнат вызова `recordAudit`
не было: переименование сервера, смена ника, тайм-аут и создание, правка и
удаление комнаты не оставляли следа ни у владельца, ни у инстанс-админа.
- guild.update, member.update, member.timeout (в причине — срок тайм-аута),
channel.create, channel.update, channel.delete;
- Go-тест TestAuditCoversGuildMemberAndChannelChanges проверяет записи на
чужом сервере и флаг actor_instance_admin, а также что действие владельца
этим флагом не помечается;
- e2e 19b в instance-admin.spec.ts включён вместо test.fixme с диагностикой.
Проверки: go test -tags sqlite_fts5 -race -count=1 ./internal/... — ok;
make go-lint — 0 issues; живьём на стенде тест 19b проходит.
Проверки, которые в матрице 11.6 обходились по REST, теперь идут через
интерфейс (AGENT.md 7.13, 7.15, 11.6).
- 25: 🔗/⚙/+ видны владельцу и не видны обычному участнику, а после выдачи
роли с правами управления появляются без перезагрузки;
- 26: статус комнаты и медленный режим появляются в шапке по событию и
пропадают при снятии;
- 27: саундборд — панель открывается в голосовой комнате, проигрывание
уходит на сервер (200), звук играет локально (счётчик вызовов
`Audio.play`, подпись «включил звук»). Если медиапуть LiveKit не
поднялся, тест скипается с причиной: это внешняя зависимость;
- 28: счётчик непрочитанных в сайдбаре и явная фиксация того, что центра
уведомлений в клиенте нет (заглушка — только переключатель системных
уведомлений в настройках).
Сценариев личных серверов и личных бесед в матрице 11.6 не было
(AGENT.md 7.2, 7.8, 7.9). Новый спек идёт под тем же флагом
`GLCHAT_E2E_REALTIME=1` и тем же стилем: два браузера, `support.ts`,
`trackLoads`, уборка в `finally`.
- 21: личный (непубличный) сервер — вход по ссылке-приглашению в браузере,
сервера нет в каталоге, вход без приглашения 403, вошедший видит историю;
- 22: DM 1:1 — непрочитанное в списке бесед, история, «печатает», ответ из
интерфейса, правка и удаление без перезагрузки;
- 23: заявка в друзья и её принятие кнопкой в интерфейсе;
- 24: блокировка из списка друзей — писать нельзя в обе стороны
(`dm.blocked`), беседа не открывается, разблокировка возвращает переписку.
Приглашение (1 на прогон) создаёт владелец: суточная квота — 10 на
пользователя (AGENT.md 8.6).
Чек-лист §11.5 проверялся отдельными скриптами и живьём, но в спеках его
не было. Новый файл (`GLCHAT_E2E_INSTANCE=1`) работает на сервере, где
админ не участник: владелец — `rtprobe`, участник — `rtprobe2`.
- 14: видимость — чужой приватный сервер в `GET /instance/guilds` и в
списке серверов админа, комнаты, история, поиск, участники, роли, баны,
инвайты, эмодзи, звуки, вебхуки, аудит; чужие DM по-прежнему 404;
- 15: управление без 403 — имя сервера, ник владельца, роли (создание,
поднятие выше своей, выдача и снятие), комнаты; аудит помечает действия
`actor_instance_admin=true`;
- 16: модерация — бан с причиной и автором, разбан, кик, тайм-аут; попытки
владельца кикнуть/забанить/замутить/лишить роли админа дают 403
`instance.admin_protected`;
- 17: обход лимитов — slowmode, приватность комнаты, лимит участников
голосовой комнаты;
- 18: UI — админ входит в чужой приватный сервер из рейки без инвайта,
пишет в приватную комнату, а участник видит переименование и кик без
перезагрузки;
- 19: аудит — прежние записи не затираются; 19b (`test.fixme`) фиксирует
пробел: переименование сервера, ник и комнаты в аудит не пишутся;
- 20: безопасность не обходится — step-up на свежей сессии, чужой Origin,
лимит реакций 429.
Уборка тестовых серверов — в `finally` от имени админа (удаление чужого
сервера требует step-up).
Новые спеки (§11.5, личные серверы и шапка сервера) используют тот же
набор шагов, что матрица 11.6, но её помощники лежали внутри
`realtime.spec.ts`. Вынес в `support.ts`, чтобы не копировать их в третий
раз: сессии и лимит входов, повтор при 429, step-up (в том числе с 2FA
админа), подготовка сервера и уборка, комнаты, роли, сообщения, звуки,
личные беседы, друзья и блокировки.
По MEMBER_UPDATE/ROLE_* клиент перечитывал участников, роли и комнаты, но
не сводку сервера: `my_permissions` в сторе сессии оставались прежними, и
кнопки управления (🔗 приглашение, ⚙ настройки, + комната) появлялись
только после перезагрузки. Матрица 11.6 требует, чтобы права сразу меняли
доступные действия (AGENT.md 11.6).
- в ветках `MEMBER_UPDATE`/`MEMBER_REMOVE` и `ROLE_*` вызывается
`addGuildFromRest` — сводка сервера перечитывается и мержится;
- vitest: кнопки появляются по событию (тест падает без правки).
grendervill