I am using FreePBX version 16.0.26 alongside with Asterisk version 16.28.0 and have been following the guidelines given with the “Filestore Module” to set up a back up process to my Dropbox account.
I have created a “Dropbox” account space under the “Settings → Filestore” menu option of the FreePBX GUI, and have supplied the “Account Name”, “Token” and “Path” information.
Prior to the above, I have created under my Dropbox account the corresponding “App” name, and have created the OAuth2 access token and have setup the corresponding file “write” permissions for the external API access.
Under the “Admin → Backup & Restore” menu option of the FreePBX GUI, I have created the backup definition using as “Storage Location” my Dropbox “App” name defined as above.
I clicked the “Save and Run” button, and am getting in a pop window a log showing the status of the newly backup process. At the very last stage, I am getting the following message:
Performing Remote Maintenance
In RequestException.php line 113:
Client error: `POST https://api.dropboxapi.com/2/files/create_folder` resulted in a `401 Unauthorized` response: {"error_summary": "expired_access_token/", "error": {".tag": "expired_access_token"}}
I double-checked the “App” directory of my Dropbox account, and indeed, it is empty, though a backup has been successfully created under a subdirectory of the “/var/spool/asterisk/backup” base directory. The subdirectory name reflects correctly the name of the defined backup scenario.
Unless I missed something, can anybody enlighten me on what might have gone wrong here if I have correctly followed the steps as described above?
Yes, I copied the generated token from my Dropbox “App” definition, and pasted it in the “Token” field of the Dropbox destination definition under the “Settings → Filestore” as depicted with:
I have deleted the Filestore definition, and have recreated it with the same “Token”. This time, the backup worked fine as depicted with:
...
Finished Remote Maintenance
Saving to selected Filestore locations
Saving to: Dropbox:'MyDropboxBackupDestApp' instance ,File location: /Apps/MyDropboxBackupDestApp/20221221-_____________.tar.gz
Finished Saving to selected Filestore locations
There were warnings during the backup process
The module manager returned no data, No backup created
Generated Backup process result email to [email protected]. Status: Success
Above log displays that the “module manager returned no data, no backup created”.
However, when checking my Dropbbox account, there is indeed a valid “20221221-_____________.tar.gz” file that I can open with an archive tool and read its contents.
Thus, not sure how to interpret above warning message.
It is showing that only one backup is stored. All other subsequent backups are absent in the destination directory as defined under the “Settings → Filestore ” of the FreepBX application.
Seems that the backup to the Dropbox destination failed again. The Freepbx application just kept the first backup as outlined in my previous post.
Under the “Dropbox Developper App” console panel, I checked the configuration and status of the defined backup destination for Freepbx, and see that the previous defined token is no longer there as depicted with:
It looks I may have found the origin of the problem allowing me to reason on why the FreePBX backup to my Dropbox account does not work with a token:
The Dropbox community post with its title “API Access Token Expired” explains “that tool is just meant for prototyping Dropbox API calls, and currently has early access to an upcoming “short-lived access token” feature. That means that, unlike standard Dropbox API access tokens, the access tokens you get from the API Explorer will expire by themselves. (You can identify them by the “sl.” prefix you mentioned.)”
And indeed, when I generate the token for the FreePBX scenario, the generated token strings starts with “sl.” following by a series of other characters and numbers. This explains why the FreePBX backup fails with an error message that the access token has expired.
According to the section “Testing with a generated token” of the “Dropbox OAuth Guide”, the “authorisation process for the API call can be accomplished by a temporary token before implementing OAuth”.
The subsequent section “Implementing Code Flow” of the same guide explains in detail the recommended code flow to be used mandating an OAuth approach for all types of API applications using a specific URL of parameters with client ID, code and secret for authorisation to exchange an access token in order to make API calls between the APP and Dropbox.
https://issues.freepbx.org/browse/FREEPBX-23597
So a bug was filed over a year ago but it seems to be in a black hole. My guess is any fix to this will need to be community driven as there is no “business case” aka financial benefit to fix it.
