Realised I may have missed the point slightly here - that callbacks aren't actually a problem because it's about what the *user* can access, not Twitter itself. So if the user can access the non-public server, the callbacks can point there without a problem. Right? :)
Supplementary question: am I going to run into issues with exposure of my application's secret keys/tokens as a result of it being open source? Thanks again, Biggs On Aug 19, 11:19 am, BigglesZX <biggle...@gmail.com> wrote: > Hi all, > > I'm currently writing a web app that interfaces with Twitter - I won't > bore you with the details, but suffice to say that this app is > designed to be installed on individual users' web servers, and uses > read-only access to the Twitter API to perform a few useful functions. > > Up until this week I was using Basic Auth, and the time has now come > for me to move the app over to OAuth. However, I'm a bit confused as > to which OAuth method would be most suitable for my app. > > Here are a couple of constraints: 1) The app may end up being > installed on a non-public-facing server, so the use of callback URLs > might be a bit difficult. 2) The most straightforward flow in my mind > would be if users could enter their username/password (or some other > kind of auth token) in the app's config file (which suggests using > xAuth to me, from a reading of the docs). > > The desktop Twitter clients I use seem to have no problem taking/ > storing a username and password and converting that into an OAuth > transaction. Would they be using xAuth? > > Basically I'm open to advice as to which OAuth method I should be > considering for this app. I want to make things as secure/ > straightforward as possible for the user while ensuring that the app > will work in a variety of environments (including private servers that > can't receive callbacks). > > Any thoughts or tips as to how I could achieve this would be hugely > appreciated. Thanks for reading, > > Biggs
