On Mon, Aug 20, 2007 at 12:00:23PM +0400, umask wrote:
> 20.08.07, 10:22, Igor Sysoev <is@xxxxxxxxxxxxx>:
>
>
>
> > On Mon, Aug 20, 2007 at 10:16:56AM +0400, Igor Sysoev wrote:
>
> > > > a0001 LOGIN user@xxxxxxxxxxx " 12345"
>
> > > >
>
> > > >
>
> > > > Cyrus IMAP и DBMail напрямую принимают такую команду нормально и логин
> > > > проходит, а вот если логин происходит через nginx, то проблема
> > > > проявляет себя несколько иначе, чем раньше: в лог nginx пишет ошибка
> > > > авторизации, а на внешнем сервере авторизации пароль получается без
> > > > пробела.
>
> > > >
>
> > > >
>
> > > >
>
> > > > Видимо в HTTP-сессии к внешнему серверу авторизации надо как-то
> > > > экранировать пароль... (и логин, возможно).
>
> > >
>
> > > Насколько я вижу из отладочного лога, nginx передаёт
>
> > >
>
> > > Auth-User: user@xxxxxxxxxxx
>
> > > Auth-Pass: 12345
>
> > >
>
> > > то есть, пробел в начале передаётся, но не экранируется. Экранируются
>
> > > \d и \a. А вообще пробелы в паролях - это плохая идея, это нужно рубить
>
> > > ещё на стадии регистрации и смены пароля.
>
> > Прилагаемый патч включает в себя предыдущий и экранирует пробел.
>
>
>
>
>
> Патч работает, как Вы и сказали.
>
> Но есть сложность. Пароль может содержать '%20' в качестве трёх символов
> пароля, т.е. '%20' воспринимается буквально, а не как часть закодированного
> URL.
>
>
>
> Надо решить как быть. Я вижу такие варианты:
>
>
>
> 1. метод страуса - игнорировать то, что подобные проблемы с паролем и
> пробелами в нём могут вылезти. Игнорировать так же и то, что многие
> imap-сервисы корректно работают с паролями, содержащими пробел в любой своей
> части. И вообще объявить алфавит для логина и пароля (нечто вроде a-zA-Z0-9).
>
>
>
> 2. при передаче пароля на внешний сервер авторизации енкодить пароль в BASE64
> или подобно функции PHP urlencode. В таком случае полностью теряется
> совместимость со старыми серверами HTTP-авторизации.
>
>
>
> 3. на внешний сервер HTTP-авторизации передавать заголовки логина и пароля в
> кавычках. В таком случае начальные и конечные пробелы не потеряются, а
> кавычки можно вырезать при желании. В пароле никакие символы не заменяются.
>
>
>
> Игорь, что вы скажете?
Второй и третий способ одинаково ломают совместимость с существующими
серверами HTTP-авторизации. nginx уже кодирует два символа - \r и \n,
поэтому я буду экранировать всё 0x00-0x20 и %.
--
Игорь Сысоев
