[swift-corelibs-dev] Implementing HTTPCookieStorage

[Will Stanton]

Hello Tony and Philippe,

I don’t think it would be odd for cookie/setting files to be in a folder named after Foundation (namely ~/.foundation):
- The files are owned by Swift/Linux Foundation in the sense Foundation writes them, and Foundation is the only one that should access them directly. Foundation should enforce security.
- On macOS, settings seem to be written to ~/Library/Preferences/$(BUNDLE_ID).plist, and the proposed ~/.foundation/Preferences/EXECUTABLE_NAME.plist isn’t that different.
‘.foundation’ is used in lieu of a library directory, and I feel this is acceptable so as not to clash with any user ~/Preferences or ~/Library directory.  I am OK with the ‘Foundation ownership’ per above.
And, executable name seems reasonable in lieu of bundle ID.

I noted something like ~/.foundation/Library/Preferences/EXECUTABLE_NAME.plist may be desirable to keep symmetry/reuse more CF code, but changing Swift CF is probably necessary anyway and better (fewer search paths to loop through, possibly less I/O).


Am interested in alternatives of course :-)
- But having separate folders for each app seems complicated, ex. '~/.app1/Preferences’ ‘~/.app2/Preferences’ pollutes home.
- I don’t really mind the name of an encapsulating folder, .foundation or otherwise.
- Placing system configuration files in /etc is a norm, but I think I’d feel more comfortable with Swift app settings in /home/user (easier to keep track of, and I can delete the whole thing without consequences*). I’m also not writing any real low-level services in Swift… but others probably are… but they probably have their own code to write config data to /etc!


To Philippe’s points about security+future-proofing:
Perhaps the cookie file could be named per version of its format:
~/.foundation/Cookies/shared initially
When we have a new format:
~/.foundation/Cookies/shared2, shared3, etc? Or even pick a new name entirely?

I also think it should be up to Swift Foundation to enforce cookie security on a per-app/family basis (the latter requires changes to the package structure?).
Perhaps for now, it is possible to save the hash and name of the executable storing a cookie? And Foundation can load cookie storage only if the executable name and file haven’t changed? (Is that an unnecessary pain?)

Regards,
Will Stanton

> On Nov 14, 2016, at 12:44 PM, Tony Parker <anthony.parker at apple.com> wrote:
> 
> Isn’t it a bit odd to use ‘.foundation’ as the name of the directory, when Foundation is just one of the libraries involved? On Darwin, the prefs are organized by application, not by framework.