Dropbox and user folder

KHofmeyer

In the MAS FAQ you have this sentence:



[color=#282828]

If you choose to sync your 1Password data using the free Dropbox service, the 1Password data file must live in a fixed folder of your Dropbox storage and the Dropbox folder *must be* located in your OS X account's home folder.[/color]

[color=#282828]

[/color]

[color=#282828]

My dropbox is folder is on another drive and has been using 1password this entire time. Does this mean the MAS version won't work for me?[/color]

danco

As far as I can tell, you can't use Dropbox the way you would like.



What I think works (I have not tried it) is having your Dropbox folder directly in your home folder, with theAgile keychain in that folder, and using a symbolic link to all your other Dropbox files on the other drive.

KHofmeyer

That would be a huge headache. This also proposes issues for others. My dropbox is 50 gigs, I can't use my OS drive for that much data. Also, at some point drop box will allow you to chose folders no matter where they are to sync with dropbox as well. I have been using 1password for 4 years and this is the first time I may look elsewhere. I don't care about paying again, having to use the mac app store, or any of that. But to have to change my entire computer setup to use the software seems like a downgrade to me.



Can no on at 1password confirm this?

danco

But you would NOT be using your OS drive for all your data.



You would just be using it for the 1PW data, and making a symbolic link to the rest of the data.



The folks at Agile have confirmed that it is a requirement (for an App Store app with sandboxing) to specify *in advance* what folders can be accessed, the user cannot decide.

khad

danco is correct. Your Dropbox folder must be located in your Home folder in order for 1Password syncing to work.



To conform to Apple's specific rules for Mac App Store submissions, there are some significant differences between the application available from the AgileBits store in the past and what you'll get when you purchase 1Password from the Mac App Store.



You only have two choices of location for the data file: within the installed sandbox of the application or in Dropbox.



If you choose to sync your 1Password data using Dropbox, the 1Password data file must live in a fixed folder of your Dropbox storage and the Dropbox folder [b]must be[/b] located in your OS X account's home folder.

Jon Marler

[quote name='khad' timestamp='1315737244' post='47693']

danco is correct. Your Dropbox folder must be located in your Home folder in order for 1Password syncing to work.



To conform to Apple's specific rules for Mac App Store submissions, there are some significant differences between the application available from the AgileBits store in the past and what you'll get when you purchase 1Password from the Mac App Store.



You only have two choices of location for the data file: within the installed sandbox of the application or in Dropbox.



If you choose to sync your 1Password data using Dropbox, the 1Password data file must live in a fixed folder of your Dropbox storage and the Dropbox folder [b]must be[/b] located in your OS X account's home folder.

[/quote]



With all due respect, I believe that Agile Bits is being a bit dishonest when blaming Apple for the problems with Dropbox synchronization with 1Password 3.9. Agile Bits chose to use sandboxing, which is [b]not[/b] required for the Mac App Store, though it is [i]recommended[/i]. Agile Bits has also chosen to ignore the advice of Dropbox and not implement the Web API to access Dropbox objects from 1Password instead accessing the files directly, which will not work when using sandboxing. If Agile Bits had chosen not to implement sandboxing, or chosen to use the Dropbox Web API, there would be no special issues or workarounds required to use Dropbox to store the agilekeychain files for synchronization. Neither choice would preclude Agile Bits from distributing 1Password via the MAS.

dwh

My understanding is that sandboxing will be required for MAS applications as of November, so why in the world would Agile choose to release a product whose architecture would require a major overhaul in just two months?

Ben

[quote name='dwh' timestamp='1315790839' post='48003']

My understanding is that sandboxing will be required for MAS applications as of November, so why in the world would Agile choose to release a product whose architecture would require a major overhaul in just two months?

[/quote]



This is indeed correct. Starting in November, any new app submissions or any updates to existing apps will need to include sandboxing. It is an Apple requirement in order to be listed on the App Store.

Jon Marler

[quote name='dwh' timestamp='1315790839' post='48003']

My understanding is that sandboxing will be required for MAS applications as of November, so why in the world would Agile choose to release a product whose architecture would require a major overhaul in just two months?

[/quote]



Why? The answer is simple: To allow the application to continue to work today while Agile Bits works on implementing the Dropbox Web API. To simply lay this at Apple's feet is dishonest IMHO. The absolute truth is that it is [b]not[/b] a requirement today, and we have all seen Apple threats come and go with no effect. The current developer documentation only recommends sandboxing and the only public mention of requiring sandboxing in November was at WWDC. Apple has yet to publish anything that specifies a date or time for requiring sandboxing. It would make more sense to me that sandboxing was a 1Password 4.0 feature, not for 3.9. If you read through the problem reports here, 9 out of 10 have to deal with Dropbox all of which appear to revolve around the sandbox container and entitlements.



Regardless of the sandboxing requirement, Agile Bits has still ignored the advice of Dropbox by failing to use the Dropbox Web API. This could easily be done within the sandbox, and would technically be the best way to comply with the sandboxing requirement and still use Dropbox for synchronization. That has absolutely nothing to do with Apple.

MikeT

[quote name='Jon Marler' timestamp='1315793599' post='48014']

]Regardless of the sandboxing requirement, Agile Bits has still ignored the advice of Dropbox by failing to use the Dropbox Web API. This could easily be done within the sandbox, and would technically be the best way to comply with the sandboxing requirement and still use Dropbox for synchronization. That has absolutely nothing to do with Apple.

[/quote]Hi Joe,



Their web APIs are for mobile apps only, not for desktop. There are [url="https://www.dropbox.com/developers/desktop_apps"][b]no official API support[/b][/url] for desktop apps. We can not use an unofficial API that'll change in a short period of time as a lot of our users depend on the Dropbox sync. Dropbox is discouraging any developers from doing this right now.



Dropbox just announced a beta version of their API that might work with desktop apps but until they finalize it, 1Password will continue to use the same method as it is now.

Jon Marler

[quote name='MikeT' timestamp='1316183530' post='49556']

Hi [b]Jon[/b],[ed]



Their web APIs are for mobile apps only, not for desktop. There are [url="https://www.dropbox.com/developers/announcements/9"][b]no official API support[/b][/url] for desktop apps. We can not use an unofficial API that'll change in a short period of time as a lot of our users depend on the Dropbox sync. Dropbox is discouraging any developers from doing this right now.



Dropbox just announced a beta version of their API that might work with desktop apps but until they finalize it, 1Password will continue to use the same method as it is now.

[/quote]



There are actually two separate API kits: mobile and web. Even in the link you sent me, Dropbox says in regards to using the Web OAuth libraries:



[quote]This is the safest and most reliable method of accessing Dropbox.[/quote]



More importantly, it would allow you to continue to use sandboxing while supporting agilekeychain data stored anywhere in Dropbox without ANY issues. The Web API is similar to the mobile API, but they are not exactly the same and have different authorization mechanisms. It should be trivially simple to add an OAuth WebKit screen for authorizing access to Dropbox. From there it would be quite easy to synchronize.



This would make a killer feature for 4.0!

MikeT

Hi Jon,



I mistakenly linked to their blog post instead of their official page here: [url="https://www.dropbox.com/developers/desktop_apps"]https://www.dropbox....rs/desktop_apps[/url]



[quote]Dropbox desktop apps are not currently supported as we continue to focus on improving the mobile and web APIs. [/quote]



Yes, we can certainly use Web APIs (which have its own limits) but at the moment, our current method of accessing Dropbox is the best way for desktop apps to work with while we wait for Dropbox to finalize their desktop/web APIs. We do not have the resources to constantly adjust to APIs that are now in flux at Dropbox, they just started a major beta of their new APIs. Hopefully, when they finish it, we can start using it. Until then, we do not plan to change this for now.



Thanks for bringing this up.



As for 4.0...who knows. <img src='http://forum.agilebits.com/public/style_emoticons/<#EMO_DIR#>/smile.png' class='bbc_emoticon' alt=':)' />

Jon Marler

[quote name='MikeT' timestamp='1316192221' post='49586']

Hi Jon,



I mistakenly linked to their blog post instead of their official page here: [url="https://www.dropbox.com/developers/desktop_apps"]https://www.dropbox....rs/desktop_apps[/url]







Yes, we can certainly use Web APIs (which have its own limits) but at the moment, our current method of accessing Dropbox is the best way for desktop apps to work with while we wait for Dropbox to finalize their desktop/web APIs. We do not have the resources to constantly adjust to APIs that are now in flux at Dropbox, they just started a major beta of their new APIs. Hopefully, when they finish it, we can start using it. Until then, we do not plan to change this for now.



Thanks for bringing this up.



As for 4.0...who knows. <img src='http://forum.agilebits.com/public/style_emoticons/<#EMO_DIR#>/smile.png' class='bbc_emoticon' alt=':)' />

[/quote]



You're faith in the desktop client is admirable given bold statements from Dropbox such as "[b]this method will likely be deprecated[/b]." and the quote I linked to above indicating that the Web API is the safest method of access. All the while knowing what a tremendous problem sandboxing will create using the desktop client. Given my countless hours of interaction with other developers it does not surprise me in the least.

MikeT

[quote name='Jon Marler' timestamp='1316192619' post='49588']



You're faith in the desktop client is admirable given bold statements from Dropbox such as "[b]this method will likely be deprecated[/b]." and the quote I linked to above indicating that the Web API is the safest method of access. All the while knowing what a tremendous problem sandboxing will create using the desktop client. Given my countless hours of interaction with other developers it does not surprise me in the least.

[/quote]



This is the direct quote from [url="https://www.dropbox.com/developers/announcements/9"]Dropbox[/url]:

[quote]It's important to note that support of this method is intended for use with people running Dropbox desktop clients of versions 1.2 and below and w[b]ill likely be deprecated in the future to make way for a more sophisticated Desktop API. [/quote][/b]

That's what they're referring to and since the Desktop APIs are not ready, yet, the current method is okay to use.



As for the Web APIs being the safest and reliable methods, they also said:



[quote]

In a pinch, you can also take advantage of the syncing capabilities of the Dropbox desktop client apps by bypassing the API and reading/writing to and from the Dropbox folder.[/quote]



We can go back and forth but we're not disagreeing about the use of APIs but more of the priority. Right now, it is not a high priority for us to use the APIs that are not intended for us to use. Until Dropbox has an API ready for us to use, we can start investigating about taking advantage of it as soon as possible.