WackoWiki : Wacko Ideas / HTTP Auth

AndreyCherezov: Хорошо, что про TWiki вспомнил. Что там еще сделано удачно – это авторизация. Авторизация с использованием средств веб-сервера лучше, чем через форму: во-первых, появляется еще одна степень свободы (управление правами не только викой, но и веб-сервером, что смягчает проблему возможных vulnerabilities в вике), во-вторых, в браузерах управление запоминанием http-паролей реализовано лучше чем у куков, в-третьих, опять-таки, бесплатные дополнительные фичи – авторизованный сервером юзер попадает в лог веб-сервера, а хранимая в куках авторизация – нет. Если еще не приходилось писать такую авторизацию – см. наводки по PHP_AUTH_USER и PHP_AUTH_PW.
Ку Куц: ждём вашего патча с http-авторизацией.
- AndreyCherezov: Действительно руки сильно чешутся взять и исправить в ваке всё самому :) Т.к. это проще, чем объясняться с авторами ;) Собственно с предыдущими виками, включая Php Wiki?, я так и делал – правил, высылал патчи разработчикам через их списки рассылки. Но в ваку и Bitrix Sitemanager? не лезу принципиально, чтобы не стать членом команды разработчиков. И так уже слишком во многие проекты вовлечен. С HTTP-авторизацией очень просто: если REMOTE_USER установлен, и если это не IP-адрес (как делают некоторые серверы), то считать юзера авторизованным – как если бы у него был кук с авторизацией. Запрос авторизации в этом случае делается в настройке сервера: допустим, при URL, оканчивающемся на /edit. С PHP_AUTH_* немного иначе, сверку пароля и перезапрос при неудаче делает уже не сервер, а php-программа: если эти переменные установлены, то сравнить с credentials в базе, и если не совпадают, то выдавать первым заголовком Header(«HTTP/1.0 401 Unauthorized»). Всё.
- AndreyCherezov: А патч можно сделать такой (добавить одну строку про REMOTE_USER):
  
  <? function GetUser() { if(isset($_ENV["REMOTE_USER"])) { return $this->LoadUser($_ENV["REMOTE_USER"]); } return $_SESSION[$this->config["cookie_prefix"]."user"];} ?>
AndreyCherezov: Если это попадет в следующий коммит на CVS, то установим на наш сайт, и смогу показать вам эту авторизацию в действии (в конфиг сервера добавляется одной строкой). До следующих апдейтов Byka User?, можно посмотреть в работе на этом урле: http://bitrix.eserv.ru/BitrixWacko/edit (запаролено только редактирование – Uri, оканчивающиеся на /edit).
- Ку Куц: я не очень понял, а пароль-то где и как проверяется?
- Ку Ме: я вот примерно понял, но не вижу в патче возможности отключить этот режим. А жаль. А пароли хранятся в хранилище паролей. А проверяются через вот такое окошко: http://sky.sharpdesign.ru/skyadmin
- AndreyCherezov: Да, пароли в случае REMOTE_USER проверяются сервером (если бы ткнули на ссылку на Bitrix Wacko?, то вопрос бы не возник ;). Kuso и Roman могут даже свои пароли там опробовать, т.к. регистрировались на нашей ваке. Что касается отключения патча – он самоотключаемый :) : если REMOTE_USER не проставлен (откуда он возьмется, если вы в сервере авторизацию не просили?), или там что-то левое (отсутствующее в базе ваки), то код безобидно пропускается.
  - Ку Куц: Я не очень понимаю. Пароли проверяются сервером? Так это тогда не HTTP-авторизация для /Wacko Wiki, а совсем даже просто поддержка чтения переменной REMOTE_USER. Уточните?
- Ку Ме: гош. а если я его разверну так, что у меня будет REMOTE_USER прописан, но использовать я его не захочу?
- AndreyCherezov: А мне вы не верите? :) Тогда попробуйте сами: если используется авторизация сервером по другой базе (не ваковой), то вака это не пропустит – все-равно выведет форму авторизации. Я пробовал. Согласен, код авторизации в ваке крайне кривой (наверное достался вам по наследству от wakka?), и полностью контролировать его сложно, вот и приходится гадать... ;) Ну, запишите в To Do Нп Ж? «факторизовать авторизацию», а сейчас просто вставьте мою строчку в Get User?, и убедитесь, что у вас от этого ничего не сломалось – при левом REMOTE_USER работает также, как при левом куке. А когда развернете «с прописанным REMOTE_USER» (жестко?) тогда появится стимул добавить опцию в конфиге :-)

Эвристика №1: Нужно хотя бы две разные инсталляции, которым это нужно.
AndreyCherezov: Мы сделали из вашей ваки стандартный модуль для SM/3 BitrixSiteManager. Соответственно можем гарантировать десятки инсталяций как минимум, если Битрикс включит ваку в комплект или как доступную опцию (предварительная договоренность уже есть; и лицензия ваша вроде бы этому не препятствует), и если вака пользователям SM/3 понравится. Не знаю, стоит ли из-за трех строк кода, которые я вам предложил, раздувать дискуссию на сотни строк ;) Конечно, это не killer-фича, и без неё можно обойтись. Но три строки – небольшая цена за дополнительную безопасность и красивую поюзерную статистику, imho.
/Ку Ме нашёл ещё одну инсталляцию и думает, что стоит быстро обсудить вид патча и включить его
/Roman Ivanov быстро обсуждаем.

kukutz_mukutz@hotmail.com	первое, самое простое. HTTPAuth. объясни (мы на ты или вы?), я правильно понимаю, что пароли в твоём патче проверяются сервером? Это не HTTP-авторизация для WackoWiki, а совсем даже просто поддержка чтения переменной REMOTE_USER?	05.06.2003 20:48:43
Andrey Cherezov	да (мы на ты), это просто самое простое решение, с которого я начал вас втягивать в эту бодягу с авторизацией :)	05.06.2003 20:50:38
kukutz_mukutz@hotmail.com	ок, а каково должно быть сложное?	05.06.2003 20:51:01
Andrey Cherezov	про PHP_AUTH вы сразу отнекиваться начали, что мол не у всех будет работать	05.06.2003 20:51:08
Andrey Cherezov	в идеале, конечно, PHP_AUTH нужно тоже поддержать в ваке – не все умеют сервер заставлять авторизовать юзеров	05.06.2003 20:51:46
Andrey Cherezov	я там в коде уже видел какие-то намёки про PHP_AUTH – может просто довести до конца	05.06.2003 20:52:08
kukutz_mukutz@hotmail.com	ок, если мы сделаем PHP_AUTH, это отменит нужду в REMOTE_USER или нет?	05.06.2003 20:52:35
Andrey Cherezov	для меня – отменит, за других не могу говорить	05.06.2003 20:53:12

Ку Ме: решит ли это проблему Хорошкова (у него сквозная авторизация в домене NT во внутренней сетке и он хочет проассоциировать пользователей по их DOMAIN\USER именам)?
RomanIvanov Если ты думаешь, что я знаю, что такое «сквозная авторизация в домене NT во внутренней сетке», то ты ошибаешься.
Ку Ме тоже не знает. Он думает, что это integrated NT authorization наверное.
AndreyCherezov: Если у Хорошкова IIS, то PHP_AUTH ему скорее всего не поможет, а REMOTE_USER наверняка поможет.
RomanIvanov нужны тесты, /me ждёт.
AndreyCherezov: От меня что-то ждет? Тогда подробнее ставьте вопрос, что требуется. При необходимости могу испытать у себя на сервере и NT-авторизацию, только не под IIS, а под acWEB, который из Eserv / 3?, там любую авторизацию можно прикрутить. А IIS вам Хорошков испытает, а на апаче (другие варианты) вы сможете сами испытать. И будет всем счастье.
не-не, я жду от Кусо и Хорошкова описание последовательности действий, которые я должен повторить чтобы создать на своём IIS ту же ситуацию, что у него.

AndreyCherezov /27.08.2003 08:52/ Да, очень хочется увидеть в R4 поддержку REMOTE_USER. У меня сейчас на www.eserv.ru доступ к /edit закрыт HTTP-авторизацией, и людям приходится дважды авторизоваться – первый раз в выскакивающем окошке браузера, потом (уже после того как веб-сервер успешно авторизовал юзера по базе ваки) те же самые имя/пароль вводить в форме ваки :( А вака могла бы уже готовенького юзера брать из REMOTE_USER, если он установлен.

WackoWiki: WackoIdeas/HTTPAuth ...