Furthermore isn’t it a bit of a conflict if we have multiple versions of Foundation running apps on a server? I would expect that the mutable state of cookies should never be shared across processes not just from a security standpoint but also from a versioning standpoint.
Let have a scenario where there are two web apps running on the same server. They should never share data between them unless specifically allowed to. Service A uses Foundation version A and service B uses version B. Unless service A and B have privileges to communicate they should never use common storage for cookies or preferences. This could allow service A to inappropriately use the stored credentials of service B if they are stored in the same directory. Moreover if the version B of Foundation has some refinement to the storage version of the cookie the file may be incompatible with Foundation A’s reading schema. In my opinion the directories should be unique to the services running unless they share a system based privilege system that is a common version (e.g. they are allowed to talk to each other and are not sandboxed apart). Of course some of this could be side-stepped by having the services running as different users. But the versioning issue still occurs and should perhaps be something that we consider. > On Nov 14, 2016, at 9:44 AM, Tony Parker via swift-corelibs-dev > <swift-corelibs-dev@swift.org> 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. > > - Tony > >> On Nov 14, 2016, at 1:43 AM, Pushkar N Kulkarni via swift-corelibs-dev >> <swift-corelibs-dev@swift.org <mailto:swift-corelibs-dev@swift.org>> wrote: >> >> Thanks Will! >> >> "NSHomeDirectory() + "/.foundation/Cookies/shared" seems good to me >> >> Pushkar N Kulkarni, >> IBM Runtimes >> >> Simplicity is prerequisite for reliability - Edsger W. Dijkstra >> >> >> >> -----Will Stanton <willstant...@yahoo.com <mailto:willstant...@yahoo.com>> >> wrote: ----- >> To: Pushkar N Kulkarni/India/IBM@IBMIN >> From: Will Stanton <willstant...@yahoo.com <mailto:willstant...@yahoo.com>> >> Date: 11/08/2016 08:45AM >> Cc: swift-corelibs-dev <swift-corelibs-dev@swift.org >> <mailto:swift-corelibs-dev@swift.org>> >> Subject: Re: [swift-corelibs-dev] Implementing HTTPCookieStorage >> >> Was wondering if there could be a common directory for Foundation-related >> files, such as NSUserDefaults in addition to cookie storage? >> >> So maybe for cookies: >> NSHomeDirectory() + "/.foundation/Cookies/shared" >> >> And settings for an app/service: >> NSHomeDirectory() + "/.foundation/Preferences/EXECUTABLE_NAME.plist" >> >> >> And I’m not familiar with how Apple Foundation/CFNetwork/nsurlsessiond >> handles cookies… or caches things, but I think I agree with Kenny that >> naming symmetry would be nice if there is a per-user cookies file. >> >> So having a /Library may be nicer, but potentially unnecessary? >> NSHomeDirectory() + "/.foundation/Library/Cookies/Cookies.something" >> >> Regards, >> Will Stanton >> >> > On Nov 7, 2016, at 5:45 PM, Tony Parker via swift-corelibs-dev >> > <swift-corelibs-dev@swift.org <mailto:swift-corelibs-dev@swift.org>> wrote: >> > >> > Hi Pushkar, >> > >> > Good question. If this were Darwin I guess I would say >> > ~/Library/Application Support — but I don’t know what the best practices >> > are on other platforms. Does anyone out there have some suggestions? >> >> >> _______________________________________________ >> swift-corelibs-dev mailing list >> swift-corelibs-dev@swift.org <mailto:swift-corelibs-dev@swift.org> >> https://lists.swift.org/mailman/listinfo/swift-corelibs-dev > > _______________________________________________ > swift-corelibs-dev mailing list > swift-corelibs-dev@swift.org > https://lists.swift.org/mailman/listinfo/swift-corelibs-dev
_______________________________________________ swift-corelibs-dev mailing list swift-corelibs-dev@swift.org https://lists.swift.org/mailman/listinfo/swift-corelibs-dev
