> Это именно те для которых нет "отметки" об аутентификации со стороны
> front-end. Почему: бэкэндов (приложений) может быть много - может оказаться
> трудно заставить их возвращать одно и то же по одинаковым правилам.
AFAIR, заголовок "Authorization: Basic ..." должен обрабатываться
всегда по одинаковым правилам. Если бекенды хотят именно basic auth -
мы можем положиться на то, что в случае отказа в доступе они вернут
401.
> В Апаче это сделано так, что можно прикрутить любой имеющийся authprovider и
> использовать его. Думаю это намного быстрее (например обращение в ldap или
> локальный файл) чем проксировать запрос особенно в случае если нужно
> проверять аутентификацию для каждого запроса. Если я правильно понимаю то
> при отсутствии keepalive загрузка одной страницы может привести к 10-кам
> запросов.
AFAIK, authprovider-ов в nginx сегодня ровно один - basic из файла.
Написать новый - это я сейчас не готов.
И - нет, Вы понимаете неправильно. Нет разницы - проксировать запрос,
или ходить в ldap. Только для хождения в ldap в nginx нет средств.
Почему это важно - я объясню ниже.
>> Да, и как именно мы модифицируем запрос?
> Тут не понял о каком запросе идет речь?
Правильно ли я понимаю, что все, что нам надо сделать - это добавить в
запрос, проксируемый на бекенд, заголовок basic аутентификации? Или
еще что-то надо в нем поменять?
> Бекэнды это темные лошадки - им дается заполненный basic header и что они
> делают по нему это исключительно их дело. Главное при проходе через
> front-end иметь опцию - аутентификация при каждом запросе (например запрос в
> LDAP по имеющимся login/password) или доверие к уже имеющемуся куку и
> передача login/pass из куки бэкендам без дополнительной валидации.
Я подумал еще раз, и понял, что не будет ldap-а - нет смысла
втаскивать в nginx функциональность, которая уже прекрасно работает в
апаче.
Режимов проверки пароля будет два - plain/bdb файл и http. http
означает, что за спиной у nginx стоит апач, которому nginx отправляет
запрос, снабдив его basic auth info. По тому, ответил апач 200 или 401
мы и определяем, правильные ли имя-пароль. А как там апач пароль
проверяет - его дело.
Да, это означает усложнение настройки. Но как сделать по-другому, не
превращая nginx в апача - я не знаю. А апач у нас уже есть, вполне
годный.
Режим ревалидации каждого запроса - можно сделать, но работать все
будет со скоростью бекенда. Так что непонятно - надо ли оно.
> Может ли логгер иметь доступ ко всем полям запроса? Тогда же можно в
> качестве кастомного логгера написать что угодно - например класть в базу
> данных структурированную инфу.
> Особенно хорошо если этот логгер будет уметь работать асинхронно - не
> тормозя поток в котором идет HTTP запрос.
Не-не-не. Только локальный файл. Поля запроса вытащим, это не проблема.
> Думаю тут и не нужно передавать имя пользователя. Имя пользователя уже в
> сессии (в куке)
Годидзе. Если один из бекендов вернул 401 - заставляем пользователя
перелогиниться. Только на более, чем один фронтенд это масштабируется
плохо.
> Думаю насколько можно больше :) Ограничения сами вылезут из деталей - я их
> пока не знаю.
Ок. Тогда я не парюсь и пользуюсь shared mem.
> Не вижу смысла тут ставить какие-то ограничения - пусть все будет на совести
> того кто эти вызовы добавит. В базовой же версии действительно никуда ходить
> не надо - нужно только имея текущее состояние что-то добавить - например
> Basic Header
А я не вижу смысла добавлять бесполезное API. А оно будет бесполезное
- см. ниже.
>> Сложно - это получить запрос, прогуляться на сторону за доп.
>> информацией, и продолжить в соответствии с полученным.
> На самом деле не понимаю почему это сложно если существуют модули типа
> mod_rewrite? Они же изменяют тела запросов меняя в них гиперлинки?
Сложно - не запрос менять, а на сторону ходить. Если мы получили
управление из nginx - мы должны как можно скорее вернуть его обратно,
потому что, пока мы его не вернем - обработка всех остальных запросов
стоит. А даже простое создание ТСР-соединения - занимает существенное
время.
Я вот что подумал. Есть же Апач с его mod_perl. Если нужна валидация
каждого запроса, и вызов стронних процедур - надо на нем и делать.
Технически это возможно и на nginx, но - будет работать так же, или
хуже. Скорее - хуже...
