Відновлення доступу до облікового запису

Якщо ви втратили доступ до SnapOtter (найчастіше через політику MFA, якій ви більше не можете відповідати), ви можете відновити доступ зсередини контейнера без клієнта бази даних. Команди відновлення працюють офлайн і потребують доступу до оболонки контейнера, а це вже означає повний контроль над екземпляром.

На яку перешкоду я наштовхнувся?

Вхід у SnapOtter застосовує два незалежні бар'єри MFA. Спершу діагностуйте:

docker exec -it snapotter snapotter-admin status

Це виводить поточну політику MFA та те, які користувачі мають зареєстрований TOTP.

• «MFA enrollment is required before login» (а ви ніколи не налаштовували застосунок): політика вимагає MFA, але у вас немає реєстрації. Послабте політику.
• Вас просять ввести код, який ви не можете отримати (втратили телефон і свої коди відновлення): ваш обліковий запис зареєстрований. Скиньте цю реєстрацію.

Послаблення політики MFA

docker exec -it snapotter snapotter-admin reset-mfa-policy

Це повертає політику назад до optional. Вона застосовується під час наступного входу без перезапуску. Вона лише коли-небудь встановлює optional, тож не може знову ввімкнути примусове застосування.

Скидання реєстрації TOTP одного користувача

docker exec -it snapotter snapotter-admin disable-mfa <username>

Якщо політика все ще вимагає MFA для цього користувача, він наштовхнеться на бар'єр реєстрації наступним, тож також виконайте reset-mfa-policy, увійдіть і зареєструйтеся заново в Налаштуваннях.

Старіші образи та резервні варіанти

На образі, зібраному до того, як з'явилася обгортка snapotter-admin, викликайте скрипт безпосередньо:

docker exec -w /app/apps/api snapotter ./node_modules/.bin/tsx \
  src/scripts/mfa-recover.ts reset-mfa-policy

Як крайній захід на будь-якій версії, задайте політику в базі даних. На образі «все в одному» Postgres працює всередині контейнера:

docker exec -it snapotter psql -h 127.0.0.1 -U snapotter -d snapotter \
  -c "UPDATE settings SET value = 'optional' WHERE key = 'mfaPolicy';"

На конфігурації з кількома контейнерами натомість спрямуйте psql на власний DATABASE_URL.

Заблоковано доступ до SSO, а не MFA?

Якщо примусовий вхід через SSO не працює, скористайтеся натомість аварійним локальним обліковим записом: задайте ssoBreakGlassUsername для локального адміністратора в Налаштування > Безпека, перш ніж ви увімкнете примусове застосування SSO, і увійдіть з паролем цього облікового запису.