gotosocial/openspec/changes/fix-apex-webfinger-and-registration/proposal.md at cd7e279bb659c7af2c5be41be883ef15566da3dd

mirror of https://gitverse.ru/kpa39l/gotosocial.git synced 2026-09-29 09:55:10 +00:00

Files

T

estorozhenko cd7e279bb6 feat(registration): open signups, 10/day limit; openspec: fix-apex-webfinger-and-registration

- docker-compose.yml: GTS_ACCOUNTS_REGISTRATION_OPEN=true, GTS_ACCOUNTS_REGISTRATION_DAILY_LIMIT=10
- openspec: proposal/specs/design/tasks for dynamic apex webfinger + registration + SMTP verify
- verified: /api/v1/instance → registrations:true; apex webfinger → acct:kpa39l@dedinit.ru; SMTP test OK

2026-09-07 05:48:46 +00:00

4.2 KiB

Raw Blame History

Why

Пользователь обнаружил, что в клиентах Tusky и Mastodon адрес его аккаунта отображается как @kpa39l@social.dedinit.ru (длинный), хотя ожидался короткий @kpa39l@dedinit.ru. Дополнительно: в феде виден только свой пост, и нужно открыть регистрацию на инстансе (до 10 пользователей в день).

Investigation

Разбор показал:

Корень проблемы с адресом — статический WebFinger на apex-домене:
- Инстанс (GtS) настроен split-domain: host=social.dedinit.ru, account-domain=dedinit.ru. Сам GtS отдаёт корректный webfinger: https://social.dedinit.ru/.well-known/webfinger?resource=acct:kpa39l@dedinit.ru → subject: acct:kpa39l@dedinit.ru (короткий).
- Но клиенты (Tusky/Mastodon) при резолве @kpa39l@dedinit.ru ходят на apex dedinit.ru/.well-known/webfinger, где лежал статический index.html с захардкоженным JSON про estorozhenko (игнорировал resource). Клиент получал ответ про другого пользователя → показывал фолбэк-адрес на основе host (social.dedinit.ru).
Регистрация была закрыта: /api/v1/instance → registrations: false, approval_required: true.
SMTP настроен (smtp.jino.ru:587, social@dedinit.ru), но не проверялся.

Solution

1. Динамический WebFinger на apex (Jino)

Apex обслуживается на Jino (Apache, без PHP/SSH-exec). Проверено: mod_alias RedirectMatch работает. В .htaccess (webroot /.well-known/webfinger/) добавлен редирект:

RedirectMatch 301 ^/\.well-known/webfinger(.*)$ https://social.dedinit.ru/.well-known/webfinger$1

Теперь dedinit.ru/.well-known/webfinger?resource=... отдаёт 301 на GtS, который динамически резолвит ЛЮБОЙ аккаунт (включая будущих пользователей) — короткий адрес @user@dedinit.ru восстанавливается для всех клиентов.

Аналогичный редирект добавлен для /.well-known/nodeinfo.

host-meta на apex уже указывал на template social.dedinit.ru/.well-known/webfinger — оставлен.

2. Регистрация (10 пользователей/день)

В docker compose.yml (env GTS_*):

GTS_ACCOUNTS_REGISTRATION_OPEN: "true"
GTS_ACCOUNTS_REGISTRATION_DAILY_LIMIT: "10"
GTS_ACCOUNTS_REGISTRATION_BACKLOG_LIMIT: не задан → дефолт 20 (очередь одобрения). При желании можно поставить явно.

approval_required остаётся true (GtS по умолчанию требует одобрение админом новых аккаунтов; при лимите 10/день очередь управляема).

3. Проверка SMTP

SMTP-конфиг проверен тестовым письмом: smtp.jino.ru:587 STARTTLS, auth social@dedinit.ru → письмо успешно отправлено на kpa39l@yandex.ru. SMTP работает, проблем нет.

Files Changed

docker-compose.yml (gotosocial): +2 env registration
static/.well-known/webfinger/.htaccess (dedinit.ru): RedirectMatch 301
static/.well-known/nodeinfo/.htaccess (dedinit.ru): RedirectMatch 301
Jino webroot: удалён статический index.html из /.well-known/webfinger/ (заменён .htaccess-редиректом)

Verification

curl -L 'https://dedinit.ru/.well-known/webfinger?resource=acct:kpa39l@dedinit.ru' → subject: acct:kpa39l@dedinit.ru (короткий)
curl -L 'https://dedinit.ru/.well-known/webfinger?resource=acct:estorozhenko@dedinit.ru' → subject: acct:estorozhenko@dedinit.ru
curl 'https://social.dedinit.ru/api/v1/instance' → registrations: true
SMTP-тест: OK

4.2 KiB Raw Blame History Unescape Escape

Why