[twitter-dev] Re: Access Tokens Changed?
I concur with David on this one. I didn't take the time to verify this scenario myself, but it does seem like it's a problem. Consider the following scenario: 1. A user has whitelisted 10+ web applications using their credentials. 2. The end user has no knowledge of what an access token is or what it entails. 3. The end user is forced to login using force_login to my application. 4. The end user hits Cancel during the authentication process. 5. The user's access token changes, revoking their access for all 10+ web applications. I guess the kicker is whether or not this is reproducible. If it is, this would seem to be a problem. Perhaps there is a workaround? On Dec 23, 11:58 am, David dtran...@gmail.com wrote: I feel like this isn't the expected behavior if a user hits Cancel when you authenticate with force_login=True - if start typing in another username, then hit cancel, it shouldn't revoke the access token for the currently authenticated user. -- 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: Twitter Search API - Possible Proximity Bug
bump On Dec 22, 9:31 am, Corey Ballou ball...@gmail.com wrote: So... did this make it's way to the bug tracker? Is there any clarification if not? On Dec 21, 9:37 am, Corey Ballou ball...@gmail.com wrote: API call: http://search.twitter.com/search.json?q=ands=keggeocode=35.22708600... On Dec 20, 7:31 pm, Corey Ballou ball...@gmail.com wrote: It's also worth noting that while the above example may not be pulling a place, the API call I'll be including tomorrow uses the latitude/ longitude pair pulled from the Google Maps API V3 geocoder with the same outcome. On Dec 20, 7:22 pm, Corey Ballou ball...@gmail.com wrote: Here's my non API call searches from search.twitter.com with a 5mi range: keg near:121 W Trade St, Charlotte NC within:5mihttp://search.twitter.com/search?q=+keg+near%3A%22121+W+Trade+St%2C+C.. If you extend the radius to 10mi, you'll get significantly more results. My office is in the heart of Charlotte at a major intersection as well (Trade St and Tryon St). http://search.twitter.com/search?q=+keg+near%3A%22121+W+Trade+St%2C+C.. Based on the results returned from the 10mi radius, it seems to indicate that even though I tweeted from a Place, the tweet is being generalized to the parent city bounding box of Charlotte, NC. It just doesn't feel right; does it have to do with an optimization to avoid the heavy cost of performing calculations for sorting by distance? I'll update this post with the API call tomorrow morning when I get in the office. I've got it tucked away in the error logs with no root password in my keychain. In the meantime, any clarification or light you can shed on how you guys are calculating proximity would be much appreciated. Regards, Corey On Dec 20, 5:36 pm, Matt Harris thematthar...@twitter.com wrote: Im not entirely clear on how to reconstruct the query you are trying to make. Can you share the full Search URL request you are making so we can take a look. Thanks, @themattharris Developer Advocate, Twitterhttp://twitter.com/themattharris On Mon, Dec 20, 2010 at 1:16 PM, Corey Ballou ball...@gmail.com wrote: While running some tests on the search API I noticed a potential issue with the search API's proximity handling when filtering by places. If I specify a radius of 5 miles with a search term of keg and the address of my office building, I would expect to retrieve a previous tweet of mine: Tweet in question: http://twitter.com/cballou/statuses/15770007518584832 The status update in question was created with an associated place_id of my office, which properly maps to the right address. The place in question (Skookum, Charlotte, NC): https://search.twitter.com/search?q=place%3A5c9b53e1da87e502 Theoretically, I should be able to search within a one mile radius with the address. In this case, the only way I'm able to retrieve my tweet is to bump the radius up to 10 miles. I've tested this issue using both lat/lon coordinates with my application as well as using your advanced search (search.twitter.com/advanced) with the full address. Am I missing something here? Are you associating places to the overall city and not the exact lat/lon marker of an address? When I view the place directly, the marker placement is indicative of having the proper lat/lon coordinates. Let me know if you need any clarification or additional details. Regards, Corey -- 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 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] followers using user_id gives 401, but screen_name works fine
Hi, im trying to get follower ids using user id and when I do that I
get the 401 Unauthorized
uri: /1/followers/ids.json?user_id={user_id}
Twitter::Unauthorized: (401): Unauthorized - This method requires
authentication.
It works fine if I do screenname
uri: /1/followers/ids.json?screen_name={screen_name}
If this is not possible, is there a way to get follower screen names
instead of follower_ids ? I would prefer not to have to burn extra api
calls switching between screen_name and user_id.
thanks
Joel
--
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] Re: Access Tokens Changed?
It is reproducible. Just have valid an access token then go through /oauth/authenticate with force_login=true and hit cancel. The access token will no longer be valid. I would not expect hitting cancel to revoke my access token while I would expect hitting deny to revoke my access token. I feel like this is just an oversight on Twitter's part that they have multiple buttons that perform the same action but are presented differently. Corey: Access tokens are application specific so unless 10+ web applications are all sharing the same consumer key/secret only the single application the user is currently authenticating with will have an invalidated access token. Abraham - Abraham Williams | Hacker Advocate | abrah.am @abraham https://twitter.com/abraham | github.com/abraham | blog.abrah.am This email is: [ ] shareable [x] ask first [ ] private. On Mon, Dec 27, 2010 at 06:46, Corey Ballou ball...@gmail.com wrote: I concur with David on this one. I didn't take the time to verify this scenario myself, but it does seem like it's a problem. Consider the following scenario: 1. A user has whitelisted 10+ web applications using their credentials. 2. The end user has no knowledge of what an access token is or what it entails. 3. The end user is forced to login using force_login to my application. 4. The end user hits Cancel during the authentication process. 5. The user's access token changes, revoking their access for all 10+ web applications. I guess the kicker is whether or not this is reproducible. If it is, this would seem to be a problem. Perhaps there is a workaround? On Dec 23, 11:58 am, David dtran...@gmail.com wrote: I feel like this isn't the expected behavior if a user hits Cancel when you authenticate with force_login=True - if start typing in another username, then hit cancel, it shouldn't revoke the access token for the currently authenticated user. -- 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 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: followers using user_id gives 401, but screen_name works fine
I think my problem is a result of :
Warning: The user ids in the Search API are different from those in
the REST API (about the two APIs). This defect is being tracked by
Issue 214. This means that the to_user_id and from_user_id field vary
from the actualy user id on Twitter.com. Applications will have to
perform a screen name-based lookup with the users/show method to get
the correct user id if necessary.
I dont understand why search would use a different user id, if they
have to, why not at least call it something else like search_user_id
or something.
Joel
On Dec 27, 10:38 am, joelkeepup taskow...@gmail.com wrote:
Hi, im trying to get follower ids using user id and when I do that I
get the 401 Unauthorized
uri: /1/followers/ids.json?user_id={user_id}
Twitter::Unauthorized: (401): Unauthorized - This method requires
authentication.
It works fine if I do screenname
uri: /1/followers/ids.json?screen_name={screen_name}
If this is not possible, is there a way to get follower screen names
instead of follower_ids ? I would prefer not to have to burn extra api
calls switching between screen_name and user_id.
thanks
Joel
--
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
