I am trying to develop a very basic console application that will retrieve a user's homepage (twitter updates from people followed by the user) and save it (json). I've read a lot on the internet, but still am unsure of whether i need to 'register' such an application, and if yes, how could I possibly do it for a console app.
I'd like to get a step-by-step rundown on how I should proceed with the development. Its just a tad complex for a noob like me in this field. I'm aware that off-the-shelf libraries for doing this job are aplenty, but I lack a general understanding of how I should approach this.
Much appreciated,
Abhi
The answer really depends on a few things.
If your application is not going to try to access information about protected users (users can opt to be protected so their information and tweets are kept private) your application will not need to be authorized by any user and will not need to be registered or deal with OAuth. Without using OAuth, you will be limited to making 150 requests per hour, per IP address.
If your application needs to make more than 150 requests an hour, or needs to access protected user information, then you will need to register your application and make requests on behalf of a user. This user could be your twitter account. This will give you up to 300 requests per hour per authorized user.
I can't give you much detail as to how to best write a console application with TweetSharp., but I am familiar with Twitterizer (I wrote it).
Related
While the Microsoft Graph API seems to be very complete feature wise, it seems like I am stuck at a fairly easy request. For a small web application I want to list apps that are registered in Azure. What a want to do with them is a little bit out of scope, but in the end I want to show the user some important applications (which we flag in some way - using tags or something like that) that the user has access to.
Now, using the /applications resource in the beta endpoint of the Graph API I can retrieve a list of applications. Now, the application does not need admin consent. When requesting the apps, it retrieves all registered apps, which is a bit odd I think. Why would it return all apps and not just the ones that are assigned to me?
But okay, lets move on. Now I have the list of apps (or the metadata of it). How can I determine if the signed-in user has access to this application (or it doesn't require assignment). Am I missing something or is this nowhere to be found?
You can use query parameters to customize responses. Please check the link https://learn.microsoft.com/en-in/graph/query-parameters
I have used appRoleAssignment with the neccessary parameters to retrieve all apps a user has access to. Turned out to be quite simple. Beta only, but stable.
Recently, YouTube decided to make video tags unavailable publicly. So to get the tags for a given video, I need to make an authenticated request to the API as the owner of the video. This is not a problem in my case as I'm fetching my own videos.
However, I'm confused about the authentication flow since YouTube strongly recommends to use OAuth2. Since I'm always going to authenticate as the same user (the owner of the video, aka myself), I definitely don't need to have any browser page for the actual user of the app to do anything. I see how I could have done it using ClientLogin (hardcoding login and password into the app) but I'm not sure how to approach this using OAuth2.
One last detail - that is not necessarily relevant since a high-level answer would be enough - is that I'm developing on iOS. Also I looked at this https://developers.google.com/accounts/docs/OAuth2 and particularly the web server case which seems closest to mine but was not able to get a clear idea from it.
Thanks in advance for your help and don't hesitate if you need me to be more specific.
There is no OAuth flow that supports your use case.
In general, you should not be distributing your YouTube login as part of your application. Even if this were available via ClientLogin, after a certain number of logins, you would likely be presented with a challenge because the authentication servers would detect a strange usage pattern.
OAuth is not for distribution a single user's login to a large N, where N is the number of users of your application. OAuth is meant for your application to act on behalf of an end user, and because tags are no longer exposed to end users through the UI, it does not make sense to expose them to users via the API either. More details can be found here:
http://apiblog.youtube.com/2012/08/video-tags-just-for-uploaders.html
How many videos do you have? What is the purpose for needing the tag metadata? From a pragmatic perspective, here are a few alternative implementations that would be easier and would not require users to log in as you:
Store a single file mapping video IDs to tags on a server somewhere and fetch this periodically. Google App Engine is a good place to do this.
Put the tag data in the description in a predictable format (you host the videos), and generate the metadata from this.
I'm building a standalone couchdb application. These are called couchapps. The idea is that the database itself is served on port 80 and returns HTML and works as the actual website. This is a very powerful idea and I'm entirely amazed by this new concept of having your code live inside your database.
But I'm having some issues with user registration. The one built into couchdb allows for cookies to be set and makes it really easy to plug it into your website. But there's several quite important things missing that my app requires in order to say that it has a "proper" user registration system.
There's no signup verification. No email is sent, no captcha is displayed. This means that anyone could spam your _users database and create as many new users as they please.
If a user forgets their password there's no facility to help them recover it.
Any idea how I could overcome these issues without doing any hardcore Erlang development at a lower level (not an Erlang guy)? It would also be great if anybody knew if I could be using OAuth to authenticate against Twitter or GitHub accounts and have that integrate seemlessly with how couchdb data is handled (inside validate_doc_update functions).
Thank you
While the built in user database can work, I would not recommend it for the workflow you describe. Here are some other options:
Browser ID
I would really recommend using BrowserID. IrisCouch has provided a plugin to couchdb here:
https://github.com/iriscouch/browserid_couchdb
This will take care of the normal registration workflow.
If you want to take it a step further and have your users "Fairly Anonymous", you can follow the example of this couchapp called "Mingle"
https://github.com/thedod/Mingle
Twitter Integration
Max Ogden's "DataCouch" project has a log in via twitter, although it is using some Node external processors to make it work. See here:
https://github.com/maxogden/datacouch/blob/master/processors/auth/twitterauth.js
Facebook integration
https://github.com/ocastalabs/CouchDB-Facebook-Authentication
OpenID
https://github.com/mcaprari/couchdb-openid
I dont think you can use the oauth purely with Couch, as this post suggests:
http://bennolan.com/2011/01/11/couchdb-oath.html
so the closest you will get there is following what Datacouch has done.
Hope these suggestions help.
I'm using https://github.com/jnunemaker/twitter to tweet to a users twitter when they post on their blog running on ROR. .e.g
Tweet : "I just posted a blog - 'I love ruby on rails' http://link-to-blog.com"
My question is, as I'm making many sites for different people do I have to create a new twitter developer application, with individual consumer keys & secrets, for each blog or is there a way to use the same twitter application?
Thanks,
Alex
You technically can use the same application in a variety of websites. Just use the keys/tokens twitter gives you in all your sites.
Nonetheless, this is a bad practice, since twitter will not be accounting your accesses to the API from the pages that are not the one you specify in the Callback URL. Furthermore, your users will return to that (and only to that) page that you specified in the callback URL, which can be very misleading for those that are in other site.
And finally the most important reasons are the following two:
You'll get to the request limit quicker than if you had several applications
You'll get to the user limit quicker than if you had several applications
The limits that twitter manages are not very big so I can tell you that the twitter functionalities won't work if you get a good peak of visits (happened to me twice). Or they may not work if you're site receives a lot of visits at a certain time. No matter if your cache your API or not, you'll end up filling the limit.
Here is the twitter documentation about this:
Caching. We recommend that you cache API responses in your application or on your site if you expect high-volume usage. For example, don't try to call the Twitter API on every page load of your hugely popular website. Instead, call our API once a minute and save the response to your local server, displaying your cached version on your site. Refer to the Terms of Service for specific information about caching limitations.
Rate limiting by active user. If your site keeps track of many Twitter users (for example, fetching their current status or statistics about their Twitter usage), please consider only requesting data for users who have recently signed in to your site.
Scale your use of the API with the number of users you have. When using OAuth to authenticate requests with the API, the rate limit applied is specific to that user_token. This means, every user who authorizes your application to act on their behalf, has their own bucket of API requests for you to use.
Request only what you need, and only when you need it. For example, polling the REST API looking for new data is inefficient for both your application, and the Twitter API. Instead consider using one of the Streaming APIs as a signal of when to make REST API requests.
If you have any question, don't hesitate to comment below. I had terrible experiences with this when my site got mentioned by a few important twitter accounts
I'm working on a small Rails application in which I'd like users to be able to prove that accounts they have at other sites, Live Journal, Stack Overflow, Reddit, etc. are in fact theirs.
Can anyone provide any guidance on how best to accomplish something like this?
I've outlined some potential options for account verification.
Ask users to basically pass their log in credentials to the application via SSL and allow it to verify that it can log in. Then, of course, log out and delete any user session data/credentials. Problems:
People are not going to psyched about the idea of exposing their credentials to a third party system.
Handing off log in information may well be against many
website's ToS agreements.
The idea makes me queasy.
Provide the user with a hash and ask them to insert it into some field of the their public profile. Putting "aTWIUqHRgxEpSVaQzCYc" in the location field of my Stack Overflow account for example and then having the application verify the hash via either API or screen scrape depending on the website.Problems:
This is tedious to do for more than one or two websites.
Some sites don't have any sort fields with user supplied information. Reddit for example.
Again, provide the user with a hash but ask them to send that hash via the website's message system to a specified user account. A server process would routinely check that account's inbox and then link the hash with the account. This seems like the easiest solution.
3B. Have the user friend the specified account when applicable.
I've not yet done enough due diligence investigating what options OAuth or OpenId might provide to speak intelligently about them.
I realize the headache of having to verify accounts this way is going to cause a barrier to entry. Not only that but failing to have a single consistent method for doing it.
I would go with OAuth / OpenID, there is a gem called omniauth and it supports a wide variety of external providers. Ryan Bates has made 3 railscasts about omniauth so you could start there! It's really easy to get it up and running. If you follow the railscasts by Ryan Bates you can allow your users to use more than 1 provider (e.g twitter, openid and facebook).