I'm glad this would annoy them, maybe they would do it properly. I don't see how they can put their own request token. They would have to manually construct the request token and authorization requests which is a lot of extra work and they are by passing the library and doing their own implementation. We can not totally stop bad coding practices, but our libraries can help avoid them and provide clear examples on how to apply oauth.
On Thu, Apr 30, 2009 at 2:28 PM, Eran Hammer-Lahav <e...@hueniverse.com>wrote: > Not giving access to the request token will not prevent early binding, > just annoy the bad developers really set on doing it. They can still add > their own “request token” to the callback and bind based on that. > > EHL > > > > On 4/30/09 10:29 AM, "Mike Malone" <mjmal...@gmail.com> wrote: > > On Thu, Apr 30, 2009 at 10:12 AM, Jesse Myers <jesse.my...@gmail.com> > wrote: > > > I can't say that I agree. > > > What do you disagree with? Eran said early binding would be addressed in > the security considerations section. > > The fact of the matter is that a lot of developers are going to > encounter OAuth for the first time when they first need to integrate > with an SP. Most developers will immediately download an OAuth library > from somewhere and start to work with it. They probably won't read the > OAuth spec and internalize it. If they do read the spec, they may just > gloss over whatever disclaimer warns them off of early binding or not > have any idea what early binding is. > > > Early binding is also harder. Why would you try to maintain state > (user/request token binding) between requests when you don't have to? The > path of least resistance is the right one in this case, which should be > enough to keep most "bad developers" from screwing things up. > > I can't think of any way you'd be able to enforce this constraint in the > OAuth libraries short of not providing access to the request token. And > that's not really an option since the consumer app needs to persist the > request token somewhere, and the library has no way of knowing where that > somewhere is. > > Mike > > > > > > > --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "OAuth" group. To post to this group, send email to oauth@googlegroups.com To unsubscribe from this group, send email to oauth+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/oauth?hl=en -~----------~----~----~----~------~----~------~--~---
