Login without DB UI intervention?

No - the intention is that you never handle the user credentials.

If you want to use a central DB account, then the best thing to do is do the authentication process during your development, and include the valid auth token in the final build of the app - then it never has to auth with Dropbox, its already been done.  You can build in an update routine so the app regularly checks for a new auth token from your server if you need to.

Thanks for the prompt reply and sorry if this is known. We want the app to bring data to OUR dropbox not the users, and we don't want users using the app to login to dropbox at all.

If I understand you right how would we get hold of the valid auth token after our app is logged in to our account during development? And what would we use in the objC SDK to initialize this for our session so calls would proceed properly as if it was linked via UI process etc?

We thought maybe we could use the "generated" token and embed it in the app but apparently this does not work with the objC SDK since it uses Oath1 not OAuth2...

Richard has this correct. This is possible, though it is not recommended. 

The iOS Core SDK does use OAuth 1, and the generated token on the App Console uses OAuth 2, as you noted, so you can't plug that in directly. You'd need to instead implement and run the OAuth 1 flow once for your account. There was another thread where I helped another developer through this in some detail here:

https://www.dropboxforum.com/hc/en-us/community/posts/204110983-Is-linking-necessary-to-download-files-

The StackOverflow posts I linked to there should be useful too:

https://stackoverflow.com/questions/15014001/allow-dropbox-api-to-access-my-account-on-users-device
https://stackoverflow.com/questions/27834922/auto-login-dropbox-account-on-core-api-without-login-prompt

Again though, I should emphasize that this is not recommended. A malicious user could extract the access token from your app and use it directly, bypassing any access controls you may have attempted to enforce.

You guys ROCK! I had read that post earlier and the guys' inability to listen made me miss the key part. To summarize for Oauth1 (until we get v2 for objC) you run a connect using linkfromController and then dump the MPOAuthCredentialConcreteStore creds for the userid of the dropbox you want to connect to. First you have to get the real userid by making a request for the account info via the loadAccountInfo method (at first I thought it was the name or email addy), then you call the credentialStoreForUserId method to extract the creds from the local SDK framework.

Take the stored token and secret returned in the creds and stuff them into the sharedSession via the updateAccessToken:accessTokenSecret:forUserId method in the future and VOILA you are linked. In fact the isLinked method of DBSession only looks to see if there is an entry in the creds array internally so it is then ready to rock.

As you guys pointed out storing the token and secret in the app is a security risk (whose extent also depends on the nature of the data being stored). A smart developer might fetch these from his own website using other secure means so as to keep the app secure and to enable the developer to reissue the credential periodically without breaking the app.

Thanks again for helping me see the light! Hopefully the v2 interfaces for objC will not be drastically different than the v1 when they come? I am quite pleased with how easy the integration is compared to the other cloud storage services.

One final question on the topic. If I wanted to use this technique as a sideband storage to our own dropbox silently AND to enable users with the regular auth cycle for their datastorage I am guessing I need to setup 2 DBSessions? Perhaps put the user's dropbox on the shared Session and do our sideband transmissions to our own dropBox on another DBsession?