Re: [twitter-dev] Re: Visual refresh of the OAuth screens

[Ben Ward]

Clive,

Congratulations on the new release—it works great! And thank you so much for 
writing up your implementation in this detail. I'm glad it's come together and 
I'm glad you've been able to use the callbacks mechanism to improve the flow. 
Hopefully we're at a point in mobile platform development now where OOBs become 
a real rarity for users, and we can use callbacks for better app integration in 
all sorts of ways.

Also, thanks for your patience and enthusiastic working with me to get the 
problem diagnosed. It was incredibly helpful to get your feedback and 
assistance, and took a bit of stress out of that weekend! I really appreciate 
it.

On May 25, 2011, at 3:53 AM, bitrace wrote:

> The main reason we opted for the embedded UIWebView was because our
> TweetIgnite App allows the user to add multiple accounts, and we found
> that the cookies twitter sets after adding the first account makes it
> difficult to add a second, as the first account is still logged in and
> there is currently no option on the new screens to log in as different
> user.


For what it's worth, the `force_login` parameter which we'll release soon on 
the authorize flow is a solution to this problem. (As mentioned in some of the 
other threads.)

Regards,

Ben
--
@benward
Platform Developer, Twitter



> Thankfully, we have now fixed the issue that caused the new OAuth
> templates to break our iPhone App and an update is now live on the App
> store.
> 
> I thought I'd share our findings as they may prove useful to anyone
> else who has experienced problems or who is currently migrating from
> xAuth to oAuth in order to meet the new Direct Message access
> requirement.
> 
> The problem we experienced following the rollout of the new OAuth
> screens occurred when a user tried to add their twitter account using
> the in-App UIWebView.  This rendered blank instead of prompting the
> user to enter their username and password.
> 
> We traced the problem to how our OAuth helper was interacting with the
> UIWebView.  In our initial implementation the OAuth helper code was
> both creating and issuing the OAuth requests, and passing html
> responses back to the UIWebView, as text to be rendered.  Although
> this worked fine with the old style screens, changes to twitter's anti-
> click jacking implementation in the new templates resulted in the
> UIWebView being rendered blank.
> 
> The solution was simply to get the OAuthHelper code to create the
> OAuth signed requests, and pass the NSURLRequest directly to the
> UIWebview for loading directly.
> 
> Our initial OAuth implementation made use of a PIN based out-of-band
> flow, however, as part of our redesign we found that we were able to
> move over to an OAuth callback implementation, which provides a much
> slicker user experience.
> 
> To do this:
> 1. Login in to twitter's developer page and change your applications
> settings to browser and register a nominal callback URL, say your
> twitter page (this callback URL is not actually used).
> 
> 2. Back in your App, define a protocol specific callback url e.g.
> yourappname://oauth/callback ours was tweetignite://oauth/callback
> 
> 3. Define the oauth_callback as your protocol specific url in the
> RequestToken request. [Take care not to over URL encode the callback
> URL in the header - a big time waster! 8-( ]
> e.g.
> 
> OAuth oauth_callback="tweetignite%3A%2F%2Foauth%2Fcallback",
> oauth_consumer_key="x", oauth_nonce="C8612F28-
> D307-446B-88E6-4804282CCB4F",
> oauth_signature="xOKzHrQk4HwhOzdGEdWalVPxF6E%3D",
> oauth_signature_method="HMAC-SHA1", oauth_timestamp="1306318989",
> oauth_version="1.0"
> 
> 4. Append the protocol specific url as an oauth_callback parameter in
> the Authorize URL e.g.
> 
>   
> https://api.twitter.com/oauth/authorize?oauth_callback=tweetignite%3A%2F%2Foauth%2Fcallback&oauth_token=xxx
> 
> Once you have implemented this in your OAuth code there are two
> choices for implementing the webview.  You can either spawn the
> request externally in mobile safari, and add your protocol specific
> callback URL to your Info.plist, which will cause your app to re-
> launch when it gets the callback.
> 
> To get the tokens add
> - (BOOL)application:(UIApplication *)application handleOpenURL:(NSURL
> *)url to your AppDelegate and grab the tokens from the oauth_verifier
> to complete the flow.
> 
> Or alternatively, as in our case continue to use the embedded
> UIWebview, which actually receives the callback URL directly in
> -(BOOL)webView:(UIWebView *)webView shouldStartLoadWithRequest:
> (NSURLRequest *)request navigationType:
> (UIWebViewNavigationType)navigationType
> here you can grab the tokens from the oauth_verifier to complete the
> flow.
> 
> With the embedded UIWebView approach you need to programmatically
> clear any cookies twitter sets, before launching a new UIWebView so a
> new account can be added.
> 
> Thanks to Ben at twitter for his help with this, and hope

[twitter-dev] Re: Visual refresh of the OAuth screens

[bitrace]

Thankfully, we have now fixed the issue that caused the new OAuth
templates to break our iPhone App and an update is now live on the App
store.

I thought I'd share our findings as they may prove useful to anyone
else who has experienced problems or who is currently migrating from
xAuth to oAuth in order to meet the new Direct Message access
requirement.

The problem we experienced following the rollout of the new OAuth
screens occurred when a user tried to add their twitter account using
the in-App UIWebView.  This rendered blank instead of prompting the
user to enter their username and password.

We traced the problem to how our OAuth helper was interacting with the
UIWebView.  In our initial implementation the OAuth helper code was
both creating and issuing the OAuth requests, and passing html
responses back to the UIWebView, as text to be rendered.  Although
this worked fine with the old style screens, changes to twitter's anti-
click jacking implementation in the new templates resulted in the
UIWebView being rendered blank.

The solution was simply to get the OAuthHelper code to create the
OAuth signed requests, and pass the NSURLRequest directly to the
UIWebview for loading directly.

Our initial OAuth implementation made use of a PIN based out-of-band
flow, however, as part of our redesign we found that we were able to
move over to an OAuth callback implementation, which provides a much
slicker user experience.

To do this:
1. Login in to twitter's developer page and change your applications
settings to browser and register a nominal callback URL, say your
twitter page (this callback URL is not actually used).

2. Back in your App, define a protocol specific callback url e.g.
yourappname://oauth/callback ours was tweetignite://oauth/callback

3. Define the oauth_callback as your protocol specific url in the
RequestToken request. [Take care not to over URL encode the callback
URL in the header - a big time waster! 8-( ]
e.g.

OAuth oauth_callback="tweetignite%3A%2F%2Foauth%2Fcallback",
oauth_consumer_key="x", oauth_nonce="C8612F28-
D307-446B-88E6-4804282CCB4F",
oauth_signature="xOKzHrQk4HwhOzdGEdWalVPxF6E%3D",
oauth_signature_method="HMAC-SHA1", oauth_timestamp="1306318989",
oauth_version="1.0"

4. Append the protocol specific url as an oauth_callback parameter in
the Authorize URL e.g.


https://api.twitter.com/oauth/authorize?oauth_callback=tweetignite%3A%2F%2Foauth%2Fcallback&oauth_token=xxx

Once you have implemented this in your OAuth code there are two
choices for implementing the webview.  You can either spawn the
request externally in mobile safari, and add your protocol specific
callback URL to your Info.plist, which will cause your app to re-
launch when it gets the callback.

To get the tokens add
- (BOOL)application:(UIApplication *)application handleOpenURL:(NSURL
*)url to your AppDelegate and grab the tokens from the oauth_verifier
to complete the flow.

Or alternatively, as in our case continue to use the embedded
UIWebview, which actually receives the callback URL directly in
 -(BOOL)webView:(UIWebView *)webView shouldStartLoadWithRequest:
(NSURLRequest *)request navigationType:
(UIWebViewNavigationType)navigationType
here you can grab the tokens from the oauth_verifier to complete the
flow.

The main reason we opted for the embedded UIWebView was because our
TweetIgnite App allows the user to add multiple accounts, and we found
that the cookies twitter sets after adding the first account makes it
difficult to add a second, as the first account is still logged in and
there is currently no option on the new screens to log in as different
user.

With the embedded UIWebView approach you need to programmatically
clear any cookies twitter sets, before launching a new UIWebView so a
new account can be added.

Thanks to Ben at twitter for his help with this, and hopefully this
will be useful to others migrating from xAuth to a full OAuth flow.

Best regards,
Clive

@clivetwist
@tweetigniteapp
[ http://itunes.apple.com/app/tweetignite/id411873391?mt=8 ]

On Apr 29, 6:36 pm, bitrace  wrote:
> Hi Matt,
>
> While we welcome improvements to the OAuth screens making it clearer
> what an App can or can not do on a users behalf, the changes that you
> have rolled out have broken our iPhone App TweetIgnite currently live
> in the App store.  [http://itunes.apple.com/app/tweetignite/id411873391?mt=8
> ].  Our App uses an OAuth PIN/out-of-band flow.
>
> As far as I am aware we formatting our OAuth requests correctly (it
> all worked before) and indeed we do receive back the html for the
> Authorisation page, however it is being rendered in the UIWebView as
> blank!
>
> Some investigation indicates that the style sheet may contain an
> incorrectly formed link:
>
>  
>
> should this not be:
>
>  
>
> Also the html returned from our OAuth request contains:
>
>  
>       html { display:none; }
>     
>
> which is clearly why the page is being rendered blank.
>
> Not 

[twitter-dev] Re: Visual refresh of the OAuth screens

[stressfree]

Matt, what happened to the mobile version of these new OAuth screens?
Is there no mobile version at all?

There used to be automatic mobile detection (based on user agent) and
rendering of mobile friendly screens: 
http://mashable.com/2010/02/03/twitter-oauth-mobile/

This all stopped working when you rolled out the new OAuth screens.
There seems to be only one version. The new screens work OK on most
touch phones, but are unusable in feature phones and most non-touch
smartphones with smaller displays:
* The new screens are actually too heavy for a lot of basic mobile
browsers and end up crashing them (for starters, most of our Nokia
phones crash)
* Other phones simply can't scroll or click on the buttons as the
browser gets incredibly slow or freezes (older Samsung, LG phones)
* On the phones where the browser doesn't crash or freeze, the user
can't even see most of the text/info about the app (which was the
whole point of the new screens)

If there a way to get a mobile version of this page? Any workaround?
Any way to get the old mobile screens at least temporarily? Or can you
_really_ simplify the OAuth screens so that they work with very basic
mobile browsers. We have a lot of angry users that paid for one of our
twitter apps and now can't sign-in because of your new OAuth screens.

Not everyone is using iPhone/Android in this world. Please tell us
that there is a way for feature phones to use OAuth.

-- 
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

Re: [twitter-dev] Re: Visual refresh of the OAuth screens

[Shannon Whitley]

I just noticed that the oAuth window appears to be resetting the height so
that the entire page is visible (no scrolling).  For Firefox and Chrome
that's fixed the issue.  Thank you!

However, there is still a problem with IE.  It is worse now.  The user no
longer sees the scrollbar and cannot login at all.




On Fri, Apr 29, 2011 at 9:21 PM, Stefan  wrote:

> Hi Matt,
>
> while being an improvement over the old oauth form, this form still
> does not tell the user all she needs to know. In particular, it hides
> the fact that the app will have almost total control over their
> twitter account.
>
> In my experience, most users are totally unaware of this fact. Of
> course, from a developer's point of view everything that will stop
> user's from authorizing their apps will always be greeted with
> skepticism. However, I hope that Twitter will sooner or later inform
> users that authorizing an app with read/write access can be
> potentially very dangerous -- and doing so in the oauth form would be
> the best place to do so.
>
> Or we could just hope that we will never see any malicious Twitter
> apps.
>
> Best regards,
> Stefan
>
> --
> Twitter developer documentation and resources: http://dev.twitter.com/doc
> API updates via Twitter: http://twitter.com/twitterapi
> Issues/Enhancements Tracker:
> http://code.google.com/p/twitter-api/issues/list
> Change your membership to this group:
> http://groups.google.com/group/twitter-development-talk
>

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

[twitter-dev] Re: Visual refresh of the OAuth screens

[Stefan]

Hi Matt,

while being an improvement over the old oauth form, this form still
does not tell the user all she needs to know. In particular, it hides
the fact that the app will have almost total control over their
twitter account.

In my experience, most users are totally unaware of this fact. Of
course, from a developer's point of view everything that will stop
user's from authorizing their apps will always be greeted with
skepticism. However, I hope that Twitter will sooner or later inform
users that authorizing an app with read/write access can be
potentially very dangerous -- and doing so in the oauth form would be
the best place to do so.

Or we could just hope that we will never see any malicious Twitter
apps.

Best regards,
Stefan

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

Re: [twitter-dev] Re: Visual refresh of the OAuth screens

[Jeremy Dunck]

On Fri, Apr 29, 2011 at 10:36 AM, bitrace  wrote:
...
> Some investigation indicates that the style sheet may contain an
> incorrectly formed link:
>
>  

Hmm, //ajax is a legitimate link, it's called a protocol-relative
link.  Can you make a minimal test case for UIWebView to determine
whether they work in general?Maybe just have a link to the same
image, one with protocol-relative, and one with a full URL?

...

abs: http://example.com/image.jpg";>
rel: 

...
?

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

[twitter-dev] Re: Visual refresh of the OAuth screens

[Fishst1k]

Has anyone else noticed the javascript error in the twf.bundle.js
file?

provide(">tfw_bundle_evaled");

Thanks,
Ben

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

[twitter-dev] Re: Visual refresh of the OAuth screens

[Tobias C. Jensen]

Looking good!

Just a heads up that on Safari on a Mac you have to press enter twice
to submit the "username and password" form.
Just like with the old oAuth Screen. =)

On 29 Apr., 19:36, bitrace  wrote:
> Hi Matt,
>
> While we welcome improvements to the OAuth screens making it clearer
> what an App can or can not do on a users behalf, the changes that you
> have rolled out have broken our iPhone App TweetIgnite currently live
> in the App store.  [http://itunes.apple.com/app/tweetignite/id411873391?mt=8
> ].  Our App uses an OAuth PIN/out-of-band flow.
>
> As far as I am aware we formatting our OAuth requests correctly (it
> all worked before) and indeed we do receive back the html for the
> Authorisation page, however it is being rendered in the UIWebView as
> blank!
>
> Some investigation indicates that the style sheet may contain an
> incorrectly formed link:
>
>  
>
> should this not be:
>
>  
>
> Also the html returned from our OAuth request contains:
>
>  
>       html { display:none; }
>     
>
> which is clearly why the page is being rendered blank.
>
> Not sure if this is due to how you now handle certain user-agent
> headers? The user-agent presented by our App is TweetIgnite/1.0.3
> (iPhone; iPhone OS 4.3).
>
> I would be grateful for some help to resolve this?  It would also be
> good to get advanced warning of future changes, and even have the
> ability to test against them before they go live.
>
> Best regards,
> Clive Twist
> @clivetwist
>
> On Apr 28, 10:02 pm, Matt Harris  wrote:
>
>
>
> > Hey Developers,
>
> > Some of you may have noticed already that earlier today we deployed a
> > redesign of the OAuth screens.
>
> > We know both you and your users have been asking for better clarity about
> > what an application can see and do with an account and these screens are a
> > step towards doing that.
>
> > One of the areas we wanted to improve is showing the details of your
> > application. If you visit the new screens you will see we've separated your
> > application details from the permissions that are being requested. We did
> > this to help users see that it is your application, not Twitter's. Remember
> > you can update your application details at anytime 
> > onhttp://dev.twitter.com/apps.
>
> > Mobile and international support has also been improved and we now use the
> > same rendering templates as those created for Web Intents. This ensures the
> > design matches the rest of #newtwitter and, more importantly, works
> > cross-browser, cross-platform, and multilingual.
>
> > We hope you find the new designs more welcoming and friendly. Let us know
> > what you think.
>
> > Best,
> > @themattharris
> > Developer Advocate, Twitterhttp://twitter.com/themattharris

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

[twitter-dev] Re: Visual refresh of the OAuth screens

[bitrace]

Hi Matt,

While we welcome improvements to the OAuth screens making it clearer
what an App can or can not do on a users behalf, the changes that you
have rolled out have broken our iPhone App TweetIgnite currently live
in the App store.  [ http://itunes.apple.com/app/tweetignite/id411873391?mt=8
].  Our App uses an OAuth PIN/out-of-band flow.

As far as I am aware we formatting our OAuth requests correctly (it
all worked before) and indeed we do receive back the html for the
Authorisation page, however it is being rendered in the UIWebView as
blank!

Some investigation indicates that the style sheet may contain an
incorrectly formed link:

 

should this not be:

 

Also the html returned from our OAuth request contains:

 
  html { display:none; }


which is clearly why the page is being rendered blank.

Not sure if this is due to how you now handle certain user-agent
headers? The user-agent presented by our App is TweetIgnite/1.0.3
(iPhone; iPhone OS 4.3).

I would be grateful for some help to resolve this?  It would also be
good to get advanced warning of future changes, and even have the
ability to test against them before they go live.

Best regards,
Clive Twist
@clivetwist



On Apr 28, 10:02 pm, Matt Harris  wrote:
> Hey Developers,
>
> Some of you may have noticed already that earlier today we deployed a
> redesign of the OAuth screens.
>
> We know both you and your users have been asking for better clarity about
> what an application can see and do with an account and these screens are a
> step towards doing that.
>
> One of the areas we wanted to improve is showing the details of your
> application. If you visit the new screens you will see we've separated your
> application details from the permissions that are being requested. We did
> this to help users see that it is your application, not Twitter's. Remember
> you can update your application details at anytime 
> onhttp://dev.twitter.com/apps.
>
> Mobile and international support has also been improved and we now use the
> same rendering templates as those created for Web Intents. This ensures the
> design matches the rest of #newtwitter and, more importantly, works
> cross-browser, cross-platform, and multilingual.
>
> We hope you find the new designs more welcoming and friendly. Let us know
> what you think.
>
> Best,
> @themattharris
> Developer Advocate, Twitterhttp://twitter.com/themattharris

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

[twitter-dev] Re: Visual refresh of the OAuth screens

[CrazyRobot]

Am I the only one thinking that the bottom part of the page is totally
misleading?
It makes you think that application makers can choose to ask for your
password and the current one just didn't.

On Apr 29, 12:57 am, Abraham Williams <4bra...@gmail.com> wrote:
> Here is a screenshoot of the new page.
>
> https://picasaweb.google.com/4braham/Screenshots#5600743120809142002
>
> Note that app descriptions are now shown to users incase you were lazy (like
> me) and didn't include a real description.
>
> Abraham
> -
> Abraham Williams | InboxQ  | abrah.am
> @abraham  | github.com/abraham | blog.abrah.am
> This email is: [ ] shareable [x] ask first [ ] private.
>
> On Thu, Apr 28, 2011 at 14:02, Matt Harris wrote:
>
>
>
>
>
>
>
> > Hey Developers,
>
> > Some of you may have noticed already that earlier today we deployed a
> > redesign of the OAuth screens.
>
> > We know both you and your users have been asking for better clarity about
> > what an application can see and do with an account and these screens are a
> > step towards doing that.
>
> > One of the areas we wanted to improve is showing the details of your
> > application. If you visit the new screens you will see we've separated your
> > application details from the permissions that are being requested. We did
> > this to help users see that it is your application, not Twitter's. Remember
> > you can update your application details at anytime on
> >http://dev.twitter.com/apps.
>
> > Mobile and international support has also been improved and we now use the
> > same rendering templates as those created for Web Intents. This ensures the
> > design matches the rest of #newtwitter and, more importantly, works
> > cross-browser, cross-platform, and multilingual.
>
> > We hope you find the new designs more welcoming and friendly. Let us know
> > what you think.
>
> > Best,
> > @themattharris
> > Developer Advocate, Twitter
> >http://twitter.com/themattharris
>
> > --
> > Twitter API documentation and resources:http://dev.twitter.com/doc
> > API updates via Twitter:http://twitter.com/twitterapi
> > Change your membership to this group:
> >http://groups.google.com/group/twitter-api-announce?hl=en

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

[twitter-dev] Re: Visual refresh of the OAuth screens

[Shannon Whitley]

Matt,

Thanks for the reply.  I'm referring to a popup browser window that
displays the full url.  The technique is not designed to mask the
oAuth process, it's designed to improve the experience for the user.
Devs have been using this technique since Twitter released oAuth.

The popup allows the user to remain on the current web page so he or
she isn't jarred through multiple screen changes during a login.  The
Sign in With Twitter button on my blog serves as an example -
http://is.gd/qlpZ4L



On Apr 28, 3:31 pm, Matt Harris  wrote:
> @Shannon: thanks for the feedback on this. The new screens are fluid in size
> so wrap to the available space. Hosting in a local iframe isn't something
> we've encouraged in the past. We prefer the user to be taken to the
> authenticate or authorize page in a tab/new window that they can see the URL
> of. This is a good area for us to write some guidance for so thanks for
> raising this.
>
> @Orian: great feedback and definitely something for us to take on board -
> thanks. This is a first release of these pages to get a feel for if they are
> going in the right direction. We tried to select a number of phrases that
> explain the access that's being granted to an application but that are also
> easy to understand. I think there will always be some that don't make it,
> but there are others, like the ones you raise, which would help aid
> transparency more.
>
> @themattharris
>
> On Thu, Apr 28, 2011 at 3:00 PM, Orian Marx (@orian) 
> wrote:
>
>
>
>
>
>
>
> > I think it's good to be giving users more information on what they are
> > granting access to, but by leaving out a number of things there are
> > misleading implications. In particular, this list does not mention
> > that users will be granting access to all their private DMs. I also
> > find it interesting the list mentions the ability to follow new
> > people, but not to unfollow existing people.
>
> > Obviously it's been to everyone's benefit who has built apps that rely
> > on OAuth up to this point that there has been specific mentioning of
> > access to DMs as this would likely turn off a lot of people from
> > granting access to experimental apps. The reality is that the OAuth
> > system needs finer-grained controls. It would be good to hear if there
> > has been any new thought on this from Twitter engineering.
>
> > Otherwise, I like the new page :)
>
> > @orian
>
> > On Apr 28, 5:02 pm, Matt Harris  wrote:
> > > Hey Developers,
>
> > > Some of you may have noticed already that earlier today we deployed a
> > > redesign of the OAuth screens.
>
> > > We know both you and your users have been asking for better clarity about
> > > what an application can see and do with an account and these screens are
> > a
> > > step towards doing that.
>
> > > One of the areas we wanted to improve is showing the details of your
> > > application. If you visit the new screens you will see we've separated
> > your
> > > application details from the permissions that are being requested. We did
> > > this to help users see that it is your application, not Twitter's.
> > Remember
> > > you can update your application details at anytime onhttp://
> > dev.twitter.com/apps.
>
> > > Mobile and international support has also been improved and we now use
> > the
> > > same rendering templates as those created for Web Intents. This ensures
> > the
> > > design matches the rest of #newtwitter and, more importantly, works
> > > cross-browser, cross-platform, and multilingual.
>
> > > We hope you find the new designs more welcoming and friendly. Let us know
> > > what you think.
>
> > > Best,
> > > @themattharris
> > > Developer Advocate, Twitterhttp://twitter.com/themattharris
>
> > --
> > Twitter developer documentation and resources:http://dev.twitter.com/doc
> > API updates via Twitter:http://twitter.com/twitterapi
> > Issues/Enhancements Tracker:
> >http://code.google.com/p/twitter-api/issues/list
> > Change your membership to this group:
> >http://groups.google.com/group/twitter-development-talk

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

Re: [twitter-dev] Re: Visual refresh of the OAuth screens

[Matt Harris]

@Shannon: thanks for the feedback on this. The new screens are fluid in size
so wrap to the available space. Hosting in a local iframe isn't something
we've encouraged in the past. We prefer the user to be taken to the
authenticate or authorize page in a tab/new window that they can see the URL
of. This is a good area for us to write some guidance for so thanks for
raising this.

@Orian: great feedback and definitely something for us to take on board -
thanks. This is a first release of these pages to get a feel for if they are
going in the right direction. We tried to select a number of phrases that
explain the access that's being granted to an application but that are also
easy to understand. I think there will always be some that don't make it,
but there are others, like the ones you raise, which would help aid
transparency more.

@themattharris

On Thu, Apr 28, 2011 at 3:00 PM, Orian Marx (@orian) wrote:

> I think it's good to be giving users more information on what they are
> granting access to, but by leaving out a number of things there are
> misleading implications. In particular, this list does not mention
> that users will be granting access to all their private DMs. I also
> find it interesting the list mentions the ability to follow new
> people, but not to unfollow existing people.
>
> Obviously it's been to everyone's benefit who has built apps that rely
> on OAuth up to this point that there has been specific mentioning of
> access to DMs as this would likely turn off a lot of people from
> granting access to experimental apps. The reality is that the OAuth
> system needs finer-grained controls. It would be good to hear if there
> has been any new thought on this from Twitter engineering.
>
> Otherwise, I like the new page :)
>
> @orian
>
> On Apr 28, 5:02 pm, Matt Harris  wrote:
> > Hey Developers,
> >
> > Some of you may have noticed already that earlier today we deployed a
> > redesign of the OAuth screens.
> >
> > We know both you and your users have been asking for better clarity about
> > what an application can see and do with an account and these screens are
> a
> > step towards doing that.
> >
> > One of the areas we wanted to improve is showing the details of your
> > application. If you visit the new screens you will see we've separated
> your
> > application details from the permissions that are being requested. We did
> > this to help users see that it is your application, not Twitter's.
> Remember
> > you can update your application details at anytime onhttp://
> dev.twitter.com/apps.
> >
> > Mobile and international support has also been improved and we now use
> the
> > same rendering templates as those created for Web Intents. This ensures
> the
> > design matches the rest of #newtwitter and, more importantly, works
> > cross-browser, cross-platform, and multilingual.
> >
> > We hope you find the new designs more welcoming and friendly. Let us know
> > what you think.
> >
> > Best,
> > @themattharris
> > Developer Advocate, Twitterhttp://twitter.com/themattharris
>
> --
> Twitter developer documentation and resources: http://dev.twitter.com/doc
> API updates via Twitter: http://twitter.com/twitterapi
> Issues/Enhancements Tracker:
> http://code.google.com/p/twitter-api/issues/list
> Change your membership to this group:
> http://groups.google.com/group/twitter-development-talk
>

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

[twitter-dev] Re: Visual refresh of the OAuth screens

[Orian Marx (@orian)]

I think it's good to be giving users more information on what they are
granting access to, but by leaving out a number of things there are
misleading implications. In particular, this list does not mention
that users will be granting access to all their private DMs. I also
find it interesting the list mentions the ability to follow new
people, but not to unfollow existing people.

Obviously it's been to everyone's benefit who has built apps that rely
on OAuth up to this point that there has been specific mentioning of
access to DMs as this would likely turn off a lot of people from
granting access to experimental apps. The reality is that the OAuth
system needs finer-grained controls. It would be good to hear if there
has been any new thought on this from Twitter engineering.

Otherwise, I like the new page :)

@orian

On Apr 28, 5:02 pm, Matt Harris  wrote:
> Hey Developers,
>
> Some of you may have noticed already that earlier today we deployed a
> redesign of the OAuth screens.
>
> We know both you and your users have been asking for better clarity about
> what an application can see and do with an account and these screens are a
> step towards doing that.
>
> One of the areas we wanted to improve is showing the details of your
> application. If you visit the new screens you will see we've separated your
> application details from the permissions that are being requested. We did
> this to help users see that it is your application, not Twitter's. Remember
> you can update your application details at anytime 
> onhttp://dev.twitter.com/apps.
>
> Mobile and international support has also been improved and we now use the
> same rendering templates as those created for Web Intents. This ensures the
> design matches the rest of #newtwitter and, more importantly, works
> cross-browser, cross-platform, and multilingual.
>
> We hope you find the new designs more welcoming and friendly. Let us know
> what you think.
>
> Best,
> @themattharris
> Developer Advocate, Twitterhttp://twitter.com/themattharris

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

[twitter-dev] Re: Visual refresh of the OAuth screens

[Shannon Whitley]

Hi Matt,

This is a big change and it negatively impacts many web applications
that popup a browser window to display the oAuth screen.  The popup
windows were sized for the old content, and the new content will force
the user to scroll.  It's not a great experience.

I wish there would have been a feedback phase before this change was
pushed through.  Can we work together to create another format that
will fit within these windows?




On Apr 28, 2:02 pm, Matt Harris  wrote:
> Hey Developers,
>
> Some of you may have noticed already that earlier today we deployed a
> redesign of the OAuth screens.
>
> We know both you and your users have been asking for better clarity about
> what an application can see and do with an account and these screens are a
> step towards doing that.
>
> One of the areas we wanted to improve is showing the details of your
> application. If you visit the new screens you will see we've separated your
> application details from the permissions that are being requested. We did
> this to help users see that it is your application, not Twitter's. Remember
> you can update your application details at anytime 
> onhttp://dev.twitter.com/apps.
>
> Mobile and international support has also been improved and we now use the
> same rendering templates as those created for Web Intents. This ensures the
> design matches the rest of #newtwitter and, more importantly, works
> cross-browser, cross-platform, and multilingual.
>
> We hope you find the new designs more welcoming and friendly. Let us know
> what you think.
>
> Best,
> @themattharris
> Developer Advocate, Twitterhttp://twitter.com/themattharris

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