Visual refresh of the OAuth screens
Matt Harris
http://twitter.com/themattharris
Shannon Whitley
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?
Abraham Williams
Abraham
-------------
Abraham Williams | InboxQ | abrah.am
This email is: [ ] shareable [x] ask first [ ] private.
--
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
Orian Marx (@orian)
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
Matt Harris
--
Twitter developer documentation and resources: http://dev.twitter.com/doc
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
Shannon Whitley
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
CrazyRobot
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 <https://twitter.com/abraham> | github.com/abraham | blog.abrah.am
>
Andrew W. Donoho
On Apr 28, 2011, at 16:02 , Matt Harris wrote:
> We hope you find the new designs more welcoming and friendly. Let us know what you think.
Matt,
I'm speaking as a user but I would like for the user to be able to separately deny write access to my account. I don't frankly care if the developer "requires" it. I think most developers just ask for the moon and get it. Only Twitter can give the user the ability to deny impersonation access on a per application basis. If the app cannot just run with just read access, then the user should really know why. In my experience, most developers just use write access as a mechanism to spread their brand.
Anon,
Andrew
____________________________________
Andrew W. Donoho
Donoho Design Group, L.L.C.
a...@DDG.com, +1 (512) 750-7596, twitter.com/adonoho
"To take no detours from the high road of reason and social responsibility."
-- Marcus Aurelius
bitrace
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:
<link rel="stylesheet" type="text/css" href="//ajax.googleapis.com/
ajax/libs/yui/3.3.0/build/cssfonts/fonts-min.css">
should this not be:
<link rel="stylesheet" type="text/css" href="http://
ajax.googleapis.com/ajax/libs/yui/3.3.0/build/cssfonts/fonts-min.css">
Also the html returned from our OAuth request contains:
<style type="text/css">
html { display:none; }
</style>
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
Tobias C. Jensen
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. =)
Fishst1k
file?
provide(">tfw_bundle_evaled");
Thanks,
Ben
Jeremy Dunck
<andrew...@gmail.com> wrote:
> Matt,
>
> I'm speaking as a user but I would like for the user to be able to separately deny write access to my account. I don't frankly care if the developer "requires" it. I think most developers just ask for the moon and get it. Only Twitter can give the user the ability to deny impersonation access on a per application basis. If the app cannot just run with just read access, then the user should really know why. In my experience, most developers just use write access as a mechanism to spread their brand.
>
There are a few problems here --
1) Some applications legitimately need write access to do their work -
for example, an auto-unfollower. You seem to discount this example.
2) It is basically not possible to upgrade privileges (with the user's
permissions) later, so if an application author thinks they may ever
need the privileges, they will ask for write, even if they don't
currently need it.
3) You seem to feel that the app author is working against you -- if
you really feel that's the case, you, the user, are ultimately in
control -- you choose whether to allow the application to have access.
Twitter can not reasonably be the arbiter of which apps have
legitimate write access -- it depends on the utility to you, the user,
and so is a personal decision. (There are examples where apps are
malicious and misleading, but that is a very small minority of all
applications.)
Jeremy Dunck
...
> Some investigation indicates that the style sheet may contain an
> incorrectly formed link:
>
> <link rel="stylesheet" type="text/css" href="//ajax.googleapis.com/
> ajax/libs/yui/3.3.0/build/cssfonts/fonts-min.css">
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?
...
<p>
abs: <img src="http://example.com/image.jpg"><br/>
rel: <img src="//example.com/image.jpg">
</p>
...
?
Andrew W. Donoho
On Apr 29, 2011, at 15:56 , Jeremy Dunck wrote:
> On Fri, Apr 29, 2011 at 8:55 AM, Andrew W. Donoho
> <andrew...@gmail.com> wrote:
>> Matt,
>>
>> I'm speaking as a user but I would like for the user to be able to separately deny write access to my account. I don't frankly care if the developer "requires" it. I think most developers just ask for the moon and get it. Only Twitter can give the user the ability to deny impersonation access on a per application basis. If the app cannot just run with just read access, then the user should really know why. In my experience, most developers just use write access as a mechanism to spread their brand.
>>
>
> There are a few problems here --
>
> 1) Some applications legitimately need write access to do their work -
> for example, an auto-unfollower. You seem to discount this example.
Jeremy,
Bear in mind that I wrote my note from the perspective of the user, not the developer. As we've recently seen, developers, at minimum, can get hacked and lose control over all of these credentials. There are other reasons for a user to want to limit that access and Twitter doesn't actually give the user the ability to veto write access.
If an app must have write access, they should tell me why. Most apps I've used don't.
> 2) It is basically not possible to upgrade privileges (with the user's
> permissions) later, so if an application author thinks they may ever
> need the privileges, they will ask for write, even if they don't
> currently need it.
What exists now is not carved in stone. Witness that Twitter just changed the login screens and can, obviously, make other changes in the future.
You also make my point that app authors ask for privileges they may not currently need. That is not a good policy for users. Twitter's permissions model though encourages developers to ask for more permissions than they need. Twitter should, IMO, change this to protect users. (Yes, Twitter does currently try to protect their users. This is another method they could use.)
> 3) You seem to feel that the app author is working against you -- if
> you really feel that's the case, you, the user, are ultimately in
> control -- you choose whether to allow the application to have access.
Actually, the app author is frequently operating at cross purposes to the user. They see the user as a product to monetize. Now you may not view users that way, that doesn't mean every developer behaves as you do. Twitter does ban, as I understand it, many apps every day due to spamming.
> Twitter can not reasonably be the arbiter of which apps have
> legitimate write access -- it depends on the utility to you, the user,
> and so is a personal decision. (There are examples where apps are
> malicious and misleading, but that is a very small minority of all
> applications.)
You further make my point. I, the user, only get to make the permissions decision when the app is first engaged. Because of this, there is no trial opportunity before I give the app full authority to act on my behalf. I cannot even find out if an app is valuable before giving it full authority to act on my behalf. This is not good for users and is a capability which appears to have been abused by app developers.
Anon,
Andrew
____________________________________
Andrew W. Donoho
Donoho Design Group, L.L.C.
a...@DDG.com, +1 (512) 750-7596, twitter.com/adonoho
"We did not come to fear the future.
We came here to shape it."
-- President Barack Obama, Sept. 2009
Stefan
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
Shannon Whitley
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
stressfree
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.
bitrace
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="xxxxxxxxxxxxx", 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=xxxxxxxxxxxxxxxxxxxxxxx
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 ]
Ben Ward
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
> --
> 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