Dropbox long-lived tokens ending Sep 30, 2021 about flysystem-dropbox HOT 9 CLOSED

Feel free to start, I highly appreciate a PR for this 👍

from flysystem-dropbox.

@freekmurze What would be the general approach/preference regarding where/how to store the new refresh tokens? Database? Local file?

from flysystem-dropbox.

Maybe make an interface so users can choose where to store stuff.

from flysystem-dropbox.

In my Laravel setup, I think I will work toward a local storage solution for the refresh token. I am using the CachedAdapter already so I could take an approach of an .env variable with the path.

namespace App\Providers;

use Illuminate\Support\Facades\Storage;
use Illuminate\Support\ServiceProvider;
use Spatie\Dropbox\Client as DropboxClient;
use League\Flysystem\Filesystem;
use Spatie\FlysystemDropbox\DropboxAdapter;
use League\Flysystem\Adapter\Local as CacheFilePath;
use League\Flysystem\Cached\CachedAdapter;
use League\Flysystem\Cached\Storage\Adapter as CustomAdapter;

class DropboxServiceProvider extends ServiceProvider
{
    /**
     * Register any application services.
     *
     * @return void
     */
    public function register()
    {
        //
    }

    /**
     * Bootstrap any application services.
     *
     * @return void
     */
    public function boot()
    {
        Storage::extend('dropbox', function ($app, $config) {
            $client = new DropboxClient($config['authorization_token']);
            $dropbox = new DropboxAdapter($client);
            $local = new CacheFilePath('/mnt/secure_files/dropbox');
            $cache = new CustomAdapter($local, 'cachefile', 300);
            $adapter = new CachedAdapter($dropbox, $cache);
            return new Filesystem($adapter, ['case_sensitive' => false]);
        });
    }
}

My server is not publicly accessible, and I would be using the offline (long-lived) refresh token. I just went through rclone's process for the same thing on a Debian server.

I'm thinking I could follow the approach rclone took and create a Console configuration script which would allow (as in my case on a server with no public access) a URL to be copied, and taken to a device with internet access to get the initial response code. Then the code gets entered, and first refresh token gets stored.

With that, and adding in logic to incorporate the refresh token process, and adding a catch for the 401 Unauthorized response (which would then require the user to run configuration again), I think that might work. In Client.php where there is a check for the $accessTokenOrAppCredentials I could incorporate a check for whether the REFRESH_TOKEN_PATH is empty. If it's not, then proceed with using that.

How does this sound?

from flysystem-dropbox.

I see there is a discussion in dropbox-api which handles credentials. Sorry this was the wrong place.

from flysystem-dropbox.

@garrettboone Hi, did you manage to add short-lived token functionality? Thanks

from flysystem-dropbox.

@anderea1 No, I've been putting it off so my files are piling up in a temp folder. It seems everyone else is going for a end-user interface with oauth2 but I don't need that. If you think you want to do it, go for it. But if not, let me know. I need it myself and should do something soon.

from flysystem-dropbox.

@garrettboone see here if it suits you #86

from flysystem-dropbox.

@anderea1 With long-lived refresh tokens, even though they are long-lived they are part of each response and can be replaced. ie long-lived but short-used. By storing it locally and replacing each request rather than noting in the env, as long as a request is made frequently enough, you won't run into an expired refresh token.

from flysystem-dropbox.