user streams, right now, uses basic auth. user streams are in a preliminary
/ experimental stage - we do not recommend (john would use stronger words)
using them in production. we will be implementing oauth on the streaming
api soon-ish.
On Wed, Apr 28, 2010 at 4:10 PM, Aral Balkan wrote:
> A q
A question on this and how it relates to User Streams. Unless I'm
mistaken (only took a cursory look/played around with User Streams),
User Streams uses Basic Auth. So if my app uses both the User Streams
API and the REST API, I have to both use xAuth for the REST calls and
store the username/passw
On 4/27/2010 4:38 PM, Taylor Singletary wrote:
The twitter screen name is less of a concern, yes John. But a Twitter
username can take an email address also, which isn't information
otherwise provided by the API and is personally identifiable and
especially dangerous when stored in conjunction wi
The twitter screen name is less of a concern, yes John. But a Twitter
username can take an email address also, which isn't information otherwise
provided by the API and is personally identifiable and especially dangerous
when stored in conjunction with a password. A screen name, in context with
dat
yeah - i would say that storing the "pair" of the username and password is
probably not a good idea.
On Tue, Apr 27, 2010 at 3:28 PM, John Meyer wrote:
> On the xAuth page you say "Storage of Twitter usernames and passwords is
> forbidden". Now given that you don't want applications needlessly
On the xAuth page you say "Storage of Twitter usernames and passwords is
forbidden". Now given that you don't want applications needlessly
querying the system and you've encouraged caching of information that
isn't likely to change overtime (such as a username, screenname, etc),
would I be inc
