#1

Did Twitter ban the Google Chrome extension URI chrome-extension:// pattern when setting the oauth_callback parameter during https://api.twitter.com/oauth/request_token portion of OAuth handshake?

Reason I ask is twitter used to return chrome-extension://* URIs as expected using oauth_callback. Now it seems twitter is returning about:blank with breaks the OAuth dance.

Issue isn’t with URL Encoding because http:// returns as expected. The issue is twitter is actively targeting chrome-extension:// and with it Google Chrome extensions.

The URI twitter-extension:// no longer returns either (used too in our Unit tests), but at least shows this message: “Redirecting you back to the application. This may take a few moments. If your browser doesn’t redirect you please click here to continue” with the expected URI linked to “click here to continue”. However, the chrome-extension://* URI specifically redirects to about:blank and breaks OAuth entirely which means twitter is targeting to break OAuth handshake for Google Chrome extensions specifically.

It make Hulk mad!

#2

What’s the full URL, including all protocol, host, and path elements that you’re sending to oauth_callback in this case?

There are some URL formats that Chrome accepts that aren’t necessarily 100% strictly valid.

#3

Hi Taylor - Here is the full oath_callback URL:
chrome-extension://iflibabkjodlnfjginiddgfmgdgjjgod/signin.html

I was expecting Twitter to redirect to whatever I pass to oath_callback as explained here:
https://dev.twitter.com/discussions/5749 - It used to work flawlessly. Something must have changed recently.

In your tests, when you pass my chrome-extension above to oath_callback, are you redirected to the passed in chrome-extension or are you redirected to about:blank?

#4

Elise, recent version of Chrome apparently have a change which causes this. See:

https://code.google.com/p/chromium/issues/detail?id=310870

1 Like
#5

OMG…Thank you so much @Wordie - It works!

Here’s what I did:

  • Updated manifest.json to include
    "web_accessible_resources": [
    “oath_callback.html”
    ]

Latest version of Chrome only allows an external resource (Twitter Redirect) to touch an in-app resource (Chrome App file) if said in-app resource is whitelisted in web_accessible_resources.

@episod Please forgive me directing fault at Twitter earlier. My tests pointed in that direction and I haven’t had much trust in @Twitter since The Great Developer Purge. http://www.youtube.com/watch?v=tCuUIkEtJjo

1 Like
#6

HOLY @^%@^(@#^&%@ DID I WASTE TIME ON THIS ONE!

Thanks :smiley:

1 Like
#7

Thank you for this information. You saved me lots of time :slight_smile:
I did forget to reload the extension after changing the manifest…
Out of curiosity, which twitter library are you using? I use https://github.com/jublonet/codebird-js/ for auth but https://github.com/ttezel/twit for using the streaming api.

-Deepak

1 Like
#8

Thank you so much! That chromium bug link really helped me fix the blank page issue.
I submitted a content bug report to Chrome (for https://developer.chrome.com/apps/tut_oauth) for this issue plus 4 others (see below if you’re interested - I found them when trying to get Twitter’s request_token step working).

Firstly, thanks for the tutorial on OAuth with chrome extensions in the above link!

Secondly, there are these content bugs in priority order:

  1. chrome_ex_oauth.html must be added to the web_accessible_resources array in the manifest.json; otherwise, the callback from OAuth results in “about: blank” page showing.

  2. Only certain OAuth providers allow anonymous consumer_key and consumer_secret; for example, Google. For all others (i.e., Twitter is one), you need to create/register an app entry using the OAuth provider’s dev website and use the key and secret they provide in the app settings.

  3. onload.js shouldn’t be included in the extension’s background page. It should only be included in the chrome_ex_oauth.html for doing the page redirection. The background page should just do “var oauth = ChromeExOAuth.initBackgroundPage” and “oauth.authorize” when needed (i.e., when the user interacts with the extension’s UI).

  4. Some OAuth providers don’t accept the oauth parameters as part of the URL - instead, they accept them in the “Authorization:” header (i.e., Twitter). To ensure this works, you need to change chrome_ex_oauth.js so that when it calls sendRequest as part of an OAuth dance step that it sends the result.header property appropriately after calling “sign.”

  5. To generate a valid oauth_signature for POST requests, you need to ensure that in chrome_ex_oauth.js the action property is passed in (value is “POST”) when calling “sign.”