Child Item

Error 400 after team admin grantes access.

Hello,
in 2021 we developed a dropbox integration which, right now is actually working correctly.
Recently we wanted to deploy another installation of our integration, to do so, we generated a new integration from app console, and we copied all our setups.

Unfortunately we are not able to conclude team oauth flux, here you go the steps to reproduce:

User lands on:
https://www.dropbox.com/oauth2/authorize?include_granted_scopes=team&token_access_type=offline&scope=team_info.read+account_info.read+files.metadata.read+files.content.read+files.metadata.write+files.content.write+team_data.member+team_data.team_space+files.team_metadata.write+files.permanent_delete+members.read+sharing.read&response_type=code&redirect_uri=http%3A%2F%2Fxxxx%2Foauth%2Fcallback%2Fdropbox-team&state=xxx&client_id=xxx
Eventually user is warned about integration's development status
Dropbox asks user to confirm all scopes given in url:
User allows integration permissions
User gets redirected to https://www.dropbox.com/1/oauth2/authorize_submit :

The strange part is that dropbox do not provides any information on what is happened.

If we try to do the same using old integration, oauth flux is completed correctly.
Both integrations are scoped apps in development mode, they have the same permissions enabled:

We discovered, by trial and error, that flux can be completed with a subset of given oauth scopes. Not sure which exactly breaks this flux, but we are able to complete the flux by using only scopes that begin with "team".

This looks like a bug or an undocumented breaking change to me.

Please, let me know if i can clarify anything.
Cheers.

Find more posts tagged with

API

Abuse

Comments

tahsini

Thanks for writing in. Can you reach out to our support channel here from the account that owns the applications, so we can assist you further? Please include information about both of your apps and the errors that are occurring.

This issue requires a bit more troubleshooting and comparison of the apps and we do not want to divulge any private app information in a public forum.

riccardo-manzan-yoroi

We opened a request as you suggested, i would leave this tread open in order to update it if we find a solution that may help anyone else.

Thanks and cheers.

Greg-DB

Thanks for reporting this issue. This issue has now been addressed.

To resolve this issue, please now disable and then re-enable the files.permanent_delete scope and then click "Submit" for any affected apps(s) on the "Permissions" tab for the app on the App Console. If you do not need the files.permanent_delete scope, you should leave it disabled.

Apologies for any inconvenience this may have caused, and thanks again for bringing this to our attention.