As stated previously the easy way to determine OAuth 1.0 vs 2.0 without using negative assertions is to check for the presence of oauth_signature_method
On Mon, Jun 14, 2010 at 1:09 PM, David Recordon <[email protected]> wrote: > It's easy to detect version when calling a protected resource. In > OAuth 2.0 you only have one token parameter whereas 1.0 has a variety > of parameters including a signature. > > --David > > > On Mon, Jun 14, 2010 at 9:05 AM, Rob Richards <[email protected]> > wrote: > > Wouldn't it make sense to require the oauth_version parameter under 2.0 > for > > resource calls so that the two versions can be distinguished? > > > > Rob > > > > Paul Lindner wrote: > >> > >> If you're routing requests with a load balancer it's not so trivial. > >> Instead of a substring match you're talking about a regex with negative > >> lookahead matching -- that's why the presence of the signature param is > >> essential to distinguishing between 2.0/1.0a. > >> > >> On Thu, Jun 10, 2010 at 10:42 AM, Eran Hammer-Lahav < > [email protected] > >> <mailto:[email protected]>> wrote: > >> > >> But in that case, all the other oauth_* parameters are missing. > >> It's trivial. > >> > >> EHL > >> > >> > -----Original Message----- > >> > From: Marius Scurtescu [mailto:[email protected] > >> <mailto:[email protected]>] > >> > Sent: Thursday, June 10, 2010 10:39 AM > >> > To: Paul Lindner > >> > Cc: Eran Hammer-Lahav; OAuth WG ([email protected] > >> <mailto:[email protected]>) > >> > Subject: Re: [OAUTH-WG] Identifying OAuth 2.0 vs 1.0 requests > >> > > >> > I run into the same issue. In section "4.2. URI Query > >> Parameter", it would > >> > help if the parameter name, oauth_token, was different from OAuth > 1. > >> > > >> > Marius > >> > > >> > > >> > > >> > On Thu, Jun 10, 2010 at 9:41 AM, Paul Lindner <[email protected] > >> <mailto:[email protected]>> wrote: > >> > > I am talking about the resource server. Specifically I want to > >> be able > >> > > to quickly determine if an incoming request is 1.0a vs 2.0. > >> And since > >> > > this is a library it can't make a lot of assumptions about the > >> > > specific environment it's running in. > >> > > At first I thought I would check the oauth_version parameter. It > >> > > turns out the 1.0a spec says that it is optional. The only > >> one that > >> > > is required for 1.0a is oauth_signature_method. > >> > > Sadly we're long past time to change the spec to optimize for > >> this use-case. > >> > > (It would have been better to have a parameter for oauth 2.0 > >> that is > >> > > distinct from 1.0a) At the very least this message will live > >> on in > >> > > the mailing list archives -- at best we document the proper way > to > >> > > distinguish between the two versions somewhere. > >> > > On Thu, Jun 10, 2010 at 8:44 AM, Eran Hammer-Lahav > >> > > <[email protected] <mailto:[email protected]>> > >> > > wrote: > >> > >> > >> > >> The request is very different on the resource server. On the > >> > >> authorization server, why would you use the same endpoint? > >> > >> > >> > >> > >> > >> > >> > >> EHL > >> > >> > >> > >> > >> > >> > >> > >> From: [email protected] <mailto:[email protected]> > >> [mailto:[email protected] <mailto:[email protected]>] On > >> > >> Behalf Of Paul Lindner > >> > >> Sent: Thursday, June 10, 2010 8:24 AM > >> > >> To: OAuth WG ([email protected] <mailto:[email protected]>) > >> > >> Subject: [OAUTH-WG] Identifying OAuth 2.0 vs 1.0 requests > >> > >> > >> > >> > >> > >> > >> > >> Hi, > >> > >> > >> > >> > >> > >> > >> > >> As I've been working through our oauth2 implementation I've > >> noticed > >> > >> that it's not easy to disambiguate OAuth 1.0a vs 2.0 API > >> calls based > >> > >> on the request parameters alone. Based on some > >> investigative at the > >> > >> Shindig project it appears that the only standard way to to > >> determine > >> > >> 1.0a vs 2.0 is by checking for the oauth_signature_method > >> > parameter. More info here: > >> > >> > >> > >> > >> > >> > >> > >> https://issues.apache.org/jira/browse/SHINDIG-1361 > >> > >> > >> > >> > >> > >> > >> > >> Has anyone else considered this use case? How did you solve it? > >> > >> > >> > >> > >> > > > >> > > _______________________________________________ > >> > > OAuth mailing list > >> > > [email protected] <mailto:[email protected]> > >> > > https://www.ietf.org/mailman/listinfo/oauth > >> > > > >> > > > >> > >> > >> ------------------------------------------------------------------------ > >> > >> _______________________________________________ > >> OAuth mailing list > >> [email protected] > >> https://www.ietf.org/mailman/listinfo/oauth > >> > > > > _______________________________________________ > > OAuth mailing list > > [email protected] > > https://www.ietf.org/mailman/listinfo/oauth > > >
_______________________________________________ OAuth mailing list [email protected] https://www.ietf.org/mailman/listinfo/oauth
