cancel
Showing results for 
Show  only  | Search instead for 
Did you mean: 
Announcements
Want to learn some quick and useful tips to make your day easier? Check out how Calvin uses Replay to get feedback from other teams at Dropbox here.

Discuss Dropbox Developer & API

cancel
Showing results for 
Show  only  | Search instead for 
Did you mean: 

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

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

martinkleinaustria
Explorer | Level 4

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

12 Replies 12

Greg-DB
Dropbox Staff

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
Explorer | Level 4

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

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

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
Explorer | Level 4

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

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
Explorer | Level 4

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

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
Explorer | Level 4

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

Need more support?
Who's talking

Top contributors to this post

  • User avatar
    Greg-DB Dropbox Staff
  • User avatar
    martinkleinaustria Explorer | Level 4
What do Dropbox user levels mean?