No sharing cookies

[Guillaume]

Hey!
I'have just notice that Fluid is sharing cookies with Safari.
I have too gmail account and would like to use one with Fluid. If I'm
already log-on on the the other one with safari, I just can't use a
specific gmail account with fluid. It's flip from to the other each
time.

So... my feature request is: make cookies specific to each Fluid app!

[todd.dit...@gmail.com]

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).

[Todd Ditchendorf]

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

> --~--~---------~--~----~------------~-------~--~----~
> You received this message because you are subscribed to the Google Groups "fluidapp" group.
> To post to this group, send email to flui...@googlegroups.com
> To unsubscribe from this group, send email to fluidapp-u...@googlegroups.com
> For more options, visit this group at http://groups.google.com/group/fluidapp?hl=en
> -~----------~----~----~----~------~----~------~--~---
>
>

[Luke Andrews]

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 <todd.ditchend...@gmail.com>
wrote:

[Todd Ditchendorf]

On Wed, Dec 2, 2009 at 2:07 PM, Luke Andrews <attab...@gmail.com> wrote:
> 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.

i doubt i have much, but i will try. I have filed an Enhancement
Request on the WebKit.org bugzilla here:

http://tod.nu/cookies

if you have something valuable to add to that issue, please feel free
to add comments. Please do me a favor and be POLITE if you do so.
Remember, the WebKit folks have provided us all with the best web
rendering engine on the planet. for free. they deserve our respect.

thanks,

TD