LINUX.ORG.RU
Форум — Development  

Apache mod_perl и получение имени авторизованного юзера в perl скрипте


1

1
Сделал сайт на основе обычных perl скриптов. Авторизацию проверял через использование mod_rewrite. Теперь решил перейти на mod_perl и есть желание отказаться от mod_rewrite. В связи с этим вопрос: Как штатными средствами mod_perl (т.е. модулями Apache::*) мне в скрипт получить имя http-авторизованного юзера?
← Потоки
Qt/Embedded и руские шрифты ... help может кто сталкивался →
Ответ на: комментарий от loki
Без спецаильного ее выставления через mod_rewrite? Так я делал как раз через него, а сейчас я хочу от него отказаться. Попробовал без mod_rewrite через mod_perl - такой переменной нет в окружении. :(
UncleAndy ★★★
() автор топика
Ответ на: комментарий от UncleAndy
На всякий случай.
Я проверяю просто выводя все переменные окружения:

#! /usr/bin/perl

print "Content-type: text/html\n\n";

print "<html><body>\n";
foreach $k (keys %ENV)
{
print $k.' = '.$ENV{$k}.'<br>';
};
print "</body></html>";
UncleAndy ★★★
() автор топика
Ответ на: комментарий от UncleAndy
Нда... Что-то мне подсказывает, что имя юзера я смогу получить только если стоит защита паролем именно на тот скрипт, который его должен получать. :( Хотя mod_rewrite позволяет получать его даже при единичной авторизации далее в любом скрипте, даже незащищенном. Возможно-ли все-таки повторить функциональность mod_rewrite через mod_perl? Они-ж вроде по возможностям должны быть одинаковыми? Т.е. принципиальных ограничений для mod_perl в этом смысле вроде-бы не должно быть?
UncleAndy ★★★
() автор топика
Ответ на: комментарий от UncleAndy
> Нда... Что-то мне подсказывает, что имя юзера я смогу получить только если стоит защита паролем именно на тот скрипт, который его должен получать. :(

http://hoohoo.ncsa.uiuc.edu/cgi/env.html

> Хотя mod_rewrite позволяет получать его даже при единичной авторизации далее в любом скрипте, даже незащищенном. Возможно-ли все-таки повторить функциональность mod_rewrite через mod_perl? Они-ж вроде по возможностям должны быть одинаковыми? Т.е. принципиальных ограничений для mod_perl в этом смысле вроде-бы не должно быть?

В своё время я отказался от использования авторизации на уровне сервера, реализовав свою, с помощью cookies. Проблема в том, что ни в rfc2616/2617, ни в CGI scpecs. не упоминается, что имя и пароль при авторизации должны быть доступны на уровне CGI. Единствоенное, что есть:

RFC 3050 CGI for SIP January 2001

The server MAY choose not to support this feature, and it is anticipated that not many implementations will, as the information is not particularly useful in the presence of complex proxy paths.

5.5.1.10 REMOTE_USER

If the message requested authentication (i.e., the AUTH_TYPE metavariable is set), then the value of the REMOTE_USER metavariable is set to the user-ID supplied for the authentication. For Basic authentication this is the content of the (decoded) "userid" grammar element; for Digest it is content of "username-value." For PGP authentication, it is the URI specified in the "signed-by" parameter of the Authorization header, if present, otherwise the URI part of the From header.

If some other authentication scheme was requested, this metavariable SHOULD be set to an appropriate component of the authorization information identifying the user or entity associated with the credentials. If authentication was not requested, this metavariable is not defined.

REMOTE_USER = *OCTET

Servers SHOULD provide this metavariable to scripts.

loki ★
()
Ответ на: комментарий от loki
loki, а не подскажешь урл на описание принципа построения авторизации на основе coockies? Вроде-бы для mod_perl даже готовый модуль есть типа Apache::AuthCookies для этого, но что это за авторизация я что-то не совсем понимаю.
UncleAndy ★★★
() автор топика
Ответ на: комментарий от UncleAndy
Вот урлов не искал - всё из головы. А идею навеял, видимо протокол CHAP (хотя там пароль НЕ передаётся).

Принцип такой:
Усер-агент передаёт два поля - имя и пароль.
Сервер проверяет, и в случае успеха генерит 2 печенья - один с дигестом юзерлогина, другой - сеанса. (второй должен быть уникальный) и отправляет клиенту.
Клиент сохраняет эти куки на всё время сеанса.
Сервер проверяет наличие и корректность куков, и либо пускает на ресурс, либо выталкивает на авторизацию.

+ы:
Куки взаимосвязаны, поэтому подделать такую пару очень сложно.
Вся авторизация доступна CGI и не привязывается к конкретному серверу.
-ы:
Нешифрованная передача имени/пароля (решается переходом на HTTPS).
От усер-агента требуется поддержка куков.

В моём случае CGI реализован на C++ (через либу cgicc), система работает уже второй год - пока не жаловались;)
loki ★
()
Ответ на: комментарий от loki
Спасибо! Этот вариант и реализовал через mod_perl. Вроде неплохо получилось. :)
UncleAndy ★★★
() автор топика
Вы не можете добавлять комментарии в эту тему. Тема перемещена в архив.
← Потоки
Development
Qt/Embedded и руские шрифты ... help может кто сталкивался →