Child Item

OAuth Updates for an App for just One Single User (Developer is only user) required ?

I received a mail from Dropbox announcing the Oauth updates by Sept 2021.

I have a very simple Single Page Java Script application - which runs in the browser not in node - and I use the Dropbox-sdk.js.

I am and will be the only user of this application.

It just does a

var dbxt = new Dropbox.Dropbox({ accessToken: "xxxxxxxxxxx" });

Where xxxxxxxxx is the Generated Access-Token from the App Console.

Then I use the returned object for a download

dbxt.filesDownload({
	path: '/BookLibrary.xml'
})

Thats it.

Do I have to change anything by Sept 2021 due to the changes with OAuth ?
If yes - Could you please provide an example for my simple case.
The "download" example that is provided in the Javascript SDK by today still works with a generated access-token so I guess I don't have to change anything.

Many thanks

Martin Klein

Find more posts tagged with

Developers

Comments

Greg-DB

In your case, you're not actually processing the OAuth app authorization flow, since you're just using a single pre-generated long-lived access token, so you technically don't need to change anything in your code.

While long-lived access tokens are now considered deprecated, but we don't currently have a plan to disable existing long-lived access tokens. (If that changes, we will of course announce that ahead of time.) That being the case, you can continue using existing long-lived access token(s) like this. Note that after the change you won't be able to create new long-lived access tokens though. So, after that point if you revoke your existing long-lived access token you wouldn't be able to generate a new one, and would need to instead update your code to use the new short-lived access tokens/refresh token functionality.

martinkleinaustria

Thanks for your reply.

If I understand you correctly in the future it would not be possible to generate access tokens in the App console ?

So I would be on the save side to switch to OAuth flow and in my case the PKCE method.

Could you please provide a PKCE example for my simple case.

The "download" example that is provided in the Javascript SDK would then also not work in the future because it also uses the pre-generated access-token so it must be reworked anyhow and I could then use this reworked "download" example for my app.

Unfortunatly the provided PKCE example in the SDK is based on node.js but my app runs just in the Browser. No server. No re-direct URL.

Many thanks for your support. Martin Klein

Greg-DB

The App Console will continue to offer the ability to generate access tokens. (Currently, that includes both long-lived and short-lived access tokens. After the change, it will no longer offer long-lived access tokens.) It does not currently offer the ability to additionally generate refresh tokens though. We may add that in the future, but I can't guarantee that.

I don't believe we currently have an example of processing the PKCE flow in browser JavaScript, but I'll pass this along as a request for one. I can't promise if/when that might be implemented though. There is unfortunately currently an open bug with that though anyway.

Greg-DB

We have a new example for using PKCE in the browser with the latest version of the JavaScript SDK, currently v9.4.0, here:

https://github.com/dropbox/dropbox-sdk-js/blob/main/examples/javascript/pkce-browser/index.html

martinkleinaustria

Many thanks for the example. Unfortunatly I only now had time to try it.

My problem is that this example works with a redirect-url 'http://localhost:8080/pkce-browser".

Since I dont work with npm I dont have a local server with this url.

I run my single-page app simply in the browser without any npm installation.

So I would expect the example to do the authorisation with a "Code Verifier" that is generated in the app and not

returned via a redirect-url.

But maybe I still do not understand the whole concept.

I have a simple one-page html App and I am and well be the only user of this app.

Many thanks for your help

With kind regards

Martin Klein

Greg-DB

I'm not sure I totally understand your latest message. Can you elaborate on what you currently need help with? What exactly are you currently trying to do and what are you stuck on? (Even if you can't run the new example via a local server, it can still serve as a reference for the JavaScript code you would need to run to implement the new OAuth flow.)

martinkleinaustria

I want to rework my existing very simple App that was based on the provided download example of the SDK to use the new authentication.

The provided new example that you suggested to me uses a local
server at the localhost domain listening to process messages on port 8080.

The whole code is written around this functionality. It receives the access token via this callback.

So my problem is that I cannot use this example since I have no local host because I dont use npm.

Might be that there is no solution for my simple case. Propably I would need a local server for the new authentication and therefore would need a npm environment.
But then dropbox in the future is no solution for a pure browser environment without npm.
But this should then be clearly stated in the documentation.
With kind regards
Martin Klein

Greg-DB

While our sample does run a local server using npm/node, npm/node is not the only option. You have your choice of server for your own app. You don't need to use npm/node in particle to integrate with the Dropbox API using the JavaScript SDK in the browser.

Also, the new authorization system does not actually change the requirements on authorization flow itself, such as redirect URIs. You still have the same options as before. For instance:

if this is only for your own use, you can still manually input your own access token and now optionally refresh token without processing the OAuth flow each time
if you do implement the OAuth flow, you still are not required to use a redirect URI. With the "code" flow, a redirect URI is still optional; if you don't use one the user just has to manually copy and paste the returned authorization code into the app

It sounds like in your case you probably just want to process the OAuth flow manually once for your own account to get a refresh token (redirect URI not required) and then plug the resulting refresh token in to the Dropbox constructor, along with the other parameters.

martinkleinaustria

I tried now your first suggestion:

if this is only for your own use, you can still manually input your own access token and now optionally refresh token without processing the OAuth flow each time

So in the Dropbox App Console I requested a Short Term Access Token (Short Term because the never ending one will disappear in the future). I inserted this manually in your sample code and of course that worked - but only for around 10 hours. Then I received a 401 error on the file list call.

So this means that I would have to do this manual request of a new access token basically every new day I use the app. Not really a solution !

But during the next days I will try your second suggestion and come back to you.

With kind regards

Martin Klein

Greg-DB

Short-lived access tokens only last for a few hours, so if you need long-term access, you'd also need to plug in a refresh token. The refresh token can be used to get new short-lived access tokens on demand, without further manual interaction. The App Console doesn't offer the ability to get refresh tokens though, so you'd need to process the OAuth flow (which you can do manually just once if that's all you need) to get the refresh token.

martinkleinaustria

Ok. Can you please point me to or provide me an example for a MANUAL OAuth flow that would provide me a refresh Token.

Many thanks and kind regards

Martin Klein

Greg-DB

You can find examples in the authorization documentation, such as how the authorization URL should be formed for /oauth2/authorize, as well as how calls to /oauth2/token would be made using curl.