The OpenNET Project / Index page

[ новости/++ | форум | wiki | теги ]

http authorization выдачей 401 из CGI-скрипта (perl cgi auth web access http mod_rewrite)


<< Предыдущая ИНДЕКС Поиск в статьях src Установить закладку Перейти на закладку Следующая >>
Ключевые слова: perl, cgi, auth, web, access, http, mod_rewrite,  (найти похожие документы)
Date: Wed, 24 Jul 2002 20:24:37 +0600 From: Andrey Sapozhnikov <sapa@icb.chel.su> Newsgroups: fido7.ru.perl Subject: http authorization выдачей 401 из CGI-скрипта > Хм. А как делается http authorization выдачей 401 из скрипта? --------------------- 401.cgi --------------------- #!/usr/bin/perl -w use strict; print "Status: 401\r\n", "WWW-Authenticate: Basic realm=\"test\"\r\n", "Content-type: text/plain\r\n\r\n", "Authorization required!\r\n"; ---------------------- eof ------------------------ P.S. Данный скрипт имеет исключительно демонстрационную цель и никоим образом не является призывом писать CGI скрипты без использования библиотеки CGI. В реальной работе используйте, если не имеете веских оснований делать по-другому: #!/usr/bin/perl -w use strict; use CGI; my $q = CGI->new; print $q->header(-status => 401, -www_authenticate => 'Basic realm="test"', -type => 'text/html'), $q->start_html('Authorization required'), $q->h2('Authorization required'), $q->end_html; P.P.S. Выдать ответ 401 еще не все. Hадо как-то получить от браузера имя и пароль пользователя. Тут все зависит от веб-сервера, но апач, к примеру, эти поля вам не передаст. Выручить может mod_rewrite. ------------------ .htaccess ------------------- <Files "401.cgi"> RewriteEngine On RewriteRule .* - [E=REMOTE_USER:%{HTTP:Authorization},L] </Files> --------------------- eof ---------------------- обеспечит передачу поля Authorization в переменной окружения REMOTE_USER. Можете выбрать другую, но имейте в виду, что CGI скрипты могут запускаться через suexec который содержит жестко заданный список переменных окружения разрешенных к передаче в скрипт. Содержимое этой переменной (например 'Basic bmFtZTpwYXNz') придется разобрать самостоятельно. В общем ничего сложного. Метод авторизации, пробел, и строчка имя:пароль завернутая при помощи base64.
From: Victor Wagner <vitus@communiware.ru> >> MAI> WWW-Authenticate: Basic realm="MuRealm" >> MAI> HTTP/1.0 401 Unauthorized ..... MAI> Я предполагал, что алгоритм такой. MAI> - клиент лезет на скрипт MAI> - действие, которое он хочет сделать, требует авторизации MAI> - генерится ошибка 401, которая вынуждает клиент показать окно ввода пароля MAI> - если пользователь нажал "отмена" он увидит текст, который идёт за хидером MAI> с 401-й ошибкой MAI> - если логин/пароль введён - передаётся в заголовке ответа клиента MAI> - логин/пароль проверяется по данным СУБД мускл. Такая схема прекрасно работала в Communiware на протяжении 3-х лет, пока не пришел в компанию Артем Чуприна и не переделал все нафиг на куках (стало работать еще прекраснее). Hо! Тонкость заключается в том, что Communiware это не сgi-скрипт, а набор mod_perl-овых модулей. Поэтому у меня была возможность залезть в заголовок Authorization и достать аттуда пароль, дабы проверить его самому. CGI-скрипту Apache пароля не отдаст. Поэтому авторизацию надо проводить либо средствами апача, либо посредством собственного модуля (например перлового, черед mod_perl) встроенного в апач. Потому что апач и стандартные авторизационные модули типа mod_auth_mysql, не будут проверять авторизацию для URL, про которую в конфиге апача не написано AuthType basic. Есть такой метод обхода этой проблемы (и я им активно пользовался еще году в 1997): увидев, что необходима авторизация, скрипт выдает РЕДИРЕКТ на $cgi->url(-query_string=>0) . "/secure" В конфиге апача написано <Location /cgi-bin/myscript/secure> AuthType basic и все что касается того по чему проверять пароли В начале работы скрипт смотрит на path_info, и если там /secure, то убеждается в наличии $ENV{'REMOTE_USER'}. После чего уже сам скрипт может решать, заслуживает ли данный юзер 200 или 403.
From: Victor Wagner <vitus@45.free.net> >> Hо! Тонкость заключается в том, что Communiware это не сgi-скрипт, а >> набор mod_perl-овых модулей. Поэтому у меня была возможность залезть >> в заголовок Authorization и достать аттуда пароль, дабы проверить его >> самому. CGI-скрипту Apache пароля не отдаст. AVG> но если его (apache) прислонить спиной к теплой стенке, то с ним еще можно AVG> много о чем поговорить (с) А.Райкин AVG> RewriteEngine on AVG> RewriteCond %{HTTP:Authorization} ^(.*) AVG> RewriteRule ^(.*) - [E=HTTP_AUTHORIZATION:%1] Теперь открываем глаза и смотрим, почему разработчики Apache сами этого не сделали. Ведь им, беднягам, пришлось писать специальный код, который ВЫКИДЫВАЕТ этот заголовок из числа помещаемых в environment. Читаем документацию по используемой операционной системе на тему о том, как узнать Environment неродственного процесса, работающего под тем же uid, и задумываемся о том, а всем ли авторам CGI-скриптов на данном сервере, выполняющимся под тем же uid, мы можем доверять.

<< Предыдущая ИНДЕКС Поиск в статьях src Установить закладку Перейти на закладку Следующая >>



Ваш комментарий
Имя:         
E-Mail:      
Заголовок:
Текст:





  Закладки на сайте
  Проследить за страницей
Created 1996-2017 by Maxim Chirkov  
ДобавитьРекламаВебмастеруГИД  
Hosting by Ihor