Назад | Перейти на главную страницу

nginx: понимание цели auth_http (прокси IMAP)

Я хотел бы отправлять клиентские запросы IMAP на серверную часть IMAP через прокси-сервер nginx. Согласно mail_auth_http модуль, директива auth_http должен использоваться для аутентификации клиентов. Но какова цель auth_http, почему нельзя просто перенаправить процесс аутентификации на серверную часть IMAP?

Насколько я знаю, auth_http указывает на сценарий аутентификации, который использует собственный протокол HTTP, чтобы определить, какой сервер будет использоваться и т. д., а фактическая аутентификация на основе IMAP полностью пропускается. Я прав?

Я был бы признателен, если бы кто-нибудь мог опубликовать практический пример.

В auth_http делает две основные вещи:

  • Он аутентифицирует пользователей (включая различные варианты эффективной задержки пользователей при неудачной аутентификации).
  • И он определяет, какой бэкэнд использовать (и какое имя пользователя и пароль использовать при бэкэнд-аутентификации, если вообще).

Хотя в некоторых случаях аутентификация может выполняться напрямую серверной частью, это не всегда возможно. Более того, если nginx необходимо использовать в качестве почтового прокси, это почти всегда означает, что существует несколько бэкэндов, а бэкэнд не известен заранее.

Также более эффективно обрабатывать аутентификацию (в частности, ошибки аутентификации) с помощью nginx, поскольку почтовые серверы, как правило, используют модель процесса для каждого соединения и не могут эффективно ждать некоторое время, прежде чем вернуть ошибку.

Если вас не волнует все вышеперечисленное и вы хотите, чтобы nginx просто передавал соединение с заранее определенным сервером, вы можете использовать что-то вроде этого в блоке nginx http {} как мертвый простой скрипт auth_http:

location = /auth {
    add_header Auth-Status OK;
    add_header Auth-Server 127.0.0.2;  # backend ip
    add_header Auth-Port   143;        # backend port
    return 204;
}

С таким сценарием аутентификации nginx всегда будет получать успешный результат аутентификации и будет передавать соединение с указанным сервером с именем пользователя и паролем, предоставленным клиентом.

Обратите внимание, что это должно не использоваться с SMTP, так как с SMTP нет бэкэнд-аутентификации.