Здравствуйте George_Seryakov, Вы писали:
GS>Здравствуйте Slov, Вы писали:
S>>Вот это интересный вопрос. Например ОЕ поддерживает аутентификацию по NNTP, но в RFC про это ничего не написано. Кто знает как оно реализовано?
GS>AUTHINFO, поди. rfc 2980. Я в состоянии оттрассировать NNTP, но до аутентификации еще не дошел.
В двух словах расскажи, а то влом лезть.
S>>2. Клиент просто помнит сессионные (ASP-шные) кукисы, а вся работа реализуется на базе ASP-шных сессий. Логон происходит один раз вначале работы клиента с сервером. У этого способа есть плюсы и минусы. Минус — привязка к ASP технологии (это если кто захочет продавать/распространять эту штуку потом :-) )
GS> Т.е при каждом запросе на сервер он будет спрашивать куку? Тоже можно, но надо мне обхяснить, как с куками работать.
Я подумал. Лучше вариант №2.
Никто никого не спрашивает. Попробуй оттрасировать HTTP при _первом_ обращении к ASP. Когда ты подключишься первый раз ты получишь куку. Ее нужно запомнить и передавать потом при каждом запросе на сервер. Если получаешь новую куку — запоминаешь ее и т.д. Кука — это просто HTTP заголовок Cookie, Set-Cookie и т.д. Номер RFC не помню, но не тот где HTTP.
Какой статус сообщает NNTP клиенту что нужен пароль?
А>>> Еще вопрос. А таки нам надо WinInet? Вроде XMLHTTP все, что надо обеспечивает. Или там какие-то невидимые миру слезы будут? S>>Лучше WinInet, так ты облегчишь клиента минимум на 600кб.
GS> Если мы доклеиваем к каждому NNTP сообщению сессионную информацию (логон, текушая группа, мессадж), то надо бы XML. Или нет?
Если по варианту 2, то не надо.
S>>msgid генерится на клиенте и запоминается в нашей БД. Соотв поле в БД нужно будет добавить (и сгенерировать msgid для уже существующих сообщений). А еще не забыть генерацию этих msgid при отправке через веб :-)
GS> Пока есть только чтение, можно считать, что msgid == номер.
const="(Some GUID)@rsdn.ru";
msgid=номер+const;
Здравствуйте George_Seryakov, Вы писали:
GS> Но как все-таки мерзко выглядит программирование XML-я на голых плюсах. Да и на ВБ не лучше.
Короче, покажи свою проксю.
S>>Сейчас нумерация _сквозная_. Т.е. в каждой группе номерной ряд имеет разрывы. Это потому что мы вообще собирались отказаться от групп и ввести фильтры. Вот тебе еще одна проблема — NNTP клиент предполагает неразрывную нумерацию.
GS> Вот не нашел в стандарте такого, более того — должна же быть предусмотрена возможность для отработки cancel. Можно будет легко проверить — как OE реагирует на разрывы в последовательности.
Ну, будем надеяться :-)
S>>Сообщения посылаются через HTTP POST в том формате, как они идут от клиента (т.е. NNTP). S>>2Игорь: Читать CDO for W2K, а в особенности IMessage.GetStream, ADODB.Stream. S>>Схема такая: S>>Клиент постит сообщение как обычно (NNTP), на сервер оно попадает обернутое в HTTP POST, оттуда в CDO.GetStream->Flush, дальше методами CDO разбирается и пихается в базу. S>>При отдаче клиенту наоборот — CDO формирует сообщение, затем CDO.GetStream и в Response.BinaryWrite. S>>Зачем так сложно? А ты хочешь разбираться с разными кодировками, MIME, UUEncode, base64 и т.п вручную?
А>>> Что я должен послать по xmlhttp.Send xmldoc, чтоб статья запостилась? S>>Сообщение в NNTP.
GS> Аутентификация? Текущая группа,номер?
S>>А теперь самое веселое. Что будем делать, когда юзеры захотят постить месаги в HTML формате, присылать аттачменты, прилеплять картинки и т.п? :wow:
GS>А ЮЮки на что?
А причем тут к перечисленному UUE? Это ж не фидо.
Не, теоретически все это тоже реализуемо, но практически ... нафик.
GS>>Не проблема. Т.е. предлагается такое решение: 1) никакого разбора на клиенте, 1.1) Никого слоя преобразования, 2) паковка NNTP в HTTP, 3) весь разбор и реализация логики NNTP на сервере. Пункт 3 я сделать не смогу, вы его беретесь сделать?
S>Нужно будет поставить эксперимент. Если CDO for W2K удачно разберет месагу для NNTP (она чем-то от обычной почтовой отличается?), то на сервере это будет легче делать. А вот если нет, то ой...
ОК. Убираю XMLHTTP, пихаю WinInet. Еще там куки обработать...
GS>>В таком разе XML мне без надобности, надо канализировать NNTP голым WinInet-ом, принимается. S>Угу.
GS>>А как мне в серверном скрипте посмотреть переданные данные? Если я POST-ом все NNTP-шные команды шлю? без никакой обертки? S>Request.Form
Убедил. А мне постом вам данные слать?
S>И поставь себе Visual InterDev или VS.NET, если хочешь ASP отлаживать.
Дык стоит. Я даже умею ASP отлажывать, точнее, умел, сейчас лениво систему настраивать. Как посмотреть элементы формы — знаю.
Здравствуйте Slov, Вы писали:
GS>>AUTHINFO, поди. rfc 2980. Я в состоянии оттрассировать NNTP, но до аутентификации еще не дошел. S>В двух словах расскажи, а то влом лезть.
Там много чего написано, но OE делает так:
-> AUTHINFO USER username
<- 381 Authoriszation required -> AUTHINFO PASS password
<- 281 Authoriszation accepted
Когда пароль не нужен, отвечает сразу кодом 281, до пароля. Если неверный — 502. Есть еще PAP запрос, но я не смотрел, как там.
S>Никто никого не спрашивает. Попробуй оттрасировать HTTP при _первом_ обращении к ASP. Когда ты подключишься первый раз ты получишь куку. Ее нужно запомнить и передавать потом при каждом запросе на сервер. Если получаешь новую куку — запоминаешь ее и т.д. Кука — это просто HTTP заголовок Cookie, Set-Cookie и т.д. Номер RFC не помню, но не тот где HTTP.
Пошел читать RTFM. Это что, мне текст слов вручную парсить в поисках куки?
S>Какой статус сообщает NNTP клиенту что нужен пароль?
По идее это в ОЭ должно выставляться. Протоко предусматривает напоминание, но ОЭ его, скорее всего, не обрабатывает.
Здравствуйте Slov, Вы писали:
S>Нужно будет поставить эксперимент. Если CDO for W2K удачно разберет месагу для NNTP (она чем-то от обычной почтовой отличается?),
Вроде, не очень. В принципе, юзнетная мессага может быть послана по обчной почте.
Поле group там в заголовке должно нас волновать. Может быть, references. Всякие dictribution, approval, followup-to — игнорировать.
Здравствуйте George_Seryakov, Вы писали:
GS> Там много чего написано, но OE делает так:
->> AUTHINFO USER username GS><- 381 Authoriszation required ->> AUTHINFO PASS password GS><- 281 Authoriszation accepted
GS> Когда пароль не нужен, отвечает сразу кодом 281, до пароля. Если неверный — 502. Есть еще PAP запрос, но я не смотрел, как там.
Короче, можешь привести пример общения ОЕ с сервером включая авторизацию? Лучше если пример будет с вариантами и т.п. Да, и в своей проксе убери КОМ и сделай как я говорил — все запросы от ОЕ передаешь через HTTP POST в исходном виде, ответ получаешь прямо документом Content-Type: text/plain короче тупая прокся (но не забудь про сессионную куку).
Здравствуйте Slov, Вы писали:
S>Короче, можешь привести пример общения ОЕ с сервером включая авторизацию? Лучше если пример будет с вариантами и т.п.
Сейчас — нет. Это проблема написания тупого ответчика, будет решена при отладке прокси. Посколько прокси мы переписываем на WinInet, которого я не знаю, все это затягивается.
S>Да, и в своей проксе убери КОМ и сделай как я говорил — все запросы от ОЕ передаешь через HTTP POST в исходном виде, ответ получаешь прямо документом Content-Type: text/plain короче тупая прокся (но не забудь про сессионную куку).
Читаю WinInet, ждите. Либо пришлите работающий кусок кода с примером использования WinInet нужным мне способом. А то все эти хендлы, флаги и контексты в глазах так и рябят. А тут еще тикет и каминное стекло разбилось...
Здравствуйте George_Seryakov, Вы писали:
GS>Читаю WinInet, ждите. Либо пришлите работающий кусок кода с примером использования WinInet нужным мне способом. А то все эти хендлы, флаги и контексты в глазах так и рябят. А тут еще тикет и каминное стекло разбилось... http://www.rsdn.ru/article/?inet/wininet.xml
Здравствуйте Slov, Вы писали:
S>Здравствуйте George_Seryakov, Вы писали:
GS>>Читаю WinInet, ждите. Либо пришлите работающий кусок кода с примером использования WinInet нужным мне способом. А то все эти хендлы, флаги и контексты в глазах так и рябят. А тут еще тикет и каминное стекло разбилось... S>http://www.rsdn.ru/article/?inet/wininet.xml
Подойдет. А вот еще есть у меня такое подозрение, что XMLHTTP перекрывает wininet для большинства неизвратных случаев.
S>Там как раз и класс неплохой имеется
Класс правильный. (Правильный класс при создании должен делать почти большую часть (в идеале — всю) работу.)
