¿Está Twitter implementando OAuth fuera de especificaciones? (C#)

Question

He estado batallando con OAuth y Twitter durante 2 semanas para intentar implementarlo. Después de muchas reescrituras de mi código, finalmente obtuve una biblioteca que realiza la solicitud, ya que debe basarse en la especificación 1.0. Lo he verificado utilizando this verifier on Google Code y this verifier from Hueniverse.

Mi versión, la de Google y la versión Hueniverse, todas producen exactamente la misma firma, así que he llegado a la conclusión de que ya no soy la causa (pero podría ponerme un pie en la boca diciendo esto ...)

Probar mi implementación creando primero una solicitud de prueba utilizando la API Console de Twitter, en este caso una actualización de estado. Copio los parámetros que cambian, el oauth_nonce y el oauth_timestamp, en los tres firmantes indicados anteriormente. Todos los demás parámetros son siempre los mismos, tokens/secrets/etc.

La consola de Twitter produce una firma, pero las otras tres sobre todo producen una firma diferente (de Twitter, idéntica entre sí).

Por lo tanto, mi pregunta es, ¿por qué estoy haciendo esto:

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

... cuando debería estar implementando la especificación de la "T"?

¿Hay algo específico que Twitter necesita/desea como parte de la solicitud? He contado el tiempo generado por Twitter como 42 caracteres, ¿es correcto? ¿Debería tener 42 caracteres de largo?

le agradecería la ayuda de cualquier persona con una visión más clara de la API de lo que, obviamente, tengo ...

Gracias de antemano!

ACTUALIZACIÓN: Alguien preguntó acerca de cómo envío los parámetros de autenticación, pero desde entonces ha eliminado su publicación, no sé por qué. De todos modos, los parámetros de autorización se envían a través del encabezado Autorización.

ACTUALIZACIÓN/SOLUCIÓN:Se mueve hacia abajo hasta donde corresponde como respuesta.

Answer 1

Un poco tarde, pero por sugerencia de @ poke, estoy agregando mi respuesta aquí:

Así que, lo descubrí, y en realidad es bastante estúpido. Hace un tiempo, probablemente reescribí 3, estaba recibiendo una mala respuesta no XML de Twitter. Entonces vi que en la consola API de Twitter escapan del encabezado params: param=\"value\". Agregué la barra invertida a la mía y al instante recibí una respuesta XML. Entonces se estancó.

De todos modos, para descartar todo desde la reescritura 7 (u 8), decidí eliminar la barra invertida de la cadena params del encabezado y resolvió todo.

Por lo tanto, la lección aprendida de todo esto es que no todo lo que muestra la consola API de Twitter debe ser imitado. En realidad, sugeriría que Twitter actualice la consola para mostrar cómo debería verse una cadena de encabezado cuando se envía y no lo que su sistema genera internamente, lo que analiza los caracteres de barras diagonales inversas.

Answer 2

El único problema que tuve al implementar la especificación OAuth con Twitter como el objetivo principal fue que Twitter restringió el nonce para que solo aceptara caracteres ASCII (mientras que la especificación realmente permite bytes). Por lo tanto, cambié mi implementación para generar un int aleatorio (con 60 bits, más de 42 caracteres) en su lugar.

Aparte de eso, la implementación de Twitter parece ser completamente correcta; al menos no tuve ningún problema.

que sugerimos para utilizar algunas de las muchas cajas de arena alrededor de OAuth (por ejemplo this o this) para comprobar realmente si todo va bien y, por ejemplo si se incluye todo lo necesario en la firma etc ..