Спасибо, по большей части ситуация понятна. С nginx я до этого не работал, поэтому не было общего представления на что нацелен этот сервер. Думал что он прямой конкурент апачу во всем + есть еще активное коммунити. В апаче же баги просто игнорируют последний год. Те патчи что слали еще год назад до сих пор не в альфе 2.3<br>
<br>Выходит в nginx просто так не получить требуемый функционал с четко выделеннным куском кода который можно расширять для своих нужд. А эти самые нужды меняются со временем, что будет через месяц даже сказать трудно - что закажут то и будет.<br>
<br>В апаче mod_perl даже не знаю стоит ли смотреть - вроде и без него уже есть почти то что надо (mod_auth_form), но его функционал очень ограничен. Писать с нуля аналог - плохо тк не профессионал в мод-писательстве. Нужно же чтобы этот модуль правильно работал в стеке с остальными (mod_proxy, mod_auth.., mod_crypto, mod_session ...)<br>
<br>Форкать и доразвивать существующее для своих нужд - видно только это и остается.<br>Вообще если честно удивлен что для такой необходимой штуки для сложных порталов как SSO ни у одного из серверов сейчас нет стабильного стандартного решения... <br>
<br><br><div class="gmail_quote">2010/2/26 Daniel Podolsky <span dir="ltr"><<a href="mailto:onokonem@gmail.com">onokonem@gmail.com</a>></span><br><blockquote class="gmail_quote" style="margin: 0pt 0pt 0pt 0.8ex; border-left: 1px solid rgb(204, 204, 204); padding-left: 1ex;">
<div class="im">> Это именно те для которых нет "отметки" об аутентификации со стороны<br>
> front-end. Почему: бэкэндов (приложений) может быть много - может оказаться<br>
> трудно заставить их возвращать одно и то же по одинаковым правилам.<br>
</div>AFAIR, заголовок "Authorization: Basic ..." должен обрабатываться<br>
всегда по одинаковым правилам. Если бекенды хотят именно basic auth -<br>
мы можем положиться на то, что в случае отказа в доступе они вернут<br>
401.<br>
<div class="im"><br>
> В Апаче это сделано так, что можно прикрутить любой имеющийся authprovider и<br>
> использовать его. Думаю это намного быстрее (например обращение в ldap или<br>
> локальный файл) чем проксировать запрос особенно в случае если нужно<br>
> проверять аутентификацию для каждого запроса. Если я правильно понимаю то<br>
> при отсутствии keepalive загрузка одной страницы может привести к 10-кам<br>
> запросов.<br>
</div>AFAIK, authprovider-ов в nginx сегодня ровно один - basic из файла.<br>
Написать новый - это я сейчас не готов.<br>
<br>
И - нет, Вы понимаете неправильно. Нет разницы - проксировать запрос,<br>
или ходить в ldap. Только для хождения в ldap в nginx нет средств.<br>
Почему это важно - я объясню ниже.<br>
<div class="im"><br>
>> Да, и как именно мы модифицируем запрос?<br>
> Тут не понял о каком запросе идет речь?<br>
</div>Правильно ли я понимаю, что все, что нам надо сделать - это добавить в<br>
запрос, проксируемый на бекенд, заголовок basic аутентификации? Или<br>
еще что-то надо в нем поменять?<br>
<div class="im"><br>
> Бекэнды это темные лошадки - им дается заполненный basic header и что они<br>
> делают по нему это исключительно их дело. Главное при проходе через<br>
> front-end иметь опцию - аутентификация при каждом запросе (например запрос в<br>
> LDAP по имеющимся login/password) или доверие к уже имеющемуся куку и<br>
> передача login/pass из куки бэкендам без дополнительной валидации.<br>
</div>Я подумал еще раз, и понял, что не будет ldap-а - нет смысла<br>
втаскивать в nginx функциональность, которая уже прекрасно работает в<br>
апаче.<br>
<br>
Режимов проверки пароля будет два - plain/bdb файл и http. http<br>
означает, что за спиной у nginx стоит апач, которому nginx отправляет<br>
запрос, снабдив его basic auth info. По тому, ответил апач 200 или 401<br>
мы и определяем, правильные ли имя-пароль. А как там апач пароль<br>
проверяет - его дело.<br>
<br>
Да, это означает усложнение настройки. Но как сделать по-другому, не<br>
превращая nginx в апача - я не знаю. А апач у нас уже есть, вполне<br>
годный.<br>
<br>
Режим ревалидации каждого запроса - можно сделать, но работать все<br>
будет со скоростью бекенда. Так что непонятно - надо ли оно.<br>
<div class="im"><br>
> Может ли логгер иметь доступ ко всем полям запроса? Тогда же можно в<br>
> качестве кастомного логгера написать что угодно - например класть в базу<br>
> данных структурированную инфу.<br>
> Особенно хорошо если этот логгер будет уметь работать асинхронно - не<br>
> тормозя поток в котором идет HTTP запрос.<br>
</div>Не-не-не. Только локальный файл. Поля запроса вытащим, это не проблема.<br>
<div class="im"><br>
> Думаю тут и не нужно передавать имя пользователя. Имя пользователя уже в<br>
> сессии (в куке)<br>
</div>Годидзе. Если один из бекендов вернул 401 - заставляем пользователя<br>
перелогиниться. Только на более, чем один фронтенд это масштабируется<br>
плохо.<br>
<div class="im"><br>
> Думаю насколько можно больше :) Ограничения сами вылезут из деталей - я их<br>
> пока не знаю.<br>
</div>Ок. Тогда я не парюсь и пользуюсь shared mem.<br>
<div class="im"><br>
> Не вижу смысла тут ставить какие-то ограничения - пусть все будет на совести<br>
> того кто эти вызовы добавит. В базовой же версии действительно никуда ходить<br>
> не надо - нужно только имея текущее состояние что-то добавить - например<br>
> Basic Header<br>
</div>А я не вижу смысла добавлять бесполезное API. А оно будет бесполезное<br>
- см. ниже.<br>
<div class="im"><br>
>> Сложно - это получить запрос, прогуляться на сторону за доп.<br>
>> информацией, и продолжить в соответствии с полученным.<br>
> На самом деле не понимаю почему это сложно если существуют модули типа<br>
> mod_rewrite? Они же изменяют тела запросов меняя в них гиперлинки?<br>
</div>Сложно - не запрос менять, а на сторону ходить. Если мы получили<br>
управление из nginx - мы должны как можно скорее вернуть его обратно,<br>
потому что, пока мы его не вернем - обработка всех остальных запросов<br>
стоит. А даже простое создание ТСР-соединения - занимает существенное<br>
время.<br>
<br>
Я вот что подумал. Есть же Апач с его mod_perl. Если нужна валидация<br>
каждого запроса, и вызов стронних процедур - надо на нем и делать.<br>
Технически это возможно и на nginx, но - будет работать так же, или<br>
хуже. Скорее - хуже...<br>
<div><div></div><div class="h5">_______________________________________________<br>
nginx-ru mailing list<br>
<a href="mailto:nginx-ru@nginx.org">nginx-ru@nginx.org</a><br>
<a href="http://nginx.org/mailman/listinfo/nginx-ru" target="_blank">http://nginx.org/mailman/listinfo/nginx-ru</a><br>
</div></div></blockquote></div><br><br clear="all"><br>-- <br>Mikhail Fursov<br>