Access dropbox file - Authentication failed because the remote party has closed the transport stream

---

Lukag wrote:

... 

this is the command

https://www.dropbox.com/oauth2/authorize?client_id=.....&response_type=code&token_access_type=offline  

...

---

Hm..🤔 What I wrote there is:

---

@Здравко wrote:

..., open a new browser window and put into address line following:

https://www.dropbox.com/oauth2/authorize?token_access_type=offline&response_type=code&client_id=<App key>

...

---

Does this sound like a command? 🧐

@Lukag The described there are all steps that you need to take for simplest OAuth flow. There are other options though, but most probably you don't need them, since you want long term access to a fixed account - the yours (correct me if I'm wrong).

The only thing you need to include in your code is the last step there (the one that needs to be repeated every time your access token expires and you need new one). That step is command. The previous steps are executed one time only and most probably you don't need them encoded. You may follow them as described there if only single (your) account needs to be linked. Just take from result the refresh token and also save in your code application key (client id) and application secret (client secret). 😉 That's all. If you're still not sure, the above is NOT command, it's web address that needs to be open in web browser (so the OAuth flow starts)!!!

Hope this sheds a piece of light.

PS: Keep in mind that none of credentials need to be exposed to the client web session (that would be security hole)! If you want let client side access, it's better PKCE code flow to get in use and in such a case all steps need to be encoded (so client will be able start OAuth flow and link corresponding account accordingly, not only you). In all cases you will need to avoid exposure of credentials that have nothing to do with particular web session.

Ok , that was ad address to use in browser 😞 

I understood that now it's better if i generate a new token ( by API )  every time. Is it or not ?

Hm..🤔 To be honest, I don't understand what you mean. Maybe the actual question should be do you need long term access or not?! This is your design decision though. 😉

If you need a single shot (i.e. something that would be run occasionally) application for your own use only, getting access token every time might be better (and simplest) solution. In all other cases use of some form of OAuth might be better solution (my proposal is the simplest OAuth flow for long term use - it is suitable for server side applications, as your looks like according your description).

The decision is yours.

My scenario in where by web app my customer look and open his file in dropbox. 

Just one form or two, just one user or two. 

I think that token access should be good. However if in future my scenario will change i'll change also my code. 

So , if you agree with me i'll continue on this way .

So i'll need generate a new token every time. Can i do it run time by api ?  

---

Lukag wrote:

... Can i do it run time by api ?  

---

Definitely NO! API cannot self authenticate. 🙂 If that was possible, it would be a big security HOLE.

Actually, the refresh step in my description above (that you don't like) does exactly this, but it's different thing. There refresh token is used for authentication (valid refresh token). 😉

i dont understand some steps.

Duration token is 4 hours, if generate now and tomorrow i'll use it in my app , the server'll answer me that token in expired / invalid . So should i refhresh by Api ? 

Do you understand that there are different tokens? 🧐

---

Lukag wrote:

...

Duration token is 4 hours, if generate now and tomorrow i'll use it in my app , the server'll answer me that token in expired / invalid ...

---

What token do you take in mind above? 🤔

Read again entire thread here and linked resources. 👆 Don't jump over!

I understood the nonsense I was saying, I continue to study. Thank you

I thought that the token was quite alway the same.

So.. the first step i must autenticate the app / user by this :

https://www.dropbox.com/oauth2/authorize?client_id=<APP_KEY>&response_type=code 

After i use  https://api.dropboxapi.com/oauth2/token

Example: code flow access token request

Right ? 

@Lukag Try read again the thread I linked to. There have been all steps shown. That you have posted is the thing you don't need encoded mandatory - i.e. execute by hand single time only outside your application. The last step, you skipped above, is mandatory to reside in your code. It may generate new access tokens whenever needed. I don't know how to say it more clear!

do you speak about this ? 

Link 

Yes.

ok .. i'm doing all steps 

when i do 

curl https://api.dropbox.com/oauth2/token -d code=<received code> -d grant_type=authorization_code -u <App key>:<App secret>

 answer me that u is ambiguos 

chooses : -UseBasicParsing -Uri -UseDefaultCredentials -UserAgent 

It is not mandatory you use curl command. You can use any other, but of course should adapt the params. Not all command have the same params set! My example (and not only) uses original curl command, not aliases that point to something else. Check what your alias points to. It looks like some shell' internal redirection that confuses you. Try another shell.

i downloaded curl.

Now i have two token and the second one never expire. Right ? id' like use always it 🙂  

refresh token doesn't expire. The tokens (and the JSON at all) are not ordered, so I don't know is it second one or not (better don't rely). Navigate on base of the field name.

ty very very much.

Good morning,

a clarification : the refresh token must be used just to obtain a new token or i can use it to obtain data ( like in /list_folder ) ?   

Hm..🤔 Can you recall this? 🙋🤫 Oh.. that laziness... Is it so "impossible" not to jump the things over? 🧐🤣

ok i hope to use the token refrecsh that don't expire to access data. Ok i'll generate a new one. Ty 

I hope you have heard about Object Oriented Programming (OOP). It's not matter of OOP language in usage! The language makes the things easier, but it's only a predispose - it doesn't make your code object oriented automatically. Actually, you can use procedure oriented programing language (for instance) and follow object orientation (and opposite) - nothing prevents it. Why am I saying this?

You can (if you want) encapsulate functionality about credentials in a type named... let's say "Credentials". This type may contain everything needed like application key, application secret, refresh token, current access token, and expiration moment of the current access token. Also the same type may has one public property letting access to valid access token that you need each time a regular API call is going to be maid. Every time that property gets accessed, the property getter may check if the current access token is still valid (with some reserve - 3~5 mins). If it is, the current access token is passed back immediately - it is just valid. If it is not (the token expiration moment has passed and the token is expired), refresh step is performed (as discussed already) in the getter. Once the refresh call succeeds, the new expiration moment is calculated (current moment plus validity period) and saved accordingly for future use (comparison) together with the just received access token. At the end, getter returns with the new valid (again) access token.

Following this rule will make you code clear and simple.

This is OOP - functionality encapsulation and reuse. 😉