Signature problems

[Tim Armes]

Hi,

I'm trying to make an authorised request to /users/@self.json, however
typepad complains that the signature did not match, When I compare
the expected base string (as returned by TypePad) and the one that I
create there are two differences.

1) I use '&' to separate the method, url and parameters (as defined
here: http://tools.ietf.org/html/rfc5849#section-3.4.1.1), whereas
Typepad is expecting &

2) My encoded URL looks like this:

https%3A%2F%2Fapi.typepad.com%2Fusers%2F%40self.json

Whereas Type is expecting this:

https%3A%2F%2Fapi.typepad.com%2Fusers
%2F6p014e8be6c69a970d.json

Looks to me as if self is being replaced by a memory address!!

So, my base string is identical except for the beginning. I generate:

GET&https%3A%2F%2Fapi.typepad.com%2Fusers%2F
%40self.json&oauth_consumer_key...

whereas TypePad expects

GET&https%3A%2F%2Fapi.typepad.com%2Fusers
%2F6p014e8be6c69a970d.json&oauth_consumer_key...

Are these known problems?

(Note that I recreated my base string using http://hueniverse.com/oauth/guide/authentication/
to ensure that I'm doing the right thing too.

Tim

[Martin Atkins]

On 09/30/2011 03:01 AM, Tim Armes wrote:
> Hi,
>
> I'm trying to make an authorised request to /users/@self.json, however
> typepad complains that the signature did not match, When I compare
> the expected base string (as returned by TypePad) and the one that I
> create there are two differences.
>
> 1) I use '&' to separate the method, url and parameters (as defined
> here: http://tools.ietf.org/html/rfc5849#section-3.4.1.1), whereas
> Typepad is expecting&
>
> 2) My encoded URL looks like this:
>
> https%3A%2F%2Fapi.typepad.com%2Fusers%2F%40self.json
>
> Whereas Type is expecting this:
>
> https%3A%2F%2Fapi.typepad.com%2Fusers
> %2F6p014e8be6c69a970d.json
>
> Looks to me as if self is being replaced by a memory address!!
>

Tim,

What's going on here is that the API is issuing an HTTP redirect from
/users/@self to the canonical form of that URL with your opaque user id.
That's what the "6p014e8be6c69a970d" part is.

So I'd bet that your HTTP client library is following the redirect
automatically but isn't regenerating the OAuth signature for the second
request.

For most HTTP libraries you can work around this by simply disabling
automatic redirect following altogether. The TypePad API will include
the requested user object as the body of the redirect, so you don't
really need to do that second request at all if the response has the 302
status code.

Let me know if this does the trick!

Thanks,
Martin

--
Martin Atkins - SAY Media Platform Tech Lead

[Tim Armes]

Thanks Martin,

I don't have that sort of control over the HTTP library unfortunately.

However, I have managed to work around the issue by getting the user's
urlid via /request-properties.json, and then issuing the canonical
form of the url to /users/.

Tim

On Sep 30, 4:22 pm, Martin Atkins <matk...@saymedia.com> wrote:
> On 09/30/2011 03:01 AM, Tim Armes wrote:
>
>
>
>
>
> > Hi,
>

> > I'm trying to make an authorised request to /use...@self.json, however