nginx: понимание цели auth_http (прокси IMAP)
Я хотел бы отправить клиентские запросы IMAP к бэкенду IMAP через прокси nginx. Согласно mail_auth_http модуль, директива auth_http должен использоваться для аутентификации клиентов. Но что точно является целью auth_http, почему процесс аутентификации не может просто быть передан бэкенду IMAP?
Насколько мне известно, auth_http точки к сценарию аутентификации, который использует пользовательский протокол HTTP для определения, какой бэкенд будет использоваться и т.д., и фактическая основанная на IMAP аутентификация, пропускаются полностью. Я корректен?
Я ценил бы его, если кто-то мог бы отправить практический пример.
auth_http делает две основные вещи:
- Он аутентифицирует пользователей (включая различные опции, позволяющие эффективно задерживать пользователей при неудачной аутентификации)
- И определяет, какой бэкэнд использовать (и какое имя пользователя и пароль использовать при аутентификации бэкэнда, если они вообще используются)
Хотя в некоторых случаях аутентификация может быть обработана непосредственно бэкэндом, это не всегда возможно. Более того, если nginx необходимо использовать в качестве почтового прокси-сервера, Это почти всегда означает, что существует несколько бэкэндов и бэкэнд не известен заранее.
Также более эффективно обрабатывать аутентификацию (в частности, ошибки аутентификации) с помощью nginx, так как почтовые серверы склонны использовать модель process-per-connection и не могут эффективно ждать некоторое время, прежде чем вернуть ошибку.
Если вас не волнует все вышесказанное, и вы хотите, чтобы nginx просто передал соединение заранее определенному бэкенду, вы можете использовать нечто подобное в блоке http{} nginx в качестве мертвого простого скрипта 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;
}
С таким скриптом auth nginx всегда получит успешный результат аутентификации, и он передаст соединение указанному бэкенду, с именем пользователя и паролем, предоставленными клиентом.
Обратите внимание, что это должно использоваться а не с SMTP, так как не существует аутентификации бэкенда с SMTP.
.