You have to keep track which flow is used with each Request Token either way!
The authorization endpoint doesn't include the oauth_version parameter. How
else would you know what to show the user and how to redirect it back? Are you
simply going to assume clients will not break when you send th
> -Original Message-
> From: oauth@googlegroups.com [mailto:oa...@googlegroups.com] On Behalf
> Of Blaine Cook
> Sent: Saturday, May 02, 2009 5:12 AM
> Given that a service provider can reject any request that has a
> referrer set (because desktop mobile apps *must* be, by definition,
> r
On May 2, 10:01 am, Joseph Smarr wrote:
> Erna-just getting to a detailed review of the diff now. Generally it looks
> good but here are a couple of things I think we should change:
>
> 1) If no oauth_token is provided on the authorization URL in 6.2.1 (e.g. the
> mobile/device case where the C
We seem to be spending a lot of time on the question of how providers
supporting both flows can tell which flow is being used. If they simply offer a
new set of 3 endpoints: request token, authorize, and access token, this entire
problem goes away. It also removed the need to make the oauth_cal
Hey guys,
as an alternative to Netflix's RI, I have written a new OAuth
implementation for Java that takes a different approach, and is more
flexible when doing HTTP via Apache's HttpComponents.
http://code.google.com/p/oauth-signpost/
Thoughts, feedback and contributions welcome!
Cheers,
Matt
On 4/30/09 7:34 AM, Blaine Cook wrote:
> A question for the security folks here:
>
> Is there a way to programmatically test for the relatedness of the
> token and secret? Could we perform automated security audits of OAuth
> libraries, looking for (anti-)patterns of implementation?
It would take
On 5/1/09 5:01 PM, Eran Hammer-Lahav wrote:
>> Explain how rev'ing HTTP to 1.2 would have "broke the web" ... ?
>
> Millions of client and server would no longer be able to interoperate
> without deploying new software, servers, proxies, caches, etc. When
> the client and server speaks a different
On 5/3/09 4:06 AM, Eran Hammer-Lahav wrote:
> We seem to be spending a lot of time on the question of how providers
> supporting both flows can tell which flow is being used. If they
> simply offer a new set of 3 endpoints: request token, authorize, and
> access token, this entire problem goes awa
Sorry, need to do a little copy-editing of what I wrote to clarify:
> If your argument is that our currently proposed change to the
> protocol breaks backwards compatibility, then say so. But saying
> "rev'ing the protocol version number will necessarily [break]
> backward compatibility" means t
It seems that the basic problem here is that we have a monolithic
version number for API calls and the handshake/dance protocol. There
are a couple of possible solutions that result if we use two
identifiers, one for the signature protocol and another for the
handshake protocol.
Option #
+1
On Sun, May 3, 2009 at 4:06 AM, Eran Hammer-Lahav wrote:
>
> We seem to be spending a lot of time on the question of how providers
> supporting both flows can tell which flow is being used. If they simply
> offer a new set of 3 endpoints: request token, authorize, and access token,
> this enti
> but you could do without a callback, asking the user to proceed
> (eventually asking him to input the token/pin/whatever is needed to
> close the loop) i.e. you need to treat the js application as if it was
> an installed app without callback capabilities.
I was referring to jQuery's Ajax callb
Hi there,
I see that OAuth 1.0 specifies RFC3986 URL encoding for parameters,
but upon looking at the Python reference library I see that RFC2396
(aka. urllib.quote) encoding is used. Is this in error?
The set of reserved characters differs in these specifications.
Thanks,
David.
--~--~-
13 matches
Mail list logo
