Using OAuth without a User Interface

AndrewMBaines · 2012-02-20T16:10:05.000Z

My application is a Windows dll that is called by a 3rd party product running on a schedule as a Windows Service. As such, there is no User Interface, and certainly no web browser. The application just tweets, nothing clever.

I applied to use XAuth, but was told that there were other ways to authenticate & authorize, but no clues given! I need different customers to use my application on their own servers, so they do need to authorize my application.

So, where to start? Have I been incorrectly refused access to XAuth, or am I missing something?

Thanks

Andrew

episod · 2012-02-22T16:16:16.000Z

It’s possible they’ve made a wrong decision, but it’s true that there are ways to accomplish this without needing something like xAuth – which really shouldn’t distributed widely.

You should be able to register a URL handler in your operating system and use the callback flow with OAuth: [node:2867]

AndrewMBaines · 2012-02-22T16:25:17.000Z

Lack of a UI is my main problem. It looks like I’ll need to create a separate app that needs to be run after installation. That will fetch a PIN to be stored (encrypted) locally.
Just need to find the time now.

It would just be nice to have some simple samples that walk you through this stuff - the Twitter API is easy, it’s OAuth that’s the pain. It’s not enough to just point you to a different website for help. If I get this working, I’ll be writing up on my blog, so hopefully help somebody else.

On the same subject - documentation doesn’t just mean listing all the methods of an API!

kurrik · 2012-02-23T00:55:25.000Z

If you see a problem with [node:3398] or [node:2927] please let us know. In particular, the first article explains the PIN flow you’d need to implement for your case, and the second tries to present the OAuth signing flow as clearly as possible.

AndrewMBaines · 2012-02-23T11:00:02.000Z

I’ve given up on Twitter’s own documentation - any document that references 6 others is worse than useless. All you need is step by step guides for common scenarios. I have no interest in learning authentication - I regard that as just the plumbing, and it shouldn’t be difficult.
If it’s any consolation, the documentation for Twitterizer (.Net Twitter wrapper) is equally bad.
I’ve found a helpful blog that I can work through.

kurrik · 2012-02-23T17:29:20.000Z

Really? “Worse than useless”? So we’re actually harming you by putting these documents online?

There are exactly three pages you need to read to understand precisely how to send a signed request. If that’s too much of a bother, then you should use a library like the documentation says. We don’t maintain official libraries, so the documentation on those vary greatly. There are some great ones like tmhOAuth, but others are like Twitterizer.

We don’t offer copy & paste solutions, because there are just too many combinations of programming language, execution environment, and use case to be able to satisfy enough developers. We’re a small team and have to work on things which offer the most return on investment. For example, there are just not enough developers writing UI-less .NET clients to make it worth it to do a step-by-step guide. However, this is basic enough that any good client library should have an example which replicates most of what you would need. I know tmhOAuth does this for PHP.

And if you find a useful piece of documentation somewhere and actually go to the process of posting about it here, please include a link so that others in your situation might be able to save themselves the trouble of trying to find it.

AndrewMBaines · 2012-02-23T17:51:23.000Z

Sorry if I’ve touched a raw nerve! If a customer criticises something I’ve done, I take note and try and improve my approach. I don’t shout them down. You asked me to point out any problems; I did; look where it got me.
This is my first experience of the Twitter API, and so far it’s been awful. On asking (mistakenly) about using xAuth, I was just told no, there are other ways - no mention of what those other ways were - I had to find out for myself about the different approaches.

kurrik · 2012-02-23T19:20:27.000Z

I’m trying to explain why the documentation is the way it is. The response you got from your XAuth request should have been more detailed, sure, but you asked here and got a reasonable response back- that doesn’t seem terribly painful to me. The [node:3062] page also lists your exact use case and points to the PIN based approach.

The feedback I’ve gotten from you is:

1.) “It’s not enough to just point you to a different website for help.” I don’t understand this because the links you were given point to this site.

2.) “Any document that references 6 others is worse than useless.” It’s unfortunate, but the specification we’ve decided to use for auth is complicated and explaining it thoroughly takes some work. If you actually got stuck on a part and want it to be clarified, that would be the kind of feedback we’d really value.

3.) “It would just be nice to have some simple samples that walk you through this stuff” and “All you need is step by step guides for common scenarios.” What “stuff”? What scenarios? Which languages? Which frameworks? Which web server? If we can’t write it, we may be able to point you to reasonable examples in client libraries.