Re: [twitter-dev] Re: Please confirm this OAuth flow ...

2011-05-19 Thread Arnaud Meunier 
Hey everyone,

There have been some great discussions and questions across several threads
and also directly on Twitter. In order to make it simple for you guys to get
answers to your questions, we've just set up a dedicated FAQ page for the
new Application Permission model:
http://dev.twitter.com/pages/application-permission-model-faq

We'll keep updating it as long as your questions come in.

Thanks a lot,
Arnaud / @rno 


On Thu, May 19, 2011 at 9:54 AM, janole  wrote:

> Only people with "modern devices" should read direct messages? Why?
>
> What about the 100.000.000 ( yes, 100 million! ) Symbian smartphones,
> where apps cannot use the external browser for the web oauth flow?
>
> As far as I know from my users, they really want to read their direct
> messages on their phones via my client. They are doing this since
> early 2009 and they won't understand why they now might not be able to
> do this anymore.
>
> Ole ( @janole / @gravityapp )
>
>
>
> On May 19, 5:20 pm, Tom van der Woerdt  wrote:
> > Can you name a modern device on which people will want a client with
> > access to direct messages, without a webbrowser? I can't.
> >
> > Tom
> >
> > On 5/19/11 5:17 PM, Adriaan Pelzer wrote:
> >
> >
> >
> >
> >
> >
> >
> > > Understood. In other words, there is no way to consume the
> > > authenticated parts of the Twitter API on devices without web browsers
> > > anymore?
> >
> > > This severe limitation will haunt Twitter in future, without a doubt.
> >
> > > Adriaan Pelzer
> >
> > >  //))//\\//\\||//
> > > //\\//7//7///\\
> >
> > > putting you in touch with your crowds
> > >http://www.wewillraakyou.com
> > > twitter:http://www.twitter.com/adriaan_pelzer
> > > linkedIn:http://uk.linkedin.com/pub/adriaan-pelzer/4/874/860/
> > > skype: adriaan_pelzer
> > > +4478 7978 1743
> >
> > > On Thu, May 19, 2011 at 4:00 PM, Tom van der Woerdt  > > > wrote:
> >
> > > Like I mentioned in my post - use the actual browser which
> > > includes an address bar (that's what it's about - without the
> > > address bar the user doesn't know it's actually twitter.com
> > >  and you might just as well use xAuth, lol).
> > > Use a callback URL which includes a custom scheme
> > > (myapp://oauth_redirect, for example) and catch this URL in your
> code.
> >
> > > Tom
> >
> > > On 5/19/11 4:58 PM, Adriaan Pelzer wrote:
> > >> If using a UIWebView is against the TOS, how should app
> > >> developers (standalone apps, that is) authenticate without xauth,
> > >> in the light of yesterday's announcements?
> >
> > >> Adriaan Pelzer
> >
> > >>  //))//\\//\\||//
> > >> //\\//7//7///\\
> >
> > >> putting you in touch with your crowds
> > >>http://www.wewillraakyou.com
> > >> twitter:http://www.twitter.com/adriaan_pelzer
> > >> linkedIn:http://uk.linkedin.com/pub/adriaan-pelzer/4/874/860/
> > >> skype: adriaan_pelzer
> > >> +4478 7978 1743
> >
> > >> On Thu, May 19, 2011 at 3:53 PM, Tom van der Woerdt  > >> > wrote:
> >
> > >> 1. Yep
> > >> 2. NO. There's no difference in oauth/authorize and
> > >> oauth/authenticate, except that authenticate will simply pass
> > >> the "accept/deny" screen if the user has already accepted the
> > >> app. Also, don't display it in a WebView, use the normal
> > >> browser instead and use a callback URL with a custom scheme -
> > >> for example myapp://. Let the browser redirect this URL back
> > >> to the app. Again, do NOT use a UIWebView - I'm pretty sure
> > >> that that's against the TOS, and if it's not, it soon will be.
> > >> 3. Yep
> > >> 4. Yes, you will need to store the consumer token and secret
> > >> in the code, and store the user's token and secret in the
> > >> keychain (or somewhere else, secure).
> >
> > >> The OAuth flow is no different for mobile devices than for
> > >> desktops.
> >
> > >> Tom
> >
> > >> On 5/19/11 4:45 PM, Andrew W. Donoho wrote:
> > >>> Gentle Twitter Support Folks,
> >
> > >>> There is an ambiguity in the OAuth flow for mobile
> > >>> devices. As I now have little time to move from xAuth to
> > >>> OAuth, I would appreciate it if Twitter Support would
> > >>> confirm the following OAuth flow which uses your routes.
> >
> > >>> 1) Use "POST oauth/request_token" to get the access token
> > >>> needed for the user web dialog.
> >
> > >>> 2) Upon receiving the request token, open a web view using
> > >>> "GET oauth/authorize". This is the ambiguous path for mobile
> > >>> devices. It is specified that this path must be used for
> > >>> desktop devices. As a mobile device is really a wireless
> > >>> desktop device, I believe Twitter wants me to use this route
> > >>>

[twitter-dev] Re: Please confirm this OAuth flow ...

2011-05-19 Thread janole 
Only people with "modern devices" should read direct messages? Why?

What about the 100.000.000 ( yes, 100 million! ) Symbian smartphones,
where apps cannot use the external browser for the web oauth flow?

As far as I know from my users, they really want to read their direct
messages on their phones via my client. They are doing this since
early 2009 and they won't understand why they now might not be able to
do this anymore.

Ole ( @janole / @gravityapp )



On May 19, 5:20 pm, Tom van der Woerdt  wrote:
> Can you name a modern device on which people will want a client with
> access to direct messages, without a webbrowser? I can't.
>
> Tom
>
> On 5/19/11 5:17 PM, Adriaan Pelzer wrote:
>
>
>
>
>
>
>
> > Understood. In other words, there is no way to consume the
> > authenticated parts of the Twitter API on devices without web browsers
> > anymore?
>
> > This severe limitation will haunt Twitter in future, without a doubt.
>
> > Adriaan Pelzer
>
> >  //))//\\//\\||//
> > //\\//7//7///\\
>
> > putting you in touch with your crowds
> >http://www.wewillraakyou.com
> > twitter:http://www.twitter.com/adriaan_pelzer
> > linkedIn:http://uk.linkedin.com/pub/adriaan-pelzer/4/874/860/
> > skype: adriaan_pelzer
> > +4478 7978 1743
>
> > On Thu, May 19, 2011 at 4:00 PM, Tom van der Woerdt  > > wrote:
>
> >     Like I mentioned in my post - use the actual browser which
> >     includes an address bar (that's what it's about - without the
> >     address bar the user doesn't know it's actually twitter.com
> >      and you might just as well use xAuth, lol).
> >     Use a callback URL which includes a custom scheme
> >     (myapp://oauth_redirect, for example) and catch this URL in your code.
>
> >     Tom
>
> >     On 5/19/11 4:58 PM, Adriaan Pelzer wrote:
> >>     If using a UIWebView is against the TOS, how should app
> >>     developers (standalone apps, that is) authenticate without xauth,
> >>     in the light of yesterday's announcements?
>
> >>     Adriaan Pelzer
>
> >>      //))//\\//\\||//
> >>     //\\//7//7///\\
>
> >>     putting you in touch with your crowds
> >>    http://www.wewillraakyou.com
> >>     twitter:http://www.twitter.com/adriaan_pelzer
> >>     linkedIn:http://uk.linkedin.com/pub/adriaan-pelzer/4/874/860/
> >>     skype: adriaan_pelzer
> >>     +4478 7978 1743
>
> >>     On Thu, May 19, 2011 at 3:53 PM, Tom van der Woerdt  >>     > wrote:
>
> >>         1. Yep
> >>         2. NO. There's no difference in oauth/authorize and
> >>         oauth/authenticate, except that authenticate will simply pass
> >>         the "accept/deny" screen if the user has already accepted the
> >>         app. Also, don't display it in a WebView, use the normal
> >>         browser instead and use a callback URL with a custom scheme -
> >>         for example myapp://. Let the browser redirect this URL back
> >>         to the app. Again, do NOT use a UIWebView - I'm pretty sure
> >>         that that's against the TOS, and if it's not, it soon will be.
> >>         3. Yep
> >>         4. Yes, you will need to store the consumer token and secret
> >>         in the code, and store the user's token and secret in the
> >>         keychain (or somewhere else, secure).
>
> >>         The OAuth flow is no different for mobile devices than for
> >>         desktops.
>
> >>         Tom
>
> >>         On 5/19/11 4:45 PM, Andrew W. Donoho wrote:
> >>>         Gentle Twitter Support Folks,
>
> >>>         There is an ambiguity in the OAuth flow for mobile
> >>>         devices. As I now have little time to move from xAuth to
> >>>         OAuth, I would appreciate it if Twitter Support would
> >>>         confirm the following OAuth flow which uses your routes.
>
> >>>         1) Use "POST oauth/request_token" to get the access token
> >>>         needed for the user web dialog.
>
> >>>         2) Upon receiving the request token, open a web view using
> >>>         "GET oauth/authorize". This is the ambiguous path for mobile
> >>>         devices. It is specified that this path must be used for
> >>>         desktop devices. As a mobile device is really a wireless
> >>>         desktop device, I believe Twitter wants me to use this route
> >>>         in lieu of "GET oauth/authenticate". Other vendors also
> >>>         allow the specification of whether this is a mobile device.
> >>>         They then provide a web authorization dialog appropriate for
> >>>         a narrow screen. It does not appear that Twitter offers this
> >>>         functionality. Could you please confirm this? Finally, as my
> >>>         app runs on an iPad, what is the preferred web view width?
> >>>         (To support both portrait and landscape orientations, it
> >>>         needs to be less than 768 pixels. 600 pixels is a common,
> >>>         Apple suggested, width.) Could you please enlighten me to
> >>>         what is Twitter's preferred authorization web view width?
>
> >>>