I have a little app that mines data on social networks and returns interesting results (e.g. the latest conversations around a certain topic). However, the front end requires that the users connects with the various services first via oauth, before these services' APIs can be scanned.
I would like this process to be automated on the server, so that a person using the app does not need to auth with Twitter, Fb, Linkedin in etc just to get results from those services. Is this possible?
No. This is not possible. The OAuth specification requires a user to first authenticate with the service and then authorize your application to request data on the user's behalf.
For twitter there is a hack: search, search, search! and 'connect' the tweets yourself :-)
This hack works for apps like http://jetwick.com
Related
I am using Twitter as an OAuth provider for ASP.NET MVC 4 web site. I would like to be able to follow up with a registered user at a later date, either by email or via a tweet. Outside of having the user follow me on Twitter, do I have any other options to communicate with the user?
Here is what I unsuccessfully considered:
It appears that there is no way to get access to the email address since Twitter OAuth API does not return it.
It appears I cannot send a direct message unless a user
follows me on Twitter.
"Read/Write/DirectMessage" permissions seem
too intrusive -- all I want to do is send a user a message that a
new product is released -- I don't need any of the write
capabilities that this level of permissions provides.
To recap, if a user used Twitter to sign in to my website, what are my options to contact that user at a later date?
Thanks.
Twitter's solution for this sort of person-to-person communication is the Direct Message, however, Twitter has (rightfully) decided that both parties need to consent to this channel being available. This decision is intended to reduce the amount of spam in the Twitter ecosystem.
Posting public tweets that mention the username will get your users' attention, but it is also broadcasting their relationship with your company to the entire Twitter ecosystem. You will, essentially, be advertising their relationship with your company without their permission. This approach will bring you headaches sooner or later.
Email is probably a better choice for the sort of announcement to existing customers.
Let's say I am making a sign up form in which I asked user's twitter ID. How do I verify if the ID entered by user belongs to him/her? In case of verifying email we simply send a verification link which user has to click so how do I verify twitter ID? I have never used twitter before.
The only reliable and practical way to verify that twitter account X belongs to user Y this to do full on “3 legged” OAuth authentication. That being said, you may want to consider if you might be OK with just taking the user at their word on it.
Getting OAuth to work and securely storing the resulting tokens is much easier nowadays than it once was, but is still non-trivial.
Reasons to verify the twitter account, in increasing reasonableness:
You will be making enough server side requests, on behalf of multiple users, that you run up against Twitter’s API Rate Limiting. (Having multiple auth-tokens will allow for a higher API rate)
You need to automagically send tweets and/or follow accounts on the user’s behalf
N.B. do this as opt-in and be ultra clear about when/why you will be doing this, or you will face the justified fury of scorned users
Don’t verify the account if you’re looking to do these things:
You need to send tweets and/or follow accounts on the user’s behalf, and the user will be able to perform a browser based confirmation workflow for each of those actions; use Twitter’s Web Intents for this.
If you just want to pull in real time data for user’s avatar, bio, or recent Tweets Twitter supplies some prefab widgets for you.
All of the authenticated Twitter API Calls can be done client side with JavaScript. Twitter has a js framework, which does not require you to handle and store tokens on your server, to help you with that.
An alternate contact method for password resets, notifications, etc.
Private communication between users on twitter requires mutual following, many users probably never check their Direct Messages (or even know what a DM is), and any messages would be limited to 140 characters. Just use email for all that kind of nonsense.
If you’re just gathering this info to display it on a user’s profile page, in an “other places on the web” kind of way, integrating and maintaining all the server side OAuth pieces is likely too much bother. Just make sure you have a reasonable and clear TOS and an obvious way for 3rd parties to report any of your users who may be claiming a twitter account that is not their own.
If you’re still interested in OAuth, Twitter's Dev page has plenty of resources, including a nice overview of a generic “Sign In with Twitter” “3 legged” OAuth work flow.
Could anyone please summarize the differences between Twitter's REST API and its Streaming API?
And does either of them uses Push technology?
The REST API lets you query or modify a user's account. You don't need their permission to query their account, you do need it to modify their account. They provide permission through OAuth authentication.
The streaming API delivers tweets based on search terms or for specific users you request, along with info about the author, in real-time. You do not need the tweet author's permission. You must log into some Twitter account to use streaming, using either basic or OAuth authentication.
Neither uses push, but streaming is a continuous net connection, so it is real-time delivery, making it functionally similar to push.
For anybody coming to this more recently, The REST API (v1.0) has now been retired with v1.1 being the only version. This Does now require authentication for everything, including reads.
Authentication required on all endpoints
In version 1.1, we're requiring applications to authenticate all of
their requests with OAuth 1.0a or Application-only authentication. Not
only will this visibility allow us to prevent abusive behavior, but it
will also help us to further understand how categories of applications
are using the API. We'll apply that understanding to better meet the
needs of developers as we continue to evolve the platform. At this
time, all authentication requires user context, but in the coming
weeks we'll be pushing out support for a form of authentication not
requiring a user context.
Actually you can use search through the REST API as well. For example it's the only way to combine geo AND query keyword, while the Stream API can only use OR logic.
I think it's about defacto push streaming as Adam Green has said.
I have a corporate website that I want to pull in tweets to, but i'm getting a rate limit using the http feed. So, I want to use an authenticated method to get the tweets.
Do I really have to register an application to do this, even though it's not really an application and my users will never be entering or changing the twitter account info.
Also, my corporate site doesn't have a public address, and registering an application through twitter appears to require a public url. So how can I get around this? Do I have to create a "fake" application with a public url, just to generate my keys?
Thanks for any help on this.
If your site is behind a proxy server along with all your users, using Javascript/jQuery won't help. All the requests will still be coming from the same IP and will hit a rate limit, as you're doing now.
The other issue is that you don't need to register an app to request a feed. Apps are only needed for Oauth, and getting a feed doesn't need that.
The best way to deal with this is to get the feed with a server script, store it on the server, and then deliver the server copy to the web pages. If you request the feed less than 150 times per hour, you won't have a limit problem.
If you want more than a single feed, you can use the streaming API to get all the tweets for up to 400 keywords or from up to 5,000 users. This still doesn't need a registered app, since the streaming API still allows Basic Auth.
Just wanted to post this for future reference and in case anyone else has the same question. The solution to my problem, was to register an application on twitter. But since I'm just using a single user, you don't have to do the regular OAuth steps of generating a request for a key, getting the response etc. Every app you register in twitter get's its own "Access Token" that you can use to retrieve tweets etc. So, this is what I ended up doing to solve the problem I was having.
Additional details: My main concern was having to do the OAuth steps of requesting an access code etc... Since my application is only a single user implementaion (just pulling in our company related tweets from company held twitter accounts), it just seemed unneccesary to have to do all of that. But what I found was that when you register an app on twitter, you get a private access token for each app. You can view a little information about that here: https://dev.twitter.com/pages/oauth_single_token.
It sounds like you are pulling the feed down over http on the server? You could just limit the updates so you don't hit the rate limit.
I would recommend instead doing this on the client side. There are a lot of very easy to use embeddable java script twitter clients out there. The rate limiting problem would dissapear as the feed would be coming from the desktop and not the server (unless they just kept refreshing it).
The Twitter developer wiki lists a few.
JQuery plugin for Twitter
Tweet (another JQuery plugin)
I asked various questions about my problem (here and here) and I also asked in the #oauth & #openid freenode's channel on IRC. (this is note an "UP" question, it's an other problem)
I'll sum up my project configuration : Anyone will have the possibility to create an app that can use my API. To start, I'll work on my API and a Web based app, but the documentation about the API will be public. It's a bit like Twitter API.
The problem I face is how can I be sure which user is using the API (to retrieve his personal data, like your tweets), even if the User is using an app that I don't know who make it (again, like twitter and all the apps around).
I googled a lot and with the help of the previous answers given, I took a look at OAuth.
As far as I understood the way OAuth works, here how :
A user visit an app that use my API (web, mobile, whatever)
The apps redirect the user to the API for the authentication (I'll use OpenId) and the authorization (OAuth). This is a bit odd since the API will have a web interface for the login and the authorization (I suppose this is how it works since Twitter do that)
The API redirect the connected user to the app, with some tokens. In these tokens, there is a token representing the user that the app must store in order to indicate to the API which user is using it currently (Am I correct?)
So far, everything goes well. But what I can't figure it out, is when the user quit the app and goes again : how the app can remember the user is the one that used it before ?
(Before some of you bring me the cookie answer, I'll remark this is a simple example, it would be the same if the user clear his cookies, format his computer or change its computer.)
The only solution I can find, is when an unauthenticated user (without a remembering cookie for example) goes to the app, the app redirect him again to the API to authenticate himself, but this time, the user won't have to re-allow the app (authorization) since it already did it. The API will then return the user to the app to allow him to play with this.
Is this the proper & secure way to do it ?
The #OAuth IRC channel told me about the new protocol, WebID, but this is currently in pre-draft mode and I don't want to use something that will change continuously in the future :/
Thank you very much for your help!
Short answer: OAuth results in an authenticated access token. That access token is tied to ONE user. And as long as the access token is valid. The third application can do whatever the API allows the access token to do.
Long answer:
The thing with OAuth is that it does not "Log in" a user. OAuth gives third party applications what is called access tokens which can be used to access data on behalf of a user whether he/she is logged in or not.
Many services restrict their access tokens. Twitter for example issues two types of access tokens, read-only, and read/write. But there is no concept of logging in to use APIs. While an access token is valid, a third party application can access the user's data, and change things without a user's explicit interaction.
Most API providers have functionality to revoke access tokens. That is what happens when you in twitter look at your Connections page . See the revoke access links?
Personally I love the OAuth approach. As an API provider, you can control what access tokens are allowed to do, and the user can kill bad applications from using his/her resources. OAuth is secure as far as authentication goes. Third party applications do not get hold of user's passwords. But once authenticated they can do whatever your API allows.
if we take a look at how Twitter works, I think the missing point is an other layer to the project: The Official website:
The thing is, when you want to allow any 3rd party application to use Twitter, this application redirect you to the OAuth page of the Twitter API, IF you are connected, but if you aren't, it redirect you to the login page, which is located at http://api.twitter.com/login
(I don't know if keeping the api in api.twitter.com for loging an user, instead of just twitter.com is correct, but this is just semantics)
So, the workflow would be:
A user goes to a 3rd party application (like a website)
This third party redirect the user to the API for Authorization
The API redirect the User to the website for Authentication first
The official website redirect the User to the OpenId provider (or Facebook connect)
The Authentication is made (via multiple requests)
The website redirect the user to the API after he's successfully authenticated
The user allow/disallow the permissions asked by the 3rd party apps
The API returns to the 3rd party apps.
The User can now use (or not) the application.
This implementation have 2 problems:
Every time an User ins't authenticated (cleared it's cookies, connect himself from an other computer, etc), he will have to go through the Authentication method, by being redirected to the Official website and then being redirected to the 3rd party application (the API would be transparent, since it has already allowed the application to access his data).
All those layers would certainly lost the User on the Authentication process with too many redirections.
A possible solution would be to store the user's access_token, for example in the case of a mobile app, but with a pure html/css/js oriented app, this isn't possible. A login/password in the 3rd party web application that would match the user to the access_token of the API would be an other solution, like Seesmic (I think), but this is just useless (for us, not Seesmic) : the idea of not having the user's password become useless.
This is a possible explanation but I would require more details on how this is possible and your thought about that solution. Would it work?
(I added this as an answer since it's an (incomplete and not so sure, I agree) one.