TMG SF_NOTIFY_POLICY_CHECK_COMPLETED Событие - PullRequest
0 голосов
/ 10 января 2011

Согласно http://msdn.microsoft.com/en-us/library/ff823993%28v=VS.85%29.aspx, во время этого события веб-фильтр может запросить GUID соответствующего правила. Я предполагаю, что это делается путем выполнения GetServerVariable с типом SELECTED_RULE_GUID, так как я не мог найти других легко идентифицируемых средств для этого.

Моя проблема связана с тем, что я хочу посмотреть, разрешает ли правило или блокирует запрос. Если он заблокирован, то мой фильтр не должен предпринимать никаких действий, но если это разрешено, мне нужно выполнить некоторую работу. SF_NOTIFY_POLICY_CHECK_COMPLETED, кажется, является лучшим событием для просмотра, так как оно происходит в последний раз, когда аутентификация и различный трафик ms_auth были обработаны, но непосредственно перед тем, как запрос будет перенаправлен или получен из кэша.

Я подумал, что, возможно, мне нужно использовать интерфейсы COM и IFPC (следуя примеру кода для регистрации веб-фильтров в TMG), чтобы получить подробную информацию о правиле. Однако при переходе через FPC -> FPCArray -> FPCArrayPolicy -> FPCPolicyRules единственная функция, возвращающая элемент, принимает либо индекс, либо имя.

Что проблематично, учитывая, что у меня есть только GUID.

Объект FPCPolicyRule (в единственном числе), по-видимому, также не имеет никакого поля, связанного с GUID, что исключает просто итерацию по коллекции для него.

Таким образом, мой вопрос сводится к тому, из события SF_NOTIFY_POLICY_CHECK_COMPLETED, как веб-фильтр определит, был ли запрос разрешен или отклонен?

1 Ответ

0 голосов
/ 12 января 2011

После дополнительных исследований и тестирования GUID доступен через PersistentName объекта FPCPolicyRule.Поскольку элемент FPCPolicyRules-> Item работает только с именем или индексом, мне пришлось перебирать его элементы, сравнивая каждое имя PersistentName с GUID.

Извинения, если это было очевидно, заняли у меня хороший день, чтобы потренироваться :)

...