Yes, sort of. I blew two days debugging my code accessing Twitter.
We had intermittent failures. It would work for hours, and then fail for hours. Eventually I noticed that we were calling http://api.twitter.com instead of https://api.twitter.com. Once we changed that it worked fine. On Aug 9, 2012, at 1:47 PM, William Mills wrote: > Mostly it's around making sure you get the signature base string constructed > right in my experience. > > From: Dick Hardt <[email protected]> > To: William Mills <[email protected]> > Cc: Dick Hardt <[email protected]>; "[email protected]" <[email protected]> > Sent: Thursday, August 9, 2012 12:48 PM > Subject: Re: [OAUTH-WG] mistake in draft-ietf-oauth-v2-http-mac-01 > > As an implementer, I have an app that accesses 10 different resources. Some > are OAuth 1.0A, some are a variant of OAuth 2. All have a slightly different > code path since each resource is its own beautiful snowflake. I did not use > any libraries for OAuth 2. Supporting MAC would give me yet another library > to integrate with. > > I'd be interested in what signing problems OAuth 1.0A has. I have my own list > of how writing to OAuth 1.0A is hard. > > On Aug 9, 2012, at 10:53 AM, William Mills wrote: > >> MAC fixes the signing problems encountered in OAuth 1.0a, yes there are >> libraries out there for OAuth 1.0a. MAC fits in to the OAuth 2 auth model >> and will provide for a single codepath for sites that want to use both >> Bearer and MAC. >> >> From: Dick Hardt <[email protected]> >> To: William Mills <[email protected]> >> Cc: "[email protected]" <[email protected]> >> Sent: Thursday, August 9, 2012 10:27 Aa >> Subject: Re: [OAUTH-WG] mistake in draft-ietf-oauth-v2-http-mac-01 >> >> >> On Aug 9, 2012, at 9:52 AM, William Mills wrote: >> >>> I find the idea of starting from scratch frustrating. MAC solves a set of >>> specific problems and has a well defined use case. It's symmetric key >>> based which doesn't work for some folks, and the question is do we try to >>> develop something that supports both PK and SK, or finish the SK use case >>> and then work on a PK based draft. >>> >>> I think it's better to leave them separate and finish out MAC which is >>> *VERY CLOSE* to being done. >> >> Who is interested in MAC? People can use OAuth 1.0 if they prefer that >> model. >> >> For my projects, I prefer the flexibility of a signed or encrypted JWT if I >> need holder of key. >> >> Just my $.02 >> >> -- Dick >> >> >> > > >
_______________________________________________ OAuth mailing list [email protected] https://www.ietf.org/mailman/listinfo/oauth
