Здравствуйте, donkombat, Вы писали: D>Хочу сделать соответствие GET запросу и html странице, которую получаю в ответ на этот запрос. Предполагаю, что если я сохраню FileObject при TDI_SEND (содержит GET запрос) то html страницу в ответ на этот GET я буду получать при TDI_RECEIVE с таким же FileObject. Это верно?
Правильней будет, как ранее говорил x64, реализовать полноценную HTTP-state машину, которая будет изначально вести учет создания/использования/уничтожения соответствующих FILE_OBJECT, как это, например, реализовано в том же самом tdi_fw. Для лучшей уверенности, я к примеру в таких случаях ставил дополнительную метку через вызов PsGetCurrentThread(), сохранял его и при вызове своего нотификатора ClientEventChainedReceive, но простого сравнения FILE_OBJECT обычно хватает.
Здравствуйте, Аноним, Вы писали:
А>Здравствуйте, donkombat, Вы писали: D>>Хочу сделать соответствие GET запросу и html странице, которую получаю в ответ на этот запрос. Предполагаю, что если я сохраню FileObject при TDI_SEND (содержит GET запрос) то html страницу в ответ на этот GET я буду получать при TDI_RECEIVE с таким же FileObject. Это верно?
А>Правильней будет, как ранее говорил x64, реализовать полноценную HTTP-state машину, которая будет изначально вести учет создания/использования/уничтожения соответствующих FILE_OBJECT, как это, например, реализовано в том же самом tdi_fw. Для лучшей уверенности, я к примеру в таких случаях ставил дополнительную метку через вызов PsGetCurrentThread(), сохранял его и при вызове своего нотификатора ClientEventChainedReceive, но простого сравнения FILE_OBJECT обычно хватает.
На практике не получаю нужного результата
Я анализирую GET запрос, и если это запрос к нехорошему сайту, то мне надо ОТЛОВИТЬ html, который приходит в ответ и его изменить. Вообщето это задача не TDI уровня: http://rsdn.ru/forum/asm/1950557.aspx
, но я хочу научится делать это именно в фильтре TDI. Для этого я упростил задачу: изменение html документа, будут самые простые: я сделаю свой шаблонный маленький html. Дальше, при получении страницы "плохого сайта" я буду вставлять вместо него свой html.
Моя проблема, в том, что я не могу соотнести GET запрос к сайту с ответом этого сайта. Я умею парсить GET запросы и зарегестировал ClientEventReceive и ClientEventChainedReceive, в TDI_SEND получаю GET запрос, а в ClientEventChainedReceive получаю html страницы, но как соотнести, как определить какому GET запросу соответствует вызов ClientEventChainedReceive?
Здравствуйте, x64, Вы писали:
D>>...как соотнести, как определить какому GET запросу соответствует вызов ClientEventChainedReceive?
x64>Там есть контексты TdiEventContext и ConnectionContext, этого более чем достаточно для идентификации соединения. Об этом есть у меня в блоге и в MSDN.
Сейчас попробую их использовать.
Еще появился вопрос: если я получаю GET запрос к плохому сайту, то можно ли сразу в TDI_SEND сделать ответ, создав собственный html с ошибкой 302, в Location указав уже свой валидный адрес, например x64.blog.ru? Смогу я так отредиректить юзера?
Здравствуйте, x64, Вы писали:
D>>...как соотнести, как определить какому GET запросу соответствует вызов ClientEventChainedReceive?
x64>Там есть контексты TdiEventContext и ConnectionContext, этого более чем достаточно для идентификации соединения. Об этом есть у меня в блоге и в MSDN.
Нетривиально надо разобраться.
Я предполагаю следующий алгоритм:
1)в TDI_SET_EVENT_HANDLER при регистрации ClientEventConnect, сохранить FileObject.
2)в TDI_SET_EVENT_HANDLER при регистрации ClientEventChainedReceive , сохранить FileObject.
3)в TDI_SEND при обращении к плохому сайту выставить в списке FileObject'у состояние "лезет на плохой сайт"
4)в ClientEventChainedReceive, взять сохраненный в 2) FileObject, и если он "лезет на плохой сайт" подменять html на свой.
В правильном направлении мыслю?
Здравствуйте, donkombat, Вы писали: D>В правильном направлении мыслю?
Нет, неверно!
ClientEventConnect генерируется при получении независимого *входящего соединения* на твою машину, а не исходящего. Поэтому считывать FILE_OBJECT нужно при перехвате TDI_CONNECT. При получении ClientEventChainedReceive тебе нужно сравнить сохраненный FILE_OBJECT и для более точной идентификации соединения — TdiEventContext и ConnectionContext, как сказал x64. Их нужно получить при TDI_CONNECT по соответствующему IP. Как вариант, при получении GET/ в TDI_SEND ты
должен проанализировать поле "Host: www.badsite.com" запомнить FILE_OBJECT и ConnectionContext, и при получении ClientEventChainedReceive сравнить FILE_OBJECT и т.д. с сохраненными из TDI_CONNECT (TDI_SEND). Если они совпали — то это "плохой" сайт и соотвественно подменять html-content. Кстати, не советую использовать для этого заранее подготовленную html-страничку, это ппц какой геморрой.
p.s. давай уже, колись, что подмену выдачи пишешь xD)))
p.p.s. будут вопросы — 202609269 для связи
Здравствуйте, Аноним, Вы писали:
А>p.s. давай уже, колись, что подмену выдачи пишешь xD))) А>p.p.s. будут вопросы — 202609269 для связи
готовлю дипломный проект на мехмат.
Здравствуйте, Аноним, Вы писали:
А>Поэтому считывать FILE_OBJECT нужно при перехвате TDI_CONNECT.
Это могу.
А>При получении ClientEventChainedReceive тебе нужно сравнить сохраненный FILE_OBJECT и для более точной идентификации А>соединения — TdiEventContext и ConnectionContext, как сказал x64. Их нужно получить при TDI_CONNECT по соответствующему IP.
это указатель param->RequestConnectionInformation->UserData; при TDI_CONNECT?
А>Как вариант, при получении GET/ в TDI_SEND ты А>должен проанализировать поле "Host: www.badsite.com" запомнить FILE_OBJECT и ConnectionContext,
Пытался найти ConnectionContext в TDI_SEND в указателях irps->FileObject->FsContext , irps->FileObject->FsContext2 , irps->FileObject->CompletionContext но не один из них не совпадает с ConnectionContext в ClientEventChainedReceive. Не там ищу или неправильно тетстирую?
А>и при получении ClientEventChainedReceive сравнить FILE_OBJECT и т.д. с сохраненными из TDI_CONNECT (TDI_SEND).
я получу этот FILE_OBJECT через ConnectionContext.
p.s зря вы не регистрируетесь, мои плюсики вам пропадают зря
А>>При получении ClientEventChainedReceive тебе нужно сравнить сохраненный FILE_OBJECT и для более точной идентификации А>соединения — TdiEventContext и ConnectionContext, как сказал x64. Их нужно получить при TDI_CONNECT по соответствующему IP. D>это указатель param->RequestConnectionInformation->UserData; при TDI_CONNECT?
Нет.
D>Пытался найти ConnectionContext в TDI_SEND в указателях irps->FileObject->FsContext , irps->FileObject->FsContext2 , irps->FileObject->CompletionContext но не один из них не совпадает с ConnectionContext в ClientEventChainedReceive. Не там ищу или неправильно тетстирую?
Об этом уже было у меня в блоге, конкретно здесь. В документации это тоже есть, просто ты её не читаешь.
D>...мои плюсики вам пропадают зря
Здравствуйте, x64, Вы писали:
x64>Я за него.
спасибо, за ответ!
x64>Об этом уже было у меня в блоге, конкретно здесь. В документации это тоже есть, просто ты её не читаешь.
У меня получилось сопоставить GET запрос в TDI_SEND ответу в ClientEventChainedReceive.
в браузере ввожу www.yandex.ru, получаю несколько вызовов ClientEventChainedReceive, первый из них содержит:
HTTP/1.1 200 OK..Server: nginx
..Date: Sun, 16 May 2010 15:47
:04 GMT..Content-Type: text/ht
ml; charset=UTF-8..Connection:
close..Cache-Control: no-cach
e,no-store,max-age=0,must-reva
lidate..Content-Length: 73530.
.Expires: Sun May 16 15:47:05
2010 GMT..Last-Modified: Sun M
ay 16 15:47:05 2010 GMT..Set-C
ookie: S=; path=/; expires=Thu
, 18-May-2000 15:47:04 GMT..Se
t-Cookie: S=; domain=.yandex.r
u; path=/; expires=Thu, 18-May
-2000 15:47:04 GMT..X-XRDS-Loc
ation: http://openid.yandex.ru
/server_xrds/.............
я планирую его изменить (пока не знаю точно как), а оставшиеся вызовы ClientEventChainedReceive отбросить. Предположение, что тогда я смогу отредиректить верно? Спасибо!
D>в браузере ввожу www.yandex.ru, получаю несколько вызовов ClientEventChainedReceive, первый из них содержит: D>HTTP/1.1 200 OK..Server: nginx D>..Date: Sun, 16 May 2010 15:47 D>:04 GMT..Content-Type: text/ht D>ml; charset=UTF-8..Connection: D> close..Cache-Control: no-cach D>e,no-store,max-age=0,must-reva D>lidate..Content-Length: 73530. D>.Expires: Sun May 16 15:47:05 D>2010 GMT..Last-Modified: Sun M D>ay 16 15:47:05 2010 GMT..Set-C D>ookie: S=; path=/; expires=Thu D>, 18-May-2000 15:47:04 GMT..Se D>t-Cookie: S=; domain=.yandex.r D>u; path=/; expires=Thu, 18-May D>-2000 15:47:04 GMT..X-XRDS-Loc D>ation: http://openid.yandex.ru D>/server_xrds/.............
Изменил в этом пакете yandex на center, а остальные вызовы ClientEventChainedReceive (для этого GET запроса) дальше не пропустил. В итоге не открывается ни yandex.ru, ни center.ru.
D>В результата получаю: The page cannot be displayed
Да ты замучал уже. Бери Wireshark и смотри, что происходит без твоего фильтра и с ним, и найди 10 отличий. Чтобы сэмулировать редиректы без фильтра, можно использовать аддоны к Firefox-у для Web-разработчиков, например, или другой аналогичный софт. Это просто как валенок, приучайся самостоятельно искать решение проблемы.
Смогу я так отредиректить юзера?
надо разобраться.