Твиттер реализует OAuth вне спецификации? (С #)

Question

Я боролся с OAuth и Twitter уже 2 недели, пытаясь это реализовать. После многих переписываний моего кода я наконец-то получил библиотеку, которая выполняет запрос в соответствии со спецификацией 1.0. Я подтвердил это, используя этот верификатор в Google Code и этот верификатор из Hueniverse .

Моя версия, версия Google и версия Hueniverse дают одинаковую подпись, поэтому я пришел к выводу, что я больше не причина (но я мог бы засунуть мне в рот, заявив об этом ...) .

Я тестирую свою реализацию, сначала создав тестовый запрос с помощью консоли API Twitter, в этом случае обновление статуса. Я копирую изменяемые параметры, oauth_nonce и oauth_timestamp, во всех трех подписавших, указанных выше. Все остальные параметры всегда одинаковы, токены / секреты / и т. Д.

Консоль Twitter выдает одну подпись, но остальные три выше всех производят другую подпись (из Twitter, идентичную друг другу).

Итак, мой вопрос: почему я получаю это:

<?xml version="1.0" encoding="UTF-8"?>
<hash>
    <request>/1/statuses/update.xml</request>
    <error>Could not authenticate with OAuth.</error>
</hash>

... когда я должен был реализовать спецификацию для "T"?

Есть ли что-то конкретное, что нужно / нужно Twitterу как часть запроса? Я посчитал одноразовый номер, сгенерированный Твиттером, как 42 символа, это правильно? Должно ли это быть 42 символа в длину?

Буду признателен за помощь любому, кто лучше разбирается в API, чем у меня ...

Заранее спасибо!

ОБНОВЛЕНИЕ: Кто-то спросил о том, как я отправляю параметры аутентификации, но с тех пор удалил их сообщение, уточните почему. В любом случае параметры авторизации отправляются через заголовок авторизации.

ОБНОВЛЕНИЕ / РЕШЕНИЕ: Перемещено вниз, где оно относится к ответу.

Answer 1

Единственная проблема, с которой я столкнулся при реализации спецификации OAuth с использованием Twitter в качестве основной цели, заключалась в том, что Twitter ограничил одноразовый прием только символами ASCII (в то время как спецификация фактически допускает любые байты).Поэтому я изменил свою реализацию, чтобы вместо нее генерировать случайное целое число (с 60 битами, то есть длиннее, чем 42 символа).

Кроме того, реализация Twitter кажется полностью правильной;по крайней мере, у меня не было никаких проблем.

Я предлагаю вам использовать некоторые из множества песочниц OAuth (например, this или this ), чтобы действительно проверитьесли все идет хорошо и, например, если вы включаете все необходимое в подпись и т.д ..

Answer 2

Немного поздно, но по предложению @ poke я добавляю свой ответ здесь:

Итак, я понял это, и это на самом деле довольно глупо. Некоторое время назад, вероятно, переписать 3, я получил плохой ответ не в формате XML из Twitter. Затем я увидел, что в консоли API Twitter они экранируют заголовок params: param=\"value\". Я добавил обратную косую черту к себе и сразу же получил ответ XML. Вот оно и застряло.

В любом случае, просто чтобы исключить все из перезаписи 7 (или 8), я решил удалить обратную косую черту из строки параметров заголовка, и это решило все.

Итак, урок, извлеченный из всего этого, заключается в том, что не все, что отображает консоль Twitter API, должно быть имитировано. На самом деле я бы также предложил, чтобы Twitter обновил консоль, чтобы отображать, как должна выглядеть строка заголовка при отправке, а не то, что их система генерирует внутри, что анализирует символы обратной косой черты.