Итак задача следующая: Надо написать фильтр для авторизации.
Как писать в целом понятно, но есть пара вопросов...

1. Как мне передать данные из ISAPI фильтра в ASP?

Допустим юзера я определил и авторизовал, при дальнейших хождениях этого клиента по моему сайту мне надо знать, что это именно тот авторизованный юзер... При автоизации я определил этого юзера и присвоил ему какой-то ID.
Если я этот ID запишу в pCtxt->AddResponseHeaders("auth:<ID>\r\n"); будет ли этот ID виден в моей ASP'шке и будет ли этот header дальше передаваться без дополнительных усилий с моей стороны, пока юзер ходит внутри моего сайта?
Пока эксперименты никчему не привели..

2. Если у меня в настройках IIS указано не пускать анонимных пользователей, то при каждом ли перемещении пользователя запрашивается Login/Password? Полагаю, что да...


Спасибо за помощь...

Здравствуйте Merle, вы писали:

M>Итак задача следующая: Надо написать фильтр для авторизации.
M>Как писать в целом понятно, но есть пара вопросов...

M>1. Как мне передать данные из ISAPI фильтра в ASP?

Ты уже вроде сам придумал — через заголовки (может быть еще получится через request string).

M>Допустим юзера я определил и авторизовал, при дальнейших хождениях этого клиента по моему сайту мне надо знать, что это именно тот авторизованный юзер... При автоизации я определил этого юзера и присвоил ему какой-то ID.
M>Если я этот ID запишу в pCtxt->AddResponseHeaders("auth:<ID>\r\n"); будет ли этот ID виден в моей ASP'шке и будет ли этот header дальше передаваться без дополнительных усилий с моей стороны, пока юзер ходит внутри моего сайта?

Нет. Браузер работает только со стандартными заголовками. Твой "auth" он обрабатывать не будет.

M>Пока эксперименты никчему не привели..

M>2. Если у меня в настройках IIS указано не пускать анонимных пользователей, то при каждом ли перемещении пользователя запрашивается Login/Password? Полагаю, что да...

Нет, сервер запрашивает авториацию один раз. Затем браузер при каждом запросе посылает ему подтверждение.

Здравствуйте Alex Ostapenko, вы писали:


AO>Ты уже вроде сам придумал — через заголовки (может быть еще получится через request string).
Да вот как-то не получается...
pCtxt->AddResponseHeaders("auth:<ID>\r\n"); А в ASP ничего не видно.. ;((


Фильтр работает по такому принципу: перехватывает OnAuthentication, сверяет логин/пароль юзера из базы и если тот подходит, то в структуре PHTTP_FILTER_AUTHENT меняет данные введенные юзером на данные реального пользователя. Но, если запросить request.servervariables("AUTH_USER") или ("REMOTE_USER"), то там по прежнему будет торчать логин который ввел пользователь.. Но это так, наблюдение..
Собственно это решает мою проблему по дальнейшему отслеживанию юзера, но все-таки хотелось бы что бы лишний раз не лазить в базу из фильтра как-нибудь передать в ASP UserID какой-нибудь... или вообще все данные по пользователю которые могут мне пригодиться...

Здравствуйте Merle, вы писали:

M>Здравствуйте Alex Ostapenko, вы писали:


AO>>Ты уже вроде сам придумал — через заголовки (может быть еще получится через request string).
M>Да вот как-то не получается...
pCtxt->>AddResponseHeaders("auth:<ID>\r\n"); А в ASP ничего не видно.. ;((

Логично, обратно то его никто присылать не будет.
Далее, смотря что тебе нужно:
1) Если у тебя фильтр будет при каждом запросе проверять авторизованность, то можно в ASP передавать
через заголовки, но не ответа, а запроса (повесившись на SF_NOTIFY_PREPROC_HEADERS или на SF_NOTIFY_AUTH_COMPLETE (только для 5-го IIS'а)).
2) Если тебе хочется, чтобы фильтр работал 1 раз, то тебе придется писать что-то в куки (других стандартных заголовков, которые бы гуляли в обе стороны я не знаю).

M>Фильтр работает по такому принципу: перехватывает OnAuthentication, сверяет логин/пароль юзера из базы и если тот подходит, то в структуре PHTTP_FILTER_AUTHENT меняет данные введенные юзером на данные реального пользователя. Но, если запросить request.servervariables("AUTH_USER") или ("REMOTE_USER"), то там по прежнему будет торчать логин который ввел пользователь.. Но это так, наблюдение..

Вероятно, оно берется из http-заголовка, который ты не трогаешь.

M>Собственно это решает мою проблему по дальнейшему отслеживанию юзера, но все-таки хотелось бы что бы лишний раз не лазить в базу из фильтра как-нибудь передать в ASP UserID какой-нибудь... или вообще все данные по пользователю которые могут мне пригодиться...

Вешайся на SF_NOTIFY_AUTH_COMPLETE и меняй заголоки запроса и/или URL (можешь дописывать в заголовки или querystring любые нужные тебе переменные).

Здравствуйте Alex Ostapenko, вы писали:

M>>Да вот как-то не получается...
pCtxt->>>AddResponseHeaders("auth:<ID>\r\n"); А в ASP ничего не видно.. ;((

AO>Логично, обратно то его никто присылать не будет.
Дык мне казалось, что фильтр перед ASP'шкой стоит... Покрайней мере событие SF_NOTIFY_AUTHENTICATION, судя по тому, что написано в MSDN'е "Event Notification Order" На эту тему..


AO>Вешайся на SF_NOTIFY_AUTH_COMPLETE и меняй заголоки запроса и/или URL (можешь дописывать в заголовки или querystring любые нужные тебе переменные).
А вот здесь я еще покопаюсь, спасибо.

Здравствуйте Merle, вы писали:

M>Здравствуйте Alex Ostapenko, вы писали:

M>>>Да вот как-то не получается...
pCtxt->>>>AddResponseHeaders("auth:<ID>\r\n"); А в ASP ничего не видно.. ;((

AO>>Логично, обратно то его никто присылать не будет.
M>Дык мне казалось, что фильтр перед ASP'шкой стоит... Покрайней мере событие SF_NOTIFY_AUTHENTICATION, судя по тому, что написано в MSDN'е "Event Notification Order" На эту тему..

Так и есть. Все события до SF_NOTIFY_SEND_RESPONSE идут до ASP. Но ты добавляешь Response (!) заголовок, а не Request. Он попадает не в ASP, а клиентскому браузеру.

Здравствуйте Alex Ostapenko, вы писали:

AO>Так и есть. Все события до SF_NOTIFY_SEND_RESPONSE идут до ASP. Но ты добавляешь Response (!) заголовок, а не Request.
Вот она, ключевая фраза!! Просто чуял, что подвох какой-то совсем элеменарный...

Все, теперь понятно где собака порылась.. ;) спасибо еще раз..

Здравствуйте Alex Ostapenko, вы писали:

AO>Так и есть. Все события до SF_NOTIFY_SEND_RESPONSE идут до ASP. Но ты добавляешь Response (!) заголовок, а не Request. Он попадает не в ASP, а клиентскому браузеру.
Нут теперь вроде все понятно, все даже как-то заработало ;))
Теперь возник такой вопрос: А как бы мне в этот фйильтр настройки передать?
Тоесть он будет у меня висеть на нескольких сайтах на одном сервере и работать будет чуть-чуть по разному... Соответственно мне надо как-то обьяснить ему это..
Мне кажется, что я где-то в MSDN'е на это дело натыкался, что-то там про реестр было, но вот где и что, убей бог — не помню..
Может кто подскажет?

Здравствуйте Merle, вы писали:

M>Здравствуйте Alex Ostapenko, вы писали:

M>Теперь возник такой вопрос: А как бы мне в этот фйильтр настройки передать?
M>Тоесть он будет у меня висеть на нескольких сайтах на одном сервере и работать будет чуть-чуть по разному... Соответственно мне надо как-то обьяснить ему это..
M>Мне кажется, что я где-то в MSDN'е на это дело натыкался, что-то там про реестр было, но вот где и что, убей бог — не помню..

Ничего стандартного мне тут не припоминается.

M>Может кто подскажет?

Сходу видятся 2 варианта:
1) конфигурационный файл;
2) ключи в реестре.
В обеих случаях привязка настройки идет по url сайта.

Здравствуйте Merle, вы писали:

M>Итак задача следующая: Надо написать фильтр для авторизации.
M>Как писать в целом понятно, но есть пара вопросов...

M>1. Как мне передать данные из ISAPI фильтра в ASP?

Сударь, Вам гемора мало?!
Зачем Вам ASP?!
Чего Вы в нем находите? IIS — MustDie, Apache — rules forever.
PHP гораздо удобнее, синтаксис лучше, и пр.,пр.,пр...

Как в IIS не знаю, но в Apache процесс интедификации прост до безумия
(такой) — есть файл .htaccess , в нем можно указать путь к файлу паролей,
и логины, которых пускать.
В какой директории этот файл лежит, для той и работает.

НО! Есть переменные (уж не помню, какие, посмотрите в SSI, http://uwg.h1.ru/comp/webdesign/ssi/),
которые будут определять имя юзера, его можно (и нужно) каджый раз проверять.

Но этот метод не надежен, т.к. пароль с логином сендятся при КАЖДОМ запросе (см.ниже),
т.ч. лучше коннектится к базе, запоминать
IP/некое случайное число/время входа , и подобного рода информацию.
Из другой таблицы при авторизации выбираешь лог/pwd, в первую табличку
вносишь данные, заоодно проверя, какие записи можно удалить.
Пароль так будет передаваться один раз. что надежнее.

M>Допустим юзера я определил и авторизовал, при дальнейших хождениях этого клиента по моему сайту мне надо знать, что это именно тот авторизованный юзер... При автоизации я определил этого юзера и присвоил ему какой-то ID.
M>Если я этот ID запишу в pCtxt->AddResponseHeaders("auth:<ID>\r\n"); будет ли этот ID виден в моей ASP'шке и будет ли этот header дальше передаваться без дополнительных усилий с моей стороны, пока юзер ходит внутри моего сайта?

Ничего просто так передаваться не будет.
Запомнить можно или через куку, или логами сервера.
Второе — описанно на Хак-зоне,
Первое — на http://uwg.h1.ru/comp/webdesign/

M>Пока эксперименты никчему не привели..

M>2. Если у меня в настройках IIS указано не пускать анонимных пользователей, то при каждом ли перемещении пользователя запрашивается Login/Password? Полагаю, что да...

Броузер и сервер взаимодействуют так:
броузер запрашивает пароль, если получает заголовок
"Authorization Require"...
Он просит юзера ввести пароль, и оптравляет его,
на что получает или облом, или суксес :)
Потом все будет также, только БРОУЗЕР ЗАПОМНИТ
пароль с логином и будет автоматом посылать введеные пользователем данные.



M>Спасибо за помощь...

Здравствуйте Аноним, вы писали:


А> Сударь, Вам гемора мало?!
А> Зачем Вам ASP?!
А> Чего Вы в нем находите? IIS — MustDie, Apache — rules forever.
А> PHP гораздо удобнее, синтаксис лучше, и пр.,пр.,пр...

Когда здесь появится форум IIS vs. Apache, я с удовольствием приведу Вам 275 аргументов в пользу IIS...


А> Как в IIS не знаю, но в Apache процесс интедификации прост до безумия
А> (такой) — есть файл .htaccess , в нем можно указать путь к файлу паролей,
А> и логины, которых пускать.
А> В какой директории этот файл лежит, для той и работает.
Ага... А если, как у меня, логины/пароли лежат в нарошной базе, да еще разделены в правах, уровнях доступа и пр. ?


А> НО! Есть переменные (уж не помню, какие, посмотрите в SSI, http://uwg.h1.ru/comp/webdesign/ssi/),
А> которые будут определять имя юзера, его можно (и нужно) каджый раз проверять.
Имя-то и в IIS есть, а мне нужно ID user'а из моей базы, причем каждый раз за этим лазить в оную базу не очень хочется...

Здравствуйте Аноним, вы писали:

А> Чего Вы в нем находите? IIS — MustDie, Apache — rules forever.

простой вопрос. как решить следующую проблему.
есть зарегистрированые в системе (Win NT) юзера.
я обращаю внимание, не в базе данных !
надо пускать и анонимных, и регистрированых.
для регистрированых — что-то дополнительное.
как решить задачу на апаче ?

я работал на разных серверах.
в системе Win NT нормально решается только через IIS.
если действительно есть решение для apache — с удовольствием выслушаю.

Олег

А> Сударь, Вам гемора мало?!
А> Зачем Вам ASP?!
Бывший фидошник? Жалобные крики суксь и рулез обычно только оттудова исходят...

А> Чего Вы в нем находите? IIS — MustDie, Apache — rules forever.
А> PHP гораздо удобнее, синтаксис лучше, и пр.,пр.,пр...
Скажите, а вы вообще имеете хоть отдаленное представление о том что такое ISAPI? Судя по тому, что предлагаете заменить его на Apache+PHP — нет. У IIS много конкурентов, но Apache не в их числе (пока).

А> Как в IIS не знаю, но в Apache процесс интедификации прост до безумия
[skip]
Вы просто не поняли вопроса.

Здравствуйте Alex Ostapenko, вы писали:

AO>Сходу видятся 2 варианта:
AO>1) конфигурационный файл;
AO>2) ключи в реестре.
AO>В обеих случаях привязка настройки идет по url сайта.

Сейчас я пишу подобный фильтр. Собственно он уже написан, но тоже возникла необходимость конфигурирования.
В связи с этим возникла идея внести изменения в архитектуру фильтра: создать COM-объект, который будет реализовывать всю функциональность (сличать логин/пароль с данными из БД, возвращать имя NT-го аккаунта для соответствующей роли пользователя, кэшировать данные и т.п.), а сам фильтр будет только обращаться к запущенному экземпляру объекта (или создавать новый, если нету запущенного) и использовать эту функциональность. Понятно, что можно и другим приложениям предоставить возможность управления этим объектом — например можно чистить кэш или менять какие-то настройки налету. Тогда можно и настройки не читать каждый раз из реестра или конфигурационного файла, а сделать это только один раз, а потом держать в памяти. При изменении же каких-то настроек можно эти изменения передавать объекту,как я уже говорил, налету.
Как вам такая схема?
С уважением, Виталий.

Здравствуйте Merle, Вы писали:

M>Итак задача следующая: Надо написать фильтр для авторизации.
M>Как писать в целом понятно, но есть пара вопросов...

M>1. Как мне передать данные из ISAPI фильтра в ASP?

M>Допустим юзера я определил и авторизовал, при дальнейших хождениях этого клиента по моему сайту мне надо знать, что это именно тот авторизованный юзер... При автоизации я определил этого юзера и присвоил ему какой-то ID.
M>Если я этот ID запишу в pCtxt->AddResponseHeaders("auth:<ID>\r\n"); будет ли этот ID виден в моей ASP'шке и будет ли этот header дальше передаваться без дополнительных усилий с моей стороны, пока юзер ходит внутри моего сайта?
M>Пока эксперименты никчему не привели..

У меня была такакя же проблема, как записать из ISAPI фильтра в ASP Session что — нибудь, но потом нашёл в MSDN (ID: Q246176 ), что напрямую это сделать невозможно, и, как один из вариантов советуют пользоваться куками.
Если у Вас это всё-же получилось, поделитесь пожалуйста, как.

Здравствуйте ild014, Вы писали:

I>Если у Вас это всё-же получилось, поделитесь пожалуйста, как.
Получилось... в Фильтре обрабатывается событие OnAuthComplite(CHttpFilterContext *pCtxt, PHTTP_FILTER_AUTH_COMPLETE_INFO pAuth), в котором добавляется переменная:
pAuth->AddHeader(pCtxt->m_pFC,"<имя переменной>:","<значение>");

Потом эта переменная подбирается в .asp'шке через Request.ServerVariables("<имя переменной>");

Обработчик вызывается при каждом запросе, данные из базы берутся только один раз, потом кладутся в локальный кэш фильтра и берутся оттуда...

Здравствуйте Yakovlev Vitaly, Вы писали:

YV>Как вам такая схема?
Получилось что-нибудь?

Здравствуйте Alex Ostapenko, Вы писали:

M>>2. Если у меня в настройках IIS указано не пускать анонимных пользователей, то при каждом ли перемещении пользователя запрашивается Login/Password? Полагаю, что да...

AO>Нет, сервер запрашивает авториацию один раз. Затем браузер при каждом запросе посылает ему подтверждение.

Не всегда. Во первых, есть область видимости для аутентификации, а во-вторых, автоматическая посылка credentials в пределах области видимости — дело добровольное и стандартом (RFC 2616) не навязываемое...

Здравствуйте FM, Вы писали:

FM>Здравствуйте Alex Ostapenko, Вы писали:

M>>>2. Если у меня в настройках IIS указано не пускать анонимных пользователей, то при каждом ли перемещении пользователя запрашивается Login/Password? Полагаю, что да...

AO>>Нет, сервер запрашивает авториацию один раз. Затем браузер при каждом запросе посылает ему подтверждение.

FM>Не всегда. Во первых, есть область видимости для аутентификации, а во-вторых, автоматическая посылка credentials в пределах области видимости — дело добровольное и стандартом (RFC 2616) не навязываемое...

Ну, в общем ты прав. Только не посылать креденшиалы каждый раз браузер может, по идее, только при работе по http/1.1 с keep-alive.

Здравствуйте Lexey, Вы писали:

AO>>>Нет, сервер запрашивает авториацию один раз. Затем браузер при каждом запросе посылает ему подтверждение.

FM>>Не всегда. Во первых, есть область видимости для аутентификации, а во-вторых, автоматическая посылка credentials в пределах области видимости — дело добровольное и стандартом (RFC 2616) не навязываемое...

L>Ну, в общем ты прав. Только не посылать креденшиалы каждый раз браузер может, по идее, только при работе по http/1.1 с keep-alive.

Если без идей, то он вообще не обязан посылать... Это просто удобная услуга броузера. RFC про это говорит конкретно: MAY. Это совсем не MUST и даже не SHOULD. :-)