Dropbox Diy
Carmen Kalua
When working with the Dropbox APIs, your app will access Dropbox on behalf of your users. You'll need to have each user of your app sign into dropbox.com to grant your app permission to access their data on Dropbox.
The selected scopes are applied to your access token and determine which API calls your application is allowed to execute. This level of access is then communicated to the end user on the Dropbox app authorization page where the user consents to sharing their data.
Prior to the introduction of scopes, Dropbox API apps would select only their level of content access (described below). Business API apps would select from one of four permission types to determine the API calls they have access to:
Always ask for the least amount permissions required by your applications. Requesting more scope and content access than required may result in end users not accepting your OAuth request and could impact your app review process.
Before you can get started, you'll need to register your app with Dropbox by creating a new app in the App Console. That page will guide you through the process of registering your app, selecting permissions, and obtaining an app key and secret (a.k.a. client_id and client_secret) and inputting redirect URIs.
If you'd like to quickly test out the Dropbox APIs using your own Dropbox account before implementing OAuth, you can generate an access token from your newly created app in My apps by pressing the button that says "Generate" in the OAuth 2 section of your app settings page.
PKCE is an open extension to OAuth 2.0, and solves this problem using dynamic codes instead of the static client_secret. Your app should construct a random code_verifier at authorization time of the user.
When an app requests team scopes for the Business API, the resulting token is associated with the team (rather than the administrator who authorized it). The user scopes requested as part of the team authorization define the calls that can be used when acting on behalf of a team member with Dropbox-API-Select-User.
Dropbox access tokens are short lived, and will expire after a short period of time. The exact expiry time of a token is returned by the token endpoint (or the redirect URI in implicit grant) - but is generally long enough for a reasonable web session.
Applications that require offline access to the API - meaning using the API when the end user is not actively interacting through your app - will not be able to prompt for re-authorization. These apps may instead use long-lived refresh tokens can be used to obtain new access tokens.
When using refresh tokens, your call to the /oauth2/token endpoint with the grant_type of authorization_code will return a short-lived access token and a refresh token, which should be securely stored.
To update your access token, call the /oauth2/token endpoint - specifying your refresh_token as a parameter and using the grant_type of refresh_token. The endpoint will return a new short-lived access token and a timestamp indicating its expiration time.
For existing apps migrating to short-lived tokens, the token_access_type parameter on your authorization URL enables requesting short-lived tokens per-auth, allowing you to update your code without versioning issues in the Dropbox App Console.
Instructions to move dropbox file location don't work. There is no "click sync then click move" option under the dropbox tray gear icon on Windows 10. I need to get the default location which is on an SSD boot drive moved to a larger drive.
Thank you so much. It worked great but the instructions on the dropbox website (pasted below) are wrong. It says for Windows, to select the gear icon first, then sync. I'm sure you knew what they were trying to say but we old engineers tend to be very literal. Thanks again.
Click the Dropbox icon in your system tray. The app window will open. In the top-right corner you'll see either the gear or your avatar icon. Click that and select Preferences. Alternatively, you can CTRL-left click the Dropbox icon in the system tray and select Preferences (this is the legacy menu).
This message isn't about moving files it's about moving folders. I have a mac. I just want to move a file from one folder to the other. If I try to copy and paste, it jsut makes another copy in the orginal folder that i want to move from! There's no drag or drop. I even tried moving it back to finder and then moving it back to the right folder and it keeps going to the wrong one!
Did this post help you? If so, give it a Like below to let us know.
Need help with something else? Ask me a question!
Find Tips & Tricks Discover more ways to use Dropbox here!
Interested in Community Groups? Click here to join
Solution: It is possible to solve this properly. It is possible to use Git with Dropbox and have the same safety and consistency guarantees as a traditional Git remote, even when there are multiple users and concurrent operations!
This answer is based on Mercurial experience, not Git, but this experience says using Dropbox this way is asking for corrupt repositories if there's even a chance that you'll be updating the same Dropbox-based repository from different machines at various times (Mac, Unix, Windows in my case).
I don't have a complete list of the things that can go wrong, but here's a specific example that bit me. Each machine has its own notion of line-ending characters and how upper/lower case characters are handled in file names. Dropbox and Git/Mercurial handle this slightly differently (I don't recall the exact differences). If Dropbox updates the repository behind Git/Mercurial's back, presto, broken repository. This happens immediately and invisibly, so you don't even know your repository is broken until you try to recover something from it.
After digging out from one mess doing things this way, I've been using the following recipe with great success and no sign of problems. Simply move your repository out of Dropbox. Use Dropbox for everything else; documentation, JAR files, anything you please. And use GitHub (Git) or Bitbucket (Mercurial) to manage the repository itself. Both are free so this adds nothing to the costs, and each tool now plays to its strengths.
I didn't want to put all my projects under one Git repository, nor did I want to go in and run this code for every single project, so I made a Bash script that will automate the process. You can use it on one or multiple directories - so it can do the code in this post for you or it can do it on multiple projects at once.
It is now 2015, and as of three days ago, a new tool based on Dropbox API v2 has been created to safely use git on Dropbox. It works against the API rather than using the desktop client, and correctly handles multiple simultaneous pushes to a repository hosted in a shared folder.
The coolest thing is that Dropbox does NOT sync the entire TrueCrypt container if you modify a small portion of your code. The sync time is roughly proportional to the amount of changes. Even though it's encrypted, the combination of TrueCrypt + Dropbox makes excellent usage of block cipher + block level sync.
Caution: However you have to be very careful about not having the container mounted while Dropbox is running. It can also be a pain to resolve conflicts if 2 different clients check-in different versions to the container. So, it's practical only for a single person using it for backups, not for a team.
P.S. Unchecking the preserve modification timestamp tells dropbox that the file has been modified and it should be sync'd. Note that mounting the container modifies the timestamp even if you don't change any file in it. If you don't want that to happen, simply mount the volume as read-only
I've been using Mercurial in the recommended manner and urge that you be cautious, especially if any of the machines differ. The Dropbox fora are full of complaints of mysterious filename case problems turning up spontaneously. Hg (and I presume Git) won't notice or complain during routine checkins and you'll only hear about the corruption when it complains of a corrupt repo when you try to use it for real. Bad news. Wish I could be more specific about the problem and its workarounds; I'm still trying to dig out from this mess myself.
I store my non-Github repo's on Dropbox. One caveat I ran into was syncing after a reinstall. Dropbox will download the smallest files first before moving to the larger ones. Not an issue if you start at night and come back after the weekend :-)
All the answers so far, including @Dan answer which is the most popular, address the idea of using Dropbox to centralize a shared repository instead of using a service focused on git like github, bitbucket, etc.
un-sync the .git directory in Dropbox. If using the Dropbox App: go to Preferences, Sync, and "choose folders to sync", where the .git directory needs to get unmarked. This will remove the .git directory.
Optionally, the -r command argument specifies the remote branch that will push to the origin master. The location of the project origin master can also be specified with the -m argument. A default .gitignore file is also placed in the remote branch directory. The directory and .gitignore file defaults are specified in the script.
For my 2 cents Dropbox only makes sence for personal use where you don't want to bother getting a central repo host. For any professional development you'll probably create more problems than you'll solve, as have been mentioned several times in the thread already, Dropbox isn't designed for this use case. That said, a perfectly safe method to dump repositories on Dropbox without any third-party plugins or tools is to use bundles. I have the following aliases in my .gitconfig to save typing: