I've been providing both consumer keys since I started using OAuth for Twitter, and I'm still encountering issues because of this change. This is frustrating beyond words.
On Jul 28, 7:03 am, João Pereira <joaomiguel.pere...@gmail.com> wrote: > I'm also frustrated. > > I can't have a consistent behaviour from twitter API. Now works fine then > give invalid signature for all users, then works again, can't understand > grrrr > > Moreover, for the same user, using the same code for authentication, some > call works and others don't. > > When will you guys at twitter get this back working? > > On Tue, Jul 28, 2009 at 11:53 AM, srikanth reddy <srikanth.yara...@gmail.com > > > > > wrote: > > Hi > > i think now both access secret and consumer secret are required. i verified > > this by giving blank consumer secret and valid access secret and i got > > invalid signature error. It works fine when i give correct values for both. > > Looks like there is no way you can protect your consumer secret > > > On Tue, Jul 28, 2009 at 2:59 PM, thetago...@googlemail.com < > > anto...@cloudangels.com> wrote: > > >> @Doug - Can you confirm that it is now MANDATORY to supply both access > >> token and access secret as well as the consumer key and consumer > >> secret to generate a valid signature? OAuth spec states in #4 that > >> consumer secret may be empty if no consumer verification is neeeded. > > >> ------[excerpt from spec]------ > >> "Service Providers SHOULD NOT rely on the Consumer Secret as a method > >> to verify the Consumer identity, unless the Consumer Secret is known > >> to be inaccessible to anyone other than the Consumer and the Service > >> Provider. The Consumer Secret MAY be an empty string (for example when > >> no Consumer verification is needed, or when verification is achieved > >> through other means such as RSA)." > >> ------[end excerpt from spec]------ > > >> This would mean that you'd have to ship the customer secret to the > >> client with each deliverable you publish, regardless of whether you > >> want to do client verification or consumer (i.e. Server) verfication. > > >> best regards, > >> Toni > > >> On 28 Jul., 10:56, kosso <kos...@gmail.com> wrote: > >> > my problems are opposite (using some php scripts) verification is ok, > >> > tweeting ok, but verified timelines (friends and mentions) not ok. > > >> > On Jul 27, 9:29 pm, winrich <winric...@gmail.com> wrote: > > >> > > ok guys. > > >> > > so my calls were failing on the verify_credentials call and not on the > >> > > update or timeline calls. the only difference i saw was the the > >> > > verify_credential call wasn't secured. i changed it to https and it > >> > > worked. ??? lol > > >> > > On Jul 27, 9:19 pm, Chad Etzel <jazzyc...@gmail.com> wrote: > > >> > > > On Mon, Jul 27, 2009 at 11:55 PM, Duane > > >> > > > Roelands<duane.roela...@gmail.com> wrote: > >> > > > > RTFM is not a helpful answer, especially when many developers are > >> > > > > relying on libraries that they did not write. > > >> > > > That's a risk you run when using code you didn't write. > > >> > > > I'm not saying that this situation doesn't suck for those affected. > >> > > > I'm sure that it does. But, for a technology so new as OAuth, the > >> > > > libraries may not be mature yet. > > >> > > > Officially, Twitter OAuth is still in Public Beta and has never been > >> > > > officially recommended to integrate into production code. That being > >> > > > said, there could still be a problem on Twitter's end with their > >> > > > signature verification mechanism and the libraries could all be > >> valid. > >> > > > I don't have a way of knowing. > > >> > > > I do agree that at least a note that "a security change was pushed > >> > > > today" would be nice, though. > > >> > > > -Chad