When I started using DevonThink first, I didn’t want to have to work out the nitty-gritty of it’s particular methods of storing preference files and web security, so I set DevonThink to allow cookies but disallow those from third party sites and checked the “Delete Cookies on Quit” checkmark because I didn’t expect to be logging into any accounts from DevonThink’s web browser.
Then after some time, I noticed Safari had developed a nasty habit of dropping all cookies at various and seemingly random times. Sometimes they would last for a week, sometimes only a day. Searching the Googles proved fruitless as there were so many possible causes that people argued on forum posts. I even went so far as to trash my whole Preferences folder and reinstall Snow Leopard in order to fix the issue to no lasting effect.
And then I noticed that after I had quit DT, Safari had lost it’s cookies yet again after I’d reset the Cookies.plist file manually only hours earlier. Logging into a website then launching and quitting DevonThink proved that DT has been the culprit the whole time.
I find it offensive that DT even has the option to delete Safari’s Cookies.plist file and has no warning to this behavior or ability to use a Different cookie file. I am fairly used to the fact that session and authentication cookies are often inaccessible from outside programs (especially downloading tools) and so I don’t expect them to work. I understand that sharing the Safari Cookies.plist file is most likely the solution to this problem of handing over downloading operations from Safari to DT when authentication is required.
What I don’t understand is how the experience of the “Delete Cookies on Quit” doesn’t take into consideration the fact that Safari or WebKit may still be open and working inside an authenticated website or that DT deletes cookies that it didn’t create itself.
My suggestion would be this: Keep a separate Cookies file just for DevonThink, prefer it over Safari’s, and then allow Safari’s cookies. Deletion of cookies should be restricted to DT’s own cookies list, a mention should be made that DT also uses Safari’s cookies, and perhaps even an option to NOT USE SAFARI’S COOKIES AT ALL.
Also, if this is a means of handing over session cookies, how do you deal with the possibility that the user has an alternative browser set as their default? I would suggest that anyone used to multiple browsers on a single computer would be aware that AUTHENTICATION SESSION COOKIES ARE NOT SHARED AMONGST ALL BROWSERS. They might not understand the mechanics, but they’ll certainly understand the behavior.
I wish to apologize for the use of all caps on occasion; this issue really did frustrate me until I reached that moment of epiphany. The point that made it so maddening was that there’s no way to track which program last deleted a given file unless I run something like fseventer all the time and scrounge through the log after it may take a week or more for the problem to occur again.