I seem to frequently encounter the problem where some of my cookies get lost. My suspicion is that the various WebKit instances that are running sometimes clobber each other's cookie updates. I generally have Safari open along with three Fluid instances, and a few other apps that use WebKit as well (NetNewsWire, Adium).
I don't think the problem is specific to Fluid, but I imagine having more instances does exacerbate it. If you have any influence with the WebKit folks, I hope you can strongly encourage them to move in the direction of separate cookies. Keeping them all together just doesn't work, and it's been broken (IMHO) for a long a time now. On Nov 30, 4:42 pm, Todd Ditchendorf <[email protected]> wrote: > 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 > > athttp://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.
