[twitter-dev] Re: oAuth still working for everyone.?

2010-12-04 Thread pgarvie
Twitter4J is ok

See this: 
http://www.springone2gx.com/blog/andrew_glover/2010/09/oauth_ing_twitter_with_twitter4j

It's the parameters you pass to twitter.getOAuthAccessToken()



On Dec 3, 12:13 am, Yusuke  wrote:
> Hi,
>
> I had confirmed the error message several hours ago and was looking
> into it.
> And somehow I don't see the error now.
>
> Please give it a try once again.
> If the problem persists, please post the exception stacktrace to
> twitte...@googlegroups.com.http://twitter4j.org/en/index.html#mailingList
>
> Thanks,
> Yusuke
>
> On Dec 3, 10:09 am, Hector  wrote:
>
> > Does anyone using twitter4j solve the oauth_verifier issue?
>
> > Thanks!

-- 
Twitter developer documentation and resources: http://dev.twitter.com/doc
API updates via Twitter: http://twitter.com/twitterapi
Issues/Enhancements Tracker: http://code.google.com/p/twitter-api/issues/list
Change your membership to this group: 
http://groups.google.com/group/twitter-development-talk


[twitter-dev] Re: oAuth still working for everyone.?

2010-12-04 Thread Dave-twiends
Yeah, I second that..

A sandbox authorize/request_token/access_token set of pages will be
great...

We could use these to check our implementations are up to spec with
the revision..

Thanks

On Dec 4, 5:19 pm, gumbah  wrote:
> Thanks for the roll back Taylor,
>
> both my Twitter apps were broken because of this... Since the roll
> back they're working again.
>
> We want to fix our code, but is there any way to check if the fixes we
> made to our code fix the (future)problem?
>
> cheers,
> G
>
> On Dec 2, 11:59 pm, Taylor Singletary 
> wrote:
>
>
>
>
>
>
>
> > Hi Folks,
>
> > We're going to rollback a subset of these changes for now. Before we give
> > this another try, we'll let everyone know the specific pain points and give
> > some time to adjust to them. In the meantime, those who experienced trouble
> > today will want to verify that their libraries are doing the right thing in
> > regard to the bullet points I posted above.
>
> > Also useful is making sure that you don't send additional headers related to
> > basic auth in an OAuth request, that you're using the proper, versioned
> > api-subdomain end points, etc.
>
> > Dave: It's pretty crucial that you send an oauth_verifier on the access
> > token step. It's not valid OAuth 1.0a without it.
>
> > Sorry about the mess folks. We should never have let these bugs persist for
> > so long.
>
> > Taylor
>
> > On Thu, Dec 2, 2010 at 2:45 PM, Tom van der Woerdt  wrote:
>
> > > Waiting doesn't help solve the issue. The spec hasn't changed, the API is
> > > just a bit more watching for the mistakes which some developers tend to
> > > make.
>
> > > I'd recommend diving into the code and fixing the errors, instead of 
> > > asking
> > > the Twitter API team to accept your "broken" OAuth implementations. :-)
>
> > > Tom
>
> > > On 12/2/10 11:42 PM, LeeS - @semel wrote:
>
> > >> I am using this library on all my sites:
> > >>https://github.com/jmathai/twitter-async,
> > >> all of which are now broken and fail to let anyone log in.
>
> > >> Any way this can be rolled back until all the various oAuth libraries
> > >> people are using are brought up to date?
>
> > >> Lee
>
> > >> On Dec 2, 5:35 pm, Dave-twiends  wrote:
>
> > >>> Thanks Taylor, yip unfortunately I wrote my oauth code about 18 months
> > >>> ago, before most of the libraries were out, so there could be anything
> > >>> wrong. It's probably not 100% spec compliant, which is probably why it
> > >>> broke.
>
> > >>> I've tracked down the issue to the access_token exchange part of the
> > >>> process. The access token's that I have from before are still working,
> > >>> just can't get new ones. I've noticed I'm not passing oauth_verifier
> > >>> back in the request, which could be causing the issue..
>
> > >>> Will let you guys know how I get on...
>
> > >>> Thanks for the pointers
> > >>> Dave
>
> > >>> On Dec 2, 9:57 pm, Taylor Singletary
> > >>> wrote:
>
> > >>>  We've corrected a number of long-standing OAuth-related bug fixes --
> >  mainly
> >  in areas where we more liberal than we should have been when verifying
> >  signatures.
>
> > >>>  Here are a few things to verify:
>
> > >>>  * Verify that you are using your consumer key where the consumer key is
> >  supposed to go. Compare this to what you see for you app on
> >  dev.twitter.com
> >  * Likewise, verify that you are using your consumer secret where it is
> >  supposed to go. Compare this to what you see for you app on
> >  dev.twitter.com
> >  * Laugh at the obviousness and absurdity of a check like that. Cry a
> >  little
> >  because we already know some people were doing the wrong thing here,
> >  especially on end points that didn't require authentication.
> >  * Verify that your timestamps are in range
> >  * If you're sending a request to a resource that doesn't require
> >  authentication but you're including OAuth credentials:
> >     - we used to just give you a free pass even if the credentials were
> >  incorrect. Hey, it doesn't require auth, so why bother checking?
> >     - now we check this. if you pass us an OAuth header or anything that
> >  looks like an OAuth-based request, we will check it for validity, even
> >  if
> >  it's a resource that doesn't require auth.
>
> > >>>  We haven't changed anything about our actual core signature validation
> >  code
> >  -- what was a valid signature before should be a valid one now. We're
> >  just
> >  checking the validity in more use cases than we were previously, and
> >  checking other validity points we were flexible with previously.
>
> > >>>  Taylor
>
> > >>>  On Thu, Dec 2, 2010 at 1:32 PM, Twitlonger >  >wrote:
>
> > >>>  I'm seeing a lot of invalid/expired token errors.
>
> > >>>  On Dec 2, 9:21 pm, Dave-twiends  wrote:
>
> > >> I noticed I've just started getting 401's for all my oAuth requests.
> > >> Seems to be happening on more than one site for me.

[twitter-dev] Re: oAuth still working for everyone.?

2010-12-04 Thread gumbah
Thanks for the roll back Taylor,

both my Twitter apps were broken because of this... Since the roll
back they're working again.

We want to fix our code, but is there any way to check if the fixes we
made to our code fix the (future)problem?

cheers,
G

On Dec 2, 11:59 pm, Taylor Singletary 
wrote:
> Hi Folks,
>
> We're going to rollback a subset of these changes for now. Before we give
> this another try, we'll let everyone know the specific pain points and give
> some time to adjust to them. In the meantime, those who experienced trouble
> today will want to verify that their libraries are doing the right thing in
> regard to the bullet points I posted above.
>
> Also useful is making sure that you don't send additional headers related to
> basic auth in an OAuth request, that you're using the proper, versioned
> api-subdomain end points, etc.
>
> Dave: It's pretty crucial that you send an oauth_verifier on the access
> token step. It's not valid OAuth 1.0a without it.
>
> Sorry about the mess folks. We should never have let these bugs persist for
> so long.
>
> Taylor
>
> On Thu, Dec 2, 2010 at 2:45 PM, Tom van der Woerdt  wrote:
>
> > Waiting doesn't help solve the issue. The spec hasn't changed, the API is
> > just a bit more watching for the mistakes which some developers tend to
> > make.
>
> > I'd recommend diving into the code and fixing the errors, instead of asking
> > the Twitter API team to accept your "broken" OAuth implementations. :-)
>
> > Tom
>
> > On 12/2/10 11:42 PM, LeeS - @semel wrote:
>
> >> I am using this library on all my sites:
> >>https://github.com/jmathai/twitter-async,
> >> all of which are now broken and fail to let anyone log in.
>
> >> Any way this can be rolled back until all the various oAuth libraries
> >> people are using are brought up to date?
>
> >> Lee
>
> >> On Dec 2, 5:35 pm, Dave-twiends  wrote:
>
> >>> Thanks Taylor, yip unfortunately I wrote my oauth code about 18 months
> >>> ago, before most of the libraries were out, so there could be anything
> >>> wrong. It's probably not 100% spec compliant, which is probably why it
> >>> broke.
>
> >>> I've tracked down the issue to the access_token exchange part of the
> >>> process. The access token's that I have from before are still working,
> >>> just can't get new ones. I've noticed I'm not passing oauth_verifier
> >>> back in the request, which could be causing the issue..
>
> >>> Will let you guys know how I get on...
>
> >>> Thanks for the pointers
> >>> Dave
>
> >>> On Dec 2, 9:57 pm, Taylor Singletary
> >>> wrote:
>
> >>>  We've corrected a number of long-standing OAuth-related bug fixes --
>  mainly
>  in areas where we more liberal than we should have been when verifying
>  signatures.
>
> >>>  Here are a few things to verify:
>
> >>>  * Verify that you are using your consumer key where the consumer key is
>  supposed to go. Compare this to what you see for you app on
>  dev.twitter.com
>  * Likewise, verify that you are using your consumer secret where it is
>  supposed to go. Compare this to what you see for you app on
>  dev.twitter.com
>  * Laugh at the obviousness and absurdity of a check like that. Cry a
>  little
>  because we already know some people were doing the wrong thing here,
>  especially on end points that didn't require authentication.
>  * Verify that your timestamps are in range
>  * If you're sending a request to a resource that doesn't require
>  authentication but you're including OAuth credentials:
>     - we used to just give you a free pass even if the credentials were
>  incorrect. Hey, it doesn't require auth, so why bother checking?
>     - now we check this. if you pass us an OAuth header or anything that
>  looks like an OAuth-based request, we will check it for validity, even
>  if
>  it's a resource that doesn't require auth.
>
> >>>  We haven't changed anything about our actual core signature validation
>  code
>  -- what was a valid signature before should be a valid one now. We're
>  just
>  checking the validity in more use cases than we were previously, and
>  checking other validity points we were flexible with previously.
>
> >>>  Taylor
>
> >>>  On Thu, Dec 2, 2010 at 1:32 PM, Twitlonger  >wrote:
>
> >>>  I'm seeing a lot of invalid/expired token errors.
>
> >>>  On Dec 2, 9:21 pm, Dave-twiends  wrote:
>
> >> I noticed I've just started getting 401's for all my oAuth requests.
> >> Seems to be happening on more than one site for me.. My application
> >> keys and status still look good..
>
> >>>  Just wondering if anyone else is having an issue..?
>
> >>>  --
> > Twitter developer documentation and resources:
> >http://dev.twitter.com/doc
> > API updates via Twitter:http://twitter.com/twitterapi
> > Issues/Enhancements Tracker:
> >http://code.google.com/p/twitter-api/issues/list
> > Change your membership to this group:
> >>>

[twitter-dev] recycled accounts?

2010-12-04 Thread Dean Collins
Does anyone know how long Twitter keeps accounts that were suspended for
whatever reason frozen before the open the account up to be re-used by
someone else?

 

Eg http://www.Twitter.com/LivePremLeague got suspended ages ago I think
at least a year ago (not my account)

 

Wondering if they will ever release it for someone to sign up fresh and
do something with this name. It seems crazy just to leave it locked
forever?

 

 

 

Cheers,

Dean

-- 
Twitter developer documentation and resources: http://dev.twitter.com/doc
API updates via Twitter: http://twitter.com/twitterapi
Issues/Enhancements Tracker: http://code.google.com/p/twitter-api/issues/list
Change your membership to this group: 
http://groups.google.com/group/twitter-development-talk


Re: [twitter-dev] xAuth Request gives Error from samsung tv maple browser

2010-12-04 Thread Tom van der Woerdt
You really shouldn't implement xAuth in JavaScript for obvious reasons, 
like how impossible it is to keep your keys secret.


Tom



On 12/4/10 6:19 AM, mahesh wrote:

HI Team,

Here i have been getting the following problem.

I can able to post the message to twitter using xAuth Protocol in
safari
but i can't from firefox ,samsung tv browser Maple and IE.

I am using javascript xmlhttprequest and sha1 for signature.

Is twitter send response when we  request from samsung tv
maple browser?.

More over when i try to request from samsung tv maple browser

i get following Error.

Status 401
Response :Failed to validate oauth signature and token

If i Run Same code in safari working fine can able to post the
message.

Please help me out what is the issue.

Thanks in Advance.



--
Twitter developer documentation and resources: http://dev.twitter.com/doc
API updates via Twitter: http://twitter.com/twitterapi
Issues/Enhancements Tracker: http://code.google.com/p/twitter-api/issues/list
Change your membership to this group: 
http://groups.google.com/group/twitter-development-talk