http://dev.twitter.com/pages/api_terms -> II. Principles -> 1. Don't surprise users -> C. Your application should not: -> replicate, frame, or mirror the Twitter website or its design.

Tom


On 5/19/11 5:10 PM, hax0rsteve wrote:

Tom,

Could you clarify :

If using a web view is against the ToS, could you state which section ?

And if "it soon will be" (which conflicts with the above), what makes you think so ?

Did I miss something ?

Also, if someone from the Twitter team could confirm either of these, this would be much
more helpful.




On 19 May 2011, at 16:00, 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 <http://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 <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 <i...@tvdw.eu <mailto:i...@tvdw.eu>> 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?

    3) Use "GET oauth/authenticate" to acquire the access token and
    access secret.

    4) As I haven't yet requested my new consumer key and, hence,
    do not know some things, will I also be maintaining a consumer
    secret for my OAuth signature mechanism?

    Thank you for your support.

    Anon,
    Andrew


    P.S. Thank you for the two week extension for our xAuth to
    OAuth transition. Because Apple may still reject my app for
    unrelated to Twitter issues, four weeks is still a totally
    inadequate period to ensure a zero downtime transition. Please
    recognize both the risks to our business and the hardship you
    are imposing on small organizations. Furthermore, Apple's WWDC
    conference occurs in the middle of your current
    conversion schedule, this only allows me, in effect, 3 weeks to
    make this change. You can really hurt us with your imposed
    schedule. While I doubt that is your intent, it is,
    nonetheless, a likely outcome. Please double, at least, your
    conversion period to 8 weeks.

    ____________________________________
    Andrew W. Donoho
    Donoho Design Group, L.L.C.
    a...@ddg.com <mailto:a...@ddg.com>, +1 (512) 750-7596,
    twitter.com/adonoho <http://twitter.com/adonoho>

    "When you can't imagine how things are going to change,
        that doesn't mean that nothing will change.
            It means that things will change in ways that are
    unimaginable."
                Bruce Sterling, January 02, 2009







-- Twitter developer documentation and resources:
    https://dev.twitter.com/doc
    API updates via Twitter: https://twitter.com/twitterapi
    Issues/Enhancements Tracker:
    https://code.google.com/p/twitter-api/issues/list
    Change your membership to this group:
    https://groups.google.com/forum/#!forum/twitter-development-talk 
<https://groups.google.com/forum/#%21forum/twitter-development-talk>

-- Twitter developer documentation and resources:
    https://dev.twitter.com/doc
    API updates via Twitter: https://twitter.com/twitterapi
    Issues/Enhancements Tracker:
    https://code.google.com/p/twitter-api/issues/list
    Change your membership to this group:
    https://groups.google.com/forum/#!forum/twitter-development-talk
    <https://groups.google.com/forum/#%21forum/twitter-development-talk>


--
Twitter developer documentation and resources: https://dev.twitter.com/doc
API updates via Twitter: https://twitter.com/twitterapi
Issues/Enhancements Tracker: https://code.google.com/p/twitter-api/issues/list Change your membership to this group: https://groups.google.com/forum/#!forum/twitter-development-talk <https://groups.google.com/forum/#%21forum/twitter-development-talk>


--
Twitter developer documentation and resources: https://dev.twitter.com/doc
API updates via Twitter: https://twitter.com/twitterapi
Issues/Enhancements Tracker: https://code.google.com/p/twitter-api/issues/list Change your membership to this group: https://groups.google.com/forum/#!forum/twitter-development-talk <https://groups.google.com/forum/#%21forum/twitter-development-talk>

--
Twitter developer documentation and resources: https://dev.twitter.com/doc
API updates via Twitter: https://twitter.com/twitterapi
Issues/Enhancements Tracker: https://code.google.com/p/twitter-api/issues/list Change your membership to this group: https://groups.google.com/forum/#!forum/twitter-development-talk <https://groups.google.com/forum/#%21forum/twitter-development-talk>

--
Twitter developer documentation and resources: https://dev.twitter.com/doc
API updates via Twitter: https://twitter.com/twitterapi
Issues/Enhancements Tracker: https://code.google.com/p/twitter-api/issues/list
Change your membership to this group: 
https://groups.google.com/forum/#!forum/twitter-development-talk

Reply via email to