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

Reply via email to