@FrancoisNOYEZ wrote:
... As long as I keep the 'oauth2_access_token_expiration' parameter equal to none, when carrying out this instantiation, I guess I will never need to perform new authentication operations, is that right?
...
Hi @FrancoisNOYEZ,
In the practice, yes, most probably. If we should be more general, there are situations where refresh token could be revoked (both explicitly, by your or another person having access to the account, or implicitly, by some actions, which shouldn't happen in normal case). Even very unlikely, it's good practice to expect such a situation in your code (script or other). When something goes wrong and the token gets revoked, somehow, just inform/warn in suitable way, at least. The same is valid for long lived access token, used by you till now. 😉 Just a good practice that can make your life easy sometimes!
@FrancoisNOYEZ wrote:
... In terms of management of this sensitive authentication data, in your opinion, how should I proceed? I used to pass along the authentication token as a parameter to the command used to launch my script ('cause I don't want to write it down in my script). Is it ok to do something similar now (the difference being that I'll have to provide 3 values instead of one)? ...
🙄🙂😁@FrancoisNOYEZ, If you care for data (of any kind) and don't want other process (and people accordingly) to touch it, command line is the worst place to pass such data (or not the best, definitelly, at least)! Command name a all options and parameters are object of logging in the shell history, at least. The same information is accessible through system tool for process monitoring (how exactly depends on exact OS in use, but accessible). Other ways are also possible! What think that you are hiding in such a way?!!! Be careful!
If I'm in your shoes, will look around your system and usually there is some sort of system "wallet". That's exactly what this service is dedicated for! Exact form is OS dependent, but generally there is some encrypted, system controlled storage where every application could reserve some space. There you can store sensitive data of your choice (like discussing here). The access is system controlled and one application can't touch data of other one and also the same application running on different account is restricted (there are different storage places). 😉 The just mentioned would be my choice.
The needed data representation can be stored on and received from a secure place (like the wallet above). On start, when available, could be used directly to instantiate Dropbox client object. When missing OAuth flow could run and result received will be used both for client instantiation and storage of sensitive data.
Hope this gives useful directions.
PS: For a almost platform independent way in Python try the "keyring" package. 😉 It behaves as a interface to corresponding installed system service. Or tries to, at least, and succeeds when there is available proper backend. Linux, Mac, and Windows are generally supported.
