New oAuth Authorization screen is unusable on phone webbrowser control

[Bob12345]

Hi,
I've been using a WebBrowser control in my Window Phone application to
login into Twitter. Today I noticed that the login/authorization page
format had changed and it is now unusable in a web browser control
that my application displays. The text on the page is squeezed
together, and the page unscrollable. If I paste the URI into the
desktop browser it displays a full-sized desktop login screen listing
all of the app's capabilities. Is anybody else having this issue? Do
you know of a workaround for this problem?
Thanks!

-Bob

[Tom van der Woerdt]

I've heard this before.

It sounds like all UIWebView, WebBrowser and probably Android's WebView are blocked. This is definitely a good thing for security reasons.

The "workaround" I recommend: launch the actual browser, using a <yourapp>:// link (something like myapplication://tokenDone) as the return URL. This is a LOT safer for the users.

Tom

[Bob12345]

Thanks for your response Tom, but I am not sure whether this could be
done on a Windows Phone 7.
The only way to open a regular browser window from a Silverlight app
on the phone(that I know of) is to use
Microsoft.Phone.Tasks.WebBrowserTask and that just opens a webpage.

Would it be possible to bypass this new screen altogether if I were to
use xAuth?

Thanks!

-Bob

On Apr 30, 9:09 am, Tom van der Woerdt <i...@tvdw.eu> wrote:
> I've heard this before.
>
> It sounds like all UIWebView, WebBrowser and probably Android's WebView

> are blocked. This is definitely a *good* thing for security reasons.

[Tom van der Woerdt]

Yes. But I don't like xAuth :-) (Not that that should be relevant for you)

Anyway, the "Microsoft.Phone.Tasks.WebBrowserTask" is exactly what I
meant. Can you get WM7 to recognize a yourapp:// URL (custom scheme)?
You could have the OAuth login flow redirect back to that page with the
oauth code (not talking about oob authorization, but the normal flow)
and get the token that way. For the user, this would probably be the
best way.

Tom

[Matthieu GD]

On Apr 30, 12:09 pm, Tom van der Woerdt <i...@tvdw.eu> wrote:
> I've heard this before.
>
> It sounds like all UIWebView, WebBrowser and probably Android's WebView

> are blocked. This is definitely a *good* thing for security reasons.

They are not blocked, it's *only* a problem of layout.

> The "workaround" I recommend: launch the actual browser, using a
> <yourapp>:// link (something like myapplication://tokenDone) as the
> return URL. This is a LOT safer for the users.

I have the same problem, and I don't see why using a webcontrol is a
security problem. Since xauth is the exception, why twitter is making
the use of oauth so hard ?

Matthieu

[Dean Collins]

Why is it safer Tom?

 

Safer for who?

 

 

Cheers,

Dean

 

 

---

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

[Tom van der Woerdt]

In an embedded view, the developer can access the content of the website without the user knowing it (read passwords, usernames, etc). On most OSes (definitely iOS, WM7 and Android) this is not possible in the non-embedded (webbrowser) view.

Tom

[Tom van der Woerdt]

On 5/1/11 12:47 AM, Matthieu GD wrote:
> On Apr 30, 12:09 pm, Tom van der Woerdt<i...@tvdw.eu> wrote:
>> I've heard this before.
>>
>> It sounds like all UIWebView, WebBrowser and probably Android's WebView
>> are blocked. This is definitely a *good* thing for security reasons.
> They are not blocked, it's *only* a problem of layout.

Are you sure? A block of CSS saying "html { display: none; }" doesn't
look like a problem, more like a feature.

>> The "workaround" I recommend: launch the actual browser, using a
>> <yourapp>:// link (something like myapplication://tokenDone) as the
>> return URL. This is a LOT safer for the users.
> I have the same problem, and I don't see why using a webcontrol is a
> security problem. Since xauth is the exception, why twitter is making
> the use of oauth so hard ?

You should read the article at http://goo.gl/xI0PZ

Tom

[Matthieu GD]

Not sure if my previous message get trough.

ok now we know it's insecure. But why removing the page without notice
since it's not easy to deploy a new version of a native application?
We have lived with xAuth (and it's still used by some applications
like full-fledged clients) during several months until oauth was
ready.

Matthieu

[Rich]

Twitter what have you done, it takes WEEKS to get updates through
Apple's review process and now you break all apps that use oAuth
through embedded browser controls, and yet seriously how is it any
different to using xAuth.

Please restore this ASAP!

[Rich]

OK I spoke to soon :) It does still seem to be working on UIWebView,
not sure about other mobile web browsers.

I do like the look and feel of the new login pages

[Bob12345]

I figured out an easy workaround for WP7 WebBrowser:
1) Navigate to a local dummy page in your isolated storage before
going to the oAuth page -- somehow this fixes the scrolling
2) Set the width of the 'auth' div to the width of your screen by
invoking javascript on the browser-- this uncrowds the page.
Wasted 2 days on this nonsense :(

[Matthieu GD]

On May 1, 7:52 am, Bob12345 <yuz...@gmail.com> wrote:
> I figured out an easy workaround for WP7 WebBrowser:
> 1) Navigate to a local dummy page in your isolated storage before
> going to the oAuth page -- somehow this fixes the scrolling
> 2) Set the width of the 'auth' div to the width of your screen by
> invoking javascript on the browser-- this uncrowds the page.
> Wasted 2 days on this nonsense :(
>

Thanks Bob for the workaround, not easy to implement but still a
temporary solution. A better one would be that Twiter restores the
page so we could migrate our application.

Matthieu

[Matthieu GD]

and the doc page for OOB authentication is not available :
http://dev.twitter.com/pages/auth#oob

Amateur hour here we come .... I'm going to ask for a xauth exception

On May 1, 7:52 am, Bob12345 <yuz...@gmail.com> wrote:

[Ben Ward]

Hi Bob, Tom, and others,

On Apr 29, 2011, at 11:50 PM, Bob12345 wrote:

> I've been using a WebBrowser control in my Window Phone application to
> login into Twitter. Today I noticed that the login/authorization page
> format had changed and it is now unusable in a web browser control
> that my application displays. The text on the page is squeezed
> together, and the page unscrollable.

I've seen a couple of reports of this concerning rendering in the current browser on Windows Phone 7. This is obviously unintended and I'm working on a fix.

On Apr 30, 2011, at 9:09 AM, Tom van der Woerdt wrote:

> It sounds like all UIWebView, WebBrowser and probably Android's WebView are blocked. This is definitely a *good* thing for security reasons.
>

> The "workaround" I recommend: launch the actual browser, using a <yourapp>:// link (something like myapplication://tokenDone) as the return URL. This is a LOT safer for the users.

Although I'm personally a strong advocate of the protocol redirects, I can assure you that we have not actively blocked access to the OAuth screens in any context or browser with these updates.

If you're having trouble with the auth screen in a web view, I'm going to need more information from you because there's no debugging tool for a UIWebView in third party apps. If you can trap any rendering or script errors from a browser view control in your development environment, please send them to me and I'll use them to look for any problems. Email me directly if you prefer.

Thanks,

Ben
/ @benward
/ Twitter platform developer

[Matthieu GD]

this message don't indicate any security concerns:
http://groups.google.com/group/twitter-api-announce/browse_thread/thread/3aac43cb45873232

[Matthieu GD]

On Apr 30, 7:18 pm, Ben Ward <benw...@twitter.com> wrote:
> Hi Bob, Tom, and others,
>
> On Apr 29, 2011, at 11:50 PM, Bob12345 wrote:
>
> > I've been using a WebBrowser control in my Window Phone application to
> > login into Twitter. Today I noticed that the login/authorization page
> > format had changed and it is now unusable in a web browser control
> > that my application displays. The text on the page is squeezed
> > together, and the page unscrollable.
>
> I've seen a couple of reports of this concerning rendering in the current browser on Windows Phone 7. This is obviously unintended and I'm working on a fix.

Thanks Ben for your message.

Matthieu

[LoungeFlyZ]

Hi Ben,

Thanks for your reply about this issue. I am also seeing this in my
Windows Phone 7 application.

Something has changed in the last few days and now the page is
rendering a little "better" but scrolling/panning/zooming isnt working
& i cant enter text in the username or password fields.

Is there anything i can do to help diagnose this issue?

Thanks,

Chris.

On Apr 30, 4:18 pm, Ben Ward <benw...@twitter.com> wrote:
> Hi Bob, Tom, and others,
>
> On Apr 29, 2011, at 11:50 PM, Bob12345 wrote:
>
> > I've been using a WebBrowser control in my Window Phone application to

> >logininto Twitter. Today I noticed that thelogin/authorizationpage

[Matthieu GD]

On May 3, 8:00 pm, LoungeFlyZ <chrisfjohn...@gmail.com> wrote:
> Hi Ben,
>
> Thanks for your reply about this issue.  I am also seeing this in my
> Windows Phone 7 application.
>
> Something has changed in the last few days and now the page is
> rendering a little "better" but scrolling/panning/zooming isnt working
> & i cant enter text in the username or password fields.
>
> Is there anything i can do to help diagnose this issue?
>
> Thanks,
>
> Chris.

I have the same issue, I emailed to Ben a screenshot of the problem on
my applicaion,

Matthieu

[Ben Ward]

Hi Chris, Matthieu and any others running into this issue:

On May 3, 2011, at 5:00 PM, LoungeFlyZ wrote:

> Something has changed in the last few days and now the page is
> rendering a little "better" but scrolling/panning/zooming isnt working
> & i cant enter text in the username or password fields.
>
> Is there anything i can do to help diagnose this issue?

The update we put out this morning fixes the general rendering of the OAuth screen in WP7 (there's a couple more minor layout improvement tweaks coming as well, but the blocking problem is rectified.) It now works perfectly in Mobile IE on the phone, but for reasons which are inexplicable, loading the exact same page within a phone:WebBrowser control in an application suffers from cropped rendering and the no-scrolling behaviour described here.

Having spent a few hours in Visual Studio, and reproduced it, it appears you can work around the issue by setting IsScriptEnabled="False" on the control.

I'll continue to investigate what's causing the render bug, but the above fix should hopefully set everybody running again.

Thanks for your patience, and to Chris and Matthieu for corresponding with me on Twitter whilst debugging the issue.

Ben

[Matthieu GD]

Thanks Ben, I can confirm it works with IsScriptEnabled="False".

I re-enable it on my control after the rendering of the auth page
because my callback page is using a script to pass the token, but like
Ben mentionned on Twitter I could have also parsed the e.Source
parameter on the navigated event.

Matthieu

[LoungeFlyZ]

Thanks for your assistance Ben... much appreciated.


Would love to get to the bottom of why this is happening on the new
login page vs. the old one (the old one was fine).