I've actually learned a bit more about this since my last post in March 2008.
Turns out there are some hooks in the WebKit api that could be used to circumvent the Shared Cookie Storage. These hooks are not really designed for that purpose exactly, but they could be used in that way. Basically it's possible to intercept all webview requests and responses in a particular delegate method and tinker with their cookies. this would require implementing my own local cookie store for storing the cookies and associating them with URL patterns. I believe there may be some 3rd party apps out there now that do this, but I'm not sure. The good news here is that this would not require swapping out the HTTP stack as I postulated above. The bad news is that this is still a ton of difficult work. and not just difficult but also very prone to serious serious serious security issues. implementing your own cookie store in a general purpose web browser is like navigating a security minefield. at this time i'm absolutely not willing to take on this kind of security risk for myself and my users in a free app. If I ever implement this kind of feature, it will definitely be for pay, not for free. for now, I have no plans to do this. In fact I actively don't want to attempt it. at all. There is some hope though. I suspect that eventually WebKit may implement this kind of functionality itself. It would be nice if there were some very high level way to say: 'hey webkit, use separate cookies, kthx'. that may still happen. And then I would have wasted many manhours implementing my own scheme. The other possibility is that some other 3rd party developers may build this kind of system as open source (either into WebKit itself or as an add-on as described above), and Fluid could adopt it. i have heard some rumblings about that, but i know of no progress (let me know if you do). anyhow, that's the current story on separate cookies in Fluid apps. it sucks, i know. TD On Tue, Mar 11, 2008 at 5:01 PM, <[email protected]> wrote: > > I agree, separate cookie jars for each SSB created by Fluid would be a > killer feature. And I am still hopeful that I'll be able to make that > happen at some point. However, there are serious roadblocks to making > this happen. Here's the problem: > > Fluid uses WebKit for web rendering. WebKit is open source. > > By default, WebKit uses the CFNetwork stack from Apple for HTTP > networking. CFNetwork is not open source > > Turns out that the CFNetwork stack does all of the cookie handling, > and this is transparent to WebKit (which makes sense if you think > about it). CFNetwork stores the cookies in a global shared cookie > storage that all WebKit-based applications use called + > [NSHTTPCookieStorage sharedCookieStorage]. I've actually done quite a > bit of work in this area, see my free app Cocoa Cookies: > http://ditchnet.org/cocoacookies. > > I've asked the WebKit team about this, and AFAICT, its not really > possible to hack on WebKit and isolate cookie sharing without > replacing the entire networking stack. Please correct me if I'm wrong, > but very senior WebKit people I've talked to have told me this. > Replacing the entire HTTP networking stack used by WebKit is a very > large and complicated task... probably not one that a single developer > should tackle alone, and certainly not one that I am currently up to. : > 0[ > > Unfortunately, the reality is that this feature will just *not happen* > in the foreseeable future. I'm always open to suggestions, however. If > you can come up with an ingenious hack to work around this, I'm all > ears. Alternatively, if anyone wants to volunteer to work on WebKit to > make it easier to swap out modular HTTP stacks, maybe that would be > interesting too, but certainly a large project. > > The only other solution I've heard floated is to use some kind of > poseAs: hack as NSHTTPCookieStorage with a custom class that actually > stores the cookies separately. I'm not sure if this is feasible or > not... but I'm open to suggestions/advice in that area. Alternatively > if anyone is really keen and wants to implement something like that > with a BSD- or MIT-style license, I'll happily include it into Fluid > for all to use. (but keep in mind that Fluid is closed source). > --~--~---------~--~----~------------~-------~--~----~ > You received this message because you are subscribed to the Google Groups > "fluidapp" group. > To post to this group, send email to [email protected] > To unsubscribe from this group, send email to > [email protected] > For more options, visit this group at > http://groups.google.com/group/fluidapp?hl=en > -~----------~----~----~----~------~----~------~--~--- > > -- You received this message because you are subscribed to the Google Groups "fluidapp" group. To post to this group, send email to [email protected]. To unsubscribe from this group, send email to [email protected]. For more options, visit this group at http://groups.google.com/group/fluidapp?hl=en.
