Files
gotosocial/openspec/changes/fix-apex-webfinger-and-registration/proposal.md
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

80 lines
4.2 KiB
Markdown
Raw Blame History

This file contains ambiguous Unicode characters
This file contains Unicode characters that might be confused with other characters. If you think that this is intentional, you can safely ignore this warning. Use the Escape button to reveal them.
## Why
Пользователь обнаружил, что в клиентах Tusky и Mastodon адрес его аккаунта
отображается как `@kpa39l@social.dedinit.ru` (длинный), хотя ожидался короткий
`@kpa39l@dedinit.ru`. Дополнительно: в феде виден только свой пост, и нужно
открыть регистрацию на инстансе (до 10 пользователей в день).
## Investigation
Разбор показал:
1. **Корень проблемы с адресом** — статический 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`).
2. **Регистрация** была закрыта: `/api/v1/instance` → `registrations: false`,
`approval_required: true`.
3. **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