We are aware of the issue with the badge emails resending to everyone, we apologise for the inconvenience - learn more here.
Forum Discussion
Login to Dropbox from browser extension on Firefox
Turns out the browser extensions on Firefox don't have permanent URLs [1]. This means that there is no single URL to whitelist on the developer page for the app.
Is there a way to make OAuth work with browser extensions on Firefox?
Thanks.
[1] Mentioned on a forum here, for example: https://discourse.mozilla.org/t/uuid-different-in-someone-elses-machine/36988
Thanks for the quick response. It seems that browser.identity.getRedirectURL() is on the right path.
I've experimented by adding and removing my extension from the browser a few times, the URL changes but the result of browser.identity.getRedirectURL() is stable.
Now, this is good but... I'm afraid there is more to make it work and I hit a wall once more. It seems that I have to use identity.launchWebAuthFlow().
- Previously I used a receiver path something like: moz-extension://7c66eee6-25<long-number>/qfeeds/oauth_receiver_dbox.html, only that the URL would always change, getRedirectURL() is now giving me a fixed URL. So I guess this is my new receiver URL: https://4ff3<long-number>.extensions.allizom.org/qfeeds/oauth_receiver_dbox.html
- The problem is that this is not a live URL, as discussed here: https://discourse.mozilla.org/t/oauth2-redirect-to-https-extensions-allizom-org-seems-to-fail/35994/4
- I was doing the Dropbox connection via call to chrome.tabs.create({ url: authUrl}), is this intended to be substituted by launchWebAuthFlow()?
Thank you for the help
Благодаря
🙂
dbox-arg0 wrote:...
- I was doing the Dropbox connection via call to chrome.tabs.create({ url: authUrl}), is this intended to be substituted by launchWebAuthFlow()?
...
The documentation:You'll use the redirect URL in two places:
- supply it when registering your extension as an OAuth2 client.
- pass it into identity.launchWebAuthFlow(), as a URL parameter added to that function's url argument.
So, yes - you have to pass to the function it as noted in documentation and the browser will take care for the rest, up to receiving redirecting URL back (at that point filled with appropriate parameters - authorization code or access token, refresh token, etc). Actual parameter interpretation have to be performed by your code (usually Dropbox SDK).
By the way, "live URL" is definitely not the most secure way! That's why usually it's replaced by platform specific addresses (on Android for instance). Seems Firefox developers are doing something similar. If I have to bet this will continue (doesn't seem complete yet). Such movements are supported by most service providers (including Dropbox).
Надявам се, че това помага. 😉 Приятен ден!
- Greg-DB
Dropbox Staff
I can't offer help on the Firefox side of things, but in case you can't use a redirect URI, it is worth noting that a redirect URI is actually optional on the Dropbox OAuth app authorization flow. That is, the use of a
redirect_urion /oauth2/authorize is not actually required; it's optional when using the code flow. If it is not supplied, the user is presented with the authorization code directly on the Dropbox web site after authorizing the app, which they would need to manually copy/paste into the third party app to complete the flow. While the user experience is certainly not as good, that may be an alternative if needed.
About Dropbox API Support & Feedback
Find help with the Dropbox API from other developers.
