As far as I understand, if I have a command-line program, the recommended way of authenticating is using a PIN-based authentication. So, in the first step, I should be sending the parameter oauth_callback to oob in the POST request.
My first question is: if the user that wants to authenticate with my command-line application has access to the browser, could I use the non-PIN-based authentication anyway (even if that’s not the recommended way)? I suppose so.
Now, my second and main question is: in general, what should the callback URL be? Can it just be anything? Is it supposed to be the URL of a real website that we own? Or we don’t have to own it? Does the site even have to exist? I am not sure I understand the purpose of this callback URL. In my specific case, I don’t have a web application or a server running and serving some webpages.
These are follow-up questions of the questions that I asked here: What happens if you don't specify oauth_callback in the first step of the 3-legged auth?
Yes, this is probably a better way.
the callback should be a publicly accessible URL - so if this is a CLI app, it should be the address that can reach the machine that is running the App. Unfortunately this is sometimes more complicated - and you need to a way to: Run a server with a public url that will do the authentication, also make sure your CLI can talk to this server, and that way the authentication will be handled in a browser under a server and url you administer, and anyone else using your CLI app will have to contact that server for the auth keys and cache them or something.
Yes, this is probably a better way.
Could you explain why it’s a better way? What are the advantages of non-PIN based authentication if my program is still a CLP?
the callback should be a publicly accessible URL - so if this is a CLI app, it should be the address that can reach the machine that is running the App. Unfortunately this is sometimes more complicated - and you need to a way to: Run a server with a public url that will do the authentication, also make sure your CLI can talk to this server, and that way the authentication will be handled in a browser under a server and url you administer, and anyone else using your CLI app will have to contact that server for the auth keys and cache them or something.
I don’t understand. In all other authentication methods I’ve come across for other platforms (most of them provide OAuth2-based authentication), I didn’t need to setup any server. Why do we need to setup a server only for this? It doesn’t make sense to me and I’ve not seen this being mentioned anywhere in the documentation so far.
You said in the other answer that I could be using http://localhost as the callback URL, but can I really do that then or not? I am confused now.
It’s more user friendly, authenticating is a matter of a user accepting the app, and that’s it. With pin based auth they have to copy the pin and enter it into the app manually.
The issue with a command line app is that if you have multiple users, there are multiple ways you can set it up. The simplest way is to not provide your own app keys at all, and let people use their own. PIN based auth works well here. This is the way we did it for twarc: GitHub - DocNow/twarc: A command line tool (and Python library) for archiving Twitter JSON you can try running twarc2 configure after installing to see how we solved the exact same problem, maybe the example will explain better. The downside here is that every user of your app must be a developer and have their own keys.
If you want all your users to just log in using their twitter account, to authenticate using your own developer app, so they don’t need to be developers themselves, you will need to set up a server on a publicly accessible url, set that as the callback, and manage the authentication yourself. This is more complicated but more user friendly. We don’t do this with twarc, we require people to have their own developer keys.
Hope that clears it up!
