This is all resolved!!
The oauth_version was the second parameter, and i ensured the correct
path was done api.twitter.com/1/statuses/update.xml
I want to say thank you to all the people that have helped me here on
twiter dev talk. esp Taylor!!! Thanks guys!!!
On Jun 10, 3:55 pm, Michael Cameron
Great, Josh, I'll check that out.
Thank you
On Jun 12, 7:50 pm, Josh Roesslein wrote:
> I author a library called Tweepy [1] that works fine with OAuth.
>
> [1]http://github.com/joshthecoder/tweepy
>
> On Sat, Jun 12, 2010 at 9:39 PM, pythonista wrote:
> > Hello,
> > I am using the simplegeo fo
I author a library called Tweepy [1] that works fine with OAuth.
[1] http://github.com/joshthecoder/tweepy
On Sat, Jun 12, 2010 at 9:39 PM, pythonista wrote:
> Hello,
> I am using the simplegeo fork of python-oauth2, and it is working
> fine.
>
> However, I then realize it doesn't contain API
Hello,
I am using the simplegeo fork of python-oauth2, and it is working
fine.
However, I then realize it doesn't contain API calls to actually send
tweets.
Anyone know of a particular Api wrapper that has updated its code, so
that calls are made using the token/token secret that is now
mandator
I can't access past page 5 on any account when I'm checking for 200
tweets at a time. Page 6 returns no tweets.
I should be able to access up to 16 pages to get 3200 tweets. I have
been able to retrieve that up until I tried again Friday. Is this a
temporary limit?
Here is an example:
http://api.
I got an error 500 after I get the authentication (from
https://api.twitter.com/oauth/access_token). I get this error while
trying to contact https://api.twitter.com/1/statuses/home_timeline.json.
I'm using xAuth and
- I'm using SSL
- I'm using the header-based OAuth (which is OAuth
oauth_consumer
Right, and...
On Sat, 12 Jun 2010 16:09:47 -0700 (PDT)
Jef Poskanzer wrote:
> You know, it's right there in the OAuth RFC.
>
> http://tools.ietf.org/html/rfc5849#section-4.6
>
> 4.6. Secrecy of the Client Credentials
>
>In many cases, the client application will be under the control of
>
Quoting funkatron :
Yeah, it's really the step of manually getting that long string of
seemingly-random characters from one app to another. a callback url
makes sense for web-based apps.
Something like PIN auth that would allow a desktop/mobile app to make
an HTTP call and recover the string pr
You know, it's right there in the OAuth RFC.
http://tools.ietf.org/html/rfc5849#section-4.6
4.6. Secrecy of the Client Credentials
In many cases, the client application will be under the control of
potentially untrusted parties. For example, if the client is a
desktop application with
On Jun 12, 2010, at 3:05 PM, Bernd Stramm wrote:
>> I've been pondering how you could solve this from my experience with
>> solving these issues with SSL/TLS. One idea is having a sort of
>> delegation chain where I could generate a new delegated secret for
>> each copy of my app I distribute rathe
On Sat, 12 Jun 2010 13:25:44 -0700
Zac Bowling wrote:
> On Jun 12, 2010, at 11:57 AM, Jef Poskanzer wrote:
> > Application authors are being asked to devote substantial resources
> > to the OAuth conversion, but OAuth provides no security for
> > application authors!
>
> It does from a web app p
> Yeah, it's really the step of manually getting that long string of
> seemingly-random characters from one app to another. a callback url
> makes sense for web-based apps.
>
> Something like PIN auth that would allow a desktop/mobile app to make
> an HTTP call and recover the string programatical
Yeah, it's really the step of manually getting that long string of
seemingly-random characters from one app to another. a callback url
makes sense for web-based apps.
Something like PIN auth that would allow a desktop/mobile app to make
an HTTP call and recover the string programatically would be
On Jun 12, 2010, at 11:57 AM, Jef Poskanzer wrote:
> Application authors are being asked to devote substantial resources to
> the OAuth conversion, but OAuth provides no security for application
> authors!
It does from a web app perspective which is the primary design goal of OAuth
since there wo
> I think you're missing the point, Taylor. It's not a matter of
> validation, but actually being able to copy such a long string. I have
> trouble with this on mobile, and I think I'm a pretty savvy user. I
> *guarantee* you the rate of failure, and giving up on the process
> entirely, will be muc
I think you're missing the point, Taylor. It's not a matter of
validation, but actually being able to copy such a long string. I have
trouble with this on mobile, and I think I'm a pretty savvy user. I
*guarantee* you the rate of failure, and giving up on the process
entirely, will be much higher t
Hi,
We are getting following response
{"request":"/1/statuses/retweet/15918472331.json","error":"Could not
authenticate with OAuth."}
for RETWEET using XAUTH implementation.
We could not figure out what may be the possible reason for this
error.
I also get similar error while accessing the DIR
Hi Vijay,
If you only want access to your own account then you can visit the
application details for your application on http://dev.twitter.com/apps. On
that page you will find an option called My Access Token. This option will
display the user token and secret for you to be able to access your
ap
I love this idea!
But why don't you use verifier instead of such a long string?
ck=KIyzzZUM7KvKYOpnst2aOw&cs=4PQk1eH4MadmzzEZ1G1KdrWHIFC1IPxv1kXZg0G3E&at=5
42212-
utEhFTv5GZZcc2R4w6thnApKtf1N1eKRedcFJthdeA&ats=FFdeOEwxOBWPPREd55
dKx7AAaI8NfpK7xnibv4Yls
I don't want to copy&paste such a string
On Jun 12, 11:49 am, Bernd Stramm wrote:
> secure against what?
The threat that OAuth's security-through-obscurity fails to protect
against is rogue-app B doing something bad while using legit-app A's
stolen credentials. The author of app A gets blamed for app B's bad
behavior and app A gets shu
On Sat, 12 Jun 2010 09:48:15 -0700
Zac Bowling wrote:
> Yes, that is a problem with any app that you distribute that has any
> embedded keys. Unfortunately, you ultimately can't really entirely
> secure anything you ship that a user can run on their own machine.
> You can however take a few steps
Hi Phil,
Check out the twitter integration with www.LiveWorldCupChat.com if
that's what you want.
Cheers,
Dean
> -Original Message-
> From: twitter-development-talk@googlegroups.com
[mailto:twitter-development-
> t...@googlegroups.com] On Behalf Of Phil Leggetter
> Sent: Saturday, 1
On Jun 12, 10:16 am, Taylor Singletary
wrote:
> (This is the other side of the coin.. on one side of the coin you have the
> advantage that OAuth applications keep working even if the user changes
> their password (YAY!) and then you have on the side of the coin that OAuth
> applications keep work
Yes, this is correct. To perform this key exchange, a consumer key (API key)
with this feature enabled is all that's required to be stored in your open
source app.
Some other interesting facts:
- A parent application can only spawn 1 version of itself for a user. If
the user repeats the flow, t
Regarding the user being able to set the source tag themselves: they will be
able to -- the application created for the user is totally their
application. They can change the name of the application to anything they
want (within the same rules as any application name on the platform).
The WordPres
I may be being naive but i fail to see the fill issues with having the
key and secret public.
What are they going to do with it? the user would still have to agree
to use the app in question that is posing as a legitimate app.
The genuine app only needs to get a new secret once a vulnerability is
Yes, that is a problem with any app that you distribute that has any embedded
keys. Unfortunately, you ultimately can't really entirely secure anything you
ship that a user can run on their own machine. You can however take a few steps
to make that extremely difficult by encrypting and obfuscati
>obfuscate your code (compiling, or intentional obfuscation)
So OAuth's security is based on obscurity? That's pretty lame.
As it was explained to me (I think the API team would do well by
discussing this stuff out in the open so we don't have to answer for
them), the concern is having keys available in plain text. with OSS,
you have that in 1, and potentially 2, situations:
1: Source code distributions/repos
2: end-us
A solution, maybe, for desktop folks who can C+P a large string
(although I'm willing to bet you'll have a lot of breakdown there),
but it will fail miserably on mobile apps. The string is way, way too
long. This will get screwed up badly by non-technical users.
(Yes, some people make open-source
> Sorry over looked the access token being included. I still do not think this
> fits well with open source
> desktop apps. I think for now just not distributing a key with the app's
> source, but provide it when the app
> is built (hidden in the binary or such).
That works fine with binaries, but
Sorry over looked the access token being included. I still do not think this
fits well with open source
desktop apps. I think for now just not distributing a key with the app's
source, but provide it when the app
is built (hidden in the binary or such).
On Sat, Jun 12, 2010 at 10:09 AM, Cameron Ka
Hello all!
I'm working on a project called Kwwika which allows anybody to add
real-time push functionality to your website. To try and get people
developing using Kwwika we've decided to create a competition that
will hopefully encourage web developers to sign up for the opportunity
of winning an
> Not sure I totally like this idea. Seems almost like double authentication
> to me.
> The user has to still sign in via the web to replicate the app and then we
> have to fetch an access token
> again by asking for their credentials?? So its like doing a 3-legged dance +
> the xAuth.
No. The pro
Not sure I totally like this idea. Seems almost like double authentication
to me.
The user has to still sign in via the web to replicate the app and then we
have to fetch an access token
again by asking for their credentials?? So its like doing a 3-legged dance +
the xAuth.
I really question the s
> @taylor
> So key exchange is done based on consumer key only.(No need to verify the
> signature?.Makes sense as this is distributed )So any abuse by the end user
> will only lead to the ban of child app ? (assuming the final auth requests
> are signed by the generated secrets (chid app secret and
Hello! I got troubles with whitelisting request
I filled form to get more request per hour for my project about 30 or
35 days ago for the first time and about 5 or
6 days ago for the second time.
I receiver two e-mails in response:
"Hi [myusername],
Thanks for requesting to be on Twitter's API
Hi,guys
when I call the follow API,it returns "/1/notifications/
follow.xml Not found"!
Does it means follow API can't work?
How should I do?
Thank you all!:)
Hi,
Pardon my ignorance here as a 1st time poster.
My actual requirement:
My web app using jQuery/Juitter needs to access my twitter account's
private List of people I am following.
I am trying to use a proxy service with a java servlet on the
serverside to access the Twitter API.Basic Auth is no
Hey,
ich want to write a Safari Twitter Extension. Ok everything fine, but
i don't know the right way to authenticate with Twitter. I think OAuth
isn't the right way, am i right? I want to update my status with
Username & Password stored in the Extension Properties. Can i do a
authentication just
Interesting idea.
I didn't think it was to hard if you had user that was fiddling with your
source to just have him generate his own keys and while I just compile my keys
into my official binary builds but I guess for scripting based clients, this
makes sense. I guess you get the attribution a
Hi,
Is it possible to get those links when using the user_timeline REST
API:
http://twitter.com/status/user_timeline/{user}.json?count=5&callback=?
The returned result doesn't give you any links - the http/https and
the links to other twitter accounts are just as plain text.
I need a simple way
If the attacker does that, the loser is only that user but not the app
(parent app) Basically this idea is to
shield the apps from being misused.
@taylor
So key exchange is done based on consumer key only.(No need to verify the
signature?.Makes sense as this is distributed )So any abuse by the en
I don't understand why you are suggesting this only for open source
programs. Were you thinking that an attacker would be incapable of
decompiling an executable and extracting the secret?
44 matches
Mail list logo
