Eh, ideally I wouldn't require my users to enter the PIN into our application. Should I just register my app as Browser-based one and redirect my users to our company's website?
Also, this may be a question for the maker of our twitter library (twitter4j) but at what point after the user has authorized our application to connect to their account am I able to extract the security token from the request token? If I pause my application and wait for them to acknowledge that they successfully allowed the connection in twitter, should I be able to access that security token immediately. Thanks, Bradley On Tue, Jul 21, 2009 at 6:40 PM, Hedley Robertson<hedley.robert...@gmail.com> wrote: > If you set the oauth_callback with a value of "oob", it will not redirect > the user, but provide the PIN style authorization behavior. > > See this older post on the new style of calling these params: > > http://groups.google.com/group/twitter-api-announce/browse_thread/thread/472500cfe9e7cdb9 > > Hope this helps. > > Hedley > > On Tue, Jul 21, 2009 at 2:06 PM, Bradley Wagner <bradley.wag...@gmail.com> > wrote: >> >> Hi, >> >> I work on a Content Management System solution in which we're >> currently trying to integrate Twitter. Here is the issue: >> >> Our software is installed, so while it is browser-based there is not a >> consistent URL to redirect people to and thus nothing that really >> makes sense to fill out when registering our application. >> >> That said, I'd like to avoid to requiring the users of our software to >> visit a url and copy/paste a PIN to authorize our application to send >> updates to their twitter accounts. >> >> Is there a recommended way to do this? Where should that URL be >> redirecting them to? It's my understanding that if they visit the URL, >> an access token can be generated without the use of a pin (we're using >> twitter4j for this part). I guess we could just redirect them to our >> product's website or some page that says "go back into our app and >> click OK to enable the twitter connection". >> >> Thanks, >> Bradley > >