Пользователи и аутентификация

Описание

Общее описание функционала

Пользователи и аутентификация обеспечивают вход в панель управления и защиту операций с туннелями. При новой локальной регистрации в поле Email указывается адрес электронной почты, а в запросе он по-прежнему передаётся в поле login. Это требование относится только к созданию новой учётной записи. Для входа можно использовать сохранённый идентификатор, в том числе прежний логин без адреса электронной почты. После успешной регистрации или входа пользователь остаётся в сессии между визитами и может завершить её выходом из системы. Роль определяет доступ к пользовательским и административным разделам. При необходимости сервис может предложить вход через внешнего провайдера. Учётные записи не объединяются только по совпадению Email: если связь с провайдером ещё не создана, сервис попросит войти с существующим логином и паролем.

Как пользователь может использовать

• Открыть сайт и создать учётную запись, указав Email, пароль и подтверждение пароля.
• Войти в панель управления с адресом электронной почты или с ранее сохранённым логином.
• Продолжить пользоваться существующей учётной записью с непочтовым логином без переоформления данных.
• Исправить Email при сообщении «Укажите корректный email» и повторить регистрацию.
• При сообщении о существующей учётной записи после внешнего входа вернуться к форме и войти с сохранённым логином и паролем.
• При входе через провайдера OpenID Connect использовать адрес, подтверждённый у провайдера; если адрес не подтверждён, вход не выполняется и можно войти с логином и паролем.
• Войти в панель управления и работать с туннелями без повторного ввода учётных данных в течение сеанса.
• Использовать бесплатную учётную запись для создания TCP- и UDP-туннелей в пределах назначенных лимитов.
• Открывать опубликованный адрес как посетитель без входа; если на сервере разрешён гостевой HTTP-режим, он продолжает работать только для HTTP и HTTPS.
• Выйти из системы, когда сеанс больше не нужен.
• Получать доступ к защищённым страницам только после успешного входа.
• Использовать административные разделы, если назначена роль администратора.
• При блокировке аккаунта администратором — получить понятный отказ при попытке входа или проверки профиля.

Как это реализовано в сервисе

Страница регистрации принимает Email, пароль и подтверждение пароля. Если адрес соответствует правилам регистрации, сервис создаёт учётную запись и устанавливает сессию в браузере. Страница входа проверяет сохранённый идентификатор и пароль; поэтому она остаётся совместимой с прежними логинами. Для создания TCP- или UDP-туннеля сервис проверяет действующую сессию либо Bearer-токен до выделения публичного адреса. Посетителю опубликованного адреса вход не требуется. Гостевое создание HTTP и HTTPS остаётся отдельной настройкой и не даёт права создавать TCP или UDP. При истечении срока неактивности или явном выходе доступ к защищённым операциям прекращается до повторного входа.

Справочник API

Регистрация новой учётной записи

POST /auth/register

Тело JSON: login, password, password_confirm. Запрос нужно отправлять с заголовком Content-Type: application/json; параметры вроде charset=utf-8 допустимы.

• login — Email для новой локальной учётной записи. Название поля сохранено для совместимости. Пробелы по краям значения игнорируются, после чего принимается один адрес в ASCII-формате: без пробелов внутри, отображаемого имени, комментариев, кавычек и нескольких символов @. Локальная часть содержит от 1 до 64 символов, не начинается и не заканчивается точкой и не содержит двух точек подряд. Домен содержит не менее двух частей, разделённых точками; каждая часть состоит из букв, цифр или дефисов без дефиса в начале и конце, а последняя часть содержит не менее двух букв. Полный адрес не длиннее 254 символов.
• password — пароль.
• password_confirm — повтор пароля.

Успех: 201, устанавливается сессионная кука, пользователь считается вошедшим.

При некорректном Email сервис возвращает 400 JSON с кодом invalid_email и сообщением Укажите корректный email. Сеанс при таком ответе не создаётся.

Если логин уже занят или адрес недоступен для самостоятельной регистрации, сервис отвечает 400 с кодом login_taken. Если тело отправлено с другим типом содержимого или без заголовка Content-Type, ответ — 415. В обоих случаях учётная запись и сессия не создаются.

Вход

POST /auth/login-local

Тело JSON: login, password. Как и для регистрации, нужен заголовок Content-Type: application/json; иначе сервис отвечает 415, и сессия не создаётся.

login остаётся обычным идентификатором. Он может быть Email или сохранённым прежним логином без адреса электронной почты. Успех: 200, устанавливается сессионная кука.

Выход

POST /auth/logout

Завершает текущую сессию. Успех: 200 или 204 по политике развёртывания.

Текущий пользователь

GET /auth/me

Возвращает сведения о вошедшем пользователе: authenticated, user (логин, роль и др.).

Требует активной сессии для защищённого ответа.

Внешний провайдер (опционально)

При включённом OIDC/OAuth в развёртывании:

• GET /auth/login?provider=<name> — перенаправление на провайдера.
• GET /auth/callback?provider=<name>&code=<code> — обработка ответа провайдера и установка сессии.

Ранее связанная учётная запись определяется по постоянному идентификатору провайдера. Если провайдер впервые возвращает Email, который уже используется другой учётной записью, автоматическое объединение не выполняется: сессия не создаётся, а браузер возвращается к форме входа с сообщением о существующем аккаунте.

При входе через провайдера OpenID Connect адрес электронной почты принимается, только если провайдер подтвердил его. Если адрес не подтверждён, сессия не создаётся, а браузер возвращается к форме входа с сообщением об ошибке.

Конкретные пути и провайдеры зависят от настроек экземпляра сервиса.

Ошибки

Регистрация

Вход

Сессия

Внешний вход

Доступ по роли

Ограничения

• Сеанс истекает после периода неактивности; длительность зависит от настроек развёртывания.
• Вход через внешнего провайдера доступен только если он включён администратором сервиса.
• Гостевой доступ к туннелям не заменяет регистрацию для защищённых страниц панели.
• После блокировки аккаунта администратором активные сессии прекращаются при следующей проверке профиля.
• При регистрации проверяется только синтаксис Email. Сервис не подтверждает владение почтовым ящиком, не отправляет письма и не выполняет проверку MX или DNS.
• Проверка Email не изменяет существующие учётные записи: это не перенос данных и не требование заменить прежний логин. Непочтовый логин можно использовать для входа через POST /auth/login-local и в форме входа браузера.
• Повтор адреса определяется без учёта регистра, как и раньше: значение сохраняется в нижнем регистре. Сервис не изменяет точки, часть адреса после + или другие особенности адресов отдельных почтовых сервисов.
• Внешний вход не объединяет учётные записи только по совпадению Email. Ранее созданная связь с провайдером продолжает работать; для первого входа с уже занятым Email нужно использовать существующий логин и пароль. Отдельного интерфейса объединения учётных записей пока нет.
• Если сеанс в админ-консоли истёк или вы вышли из системы, браузер перейдёт на главную страницу сервиса, где можно войти снова. После входа откроется список туннелей в личном кабинете, а не админ-консоль.
• Запросы регистрации и входа принимаются только в формате JSON с заголовком Content-Type: application/json. Интеграция, которая отправляет форму или обычный текст, получает 415.
• Самостоятельная регистрация не даёт права администратора. Адреса, которые владелец сервиса назначил администраторами, через форму зарегистрировать нельзя: ответ такой же, как для занятого логина. Административный доступ выдаёт владелец сервиса или внешний вход с подтверждённым адресом.
• Вход через провайдера OpenID Connect принимает только адрес электронной почты, который подтвердил провайдер. Неподтверждённый адрес приводит к отказу во входе, учётная запись при этом не создаётся.