[dev] surf cookies handling bug and cookiejar patch

From: <carlosjosepita_AT_gmail.com>
Date: Fri, 9 Jul 2010 17:06:18 -0300

Hi all,

I've been having problems to use gmail -just like others- and the
google pdf quick view -I haven't seen another report about this one-
with surf. Besides the session management issues, surf is not updating
cookies that are created by javascript running in the current page.
Notice v.g. that uzbl, which supports the two of the aforementioned
webapps, handle both cases of cookie creation:

g_object_connect(G_OBJECT(uzbl.net.soup_cookie_jar), "signal::changed", G_CALLBACK(save_cookies_js), NULL, NULL);
save_cookies_http(SoupMessage *msg, gpointer user_data) {
save_cookies_js(SoupCookieJar *jar, SoupCookie *old_cookie, SoupCookie
*new_cookie, gpointer user_data) {

Where soup_cookie_jar is the basic, non persistent, SoupCookieJar.
Anyway, I don't like this approach, I think they do it like this
because they want to allow for external customizable handlers for every
imaginable event. That way they implement cookie persistence a layer
above the C core.

But the customary cookiejar mechanism in webkit takes care of everything
by just registering it as a feature of the session. Except for file
locking, which is sine qua non for surf :(. So I decided to "subclass"
SoupCookieJarText in order to add some needed decoration: file locking
and sessiontime management. It's about 60 lines of OO-wannabe
GObject-boilerplate and 3 lines of directly useful code, but I think
it's a cleaner approach than trying to intercept all cookie related
events. Besides, it removes about 60 lines of cookie handling (for a
net amount of 0 lines), it leverages the webkit cookiejar feature and it
solves the aforementioned bugs.

Well, just HIH someone else.

Best regards


Received on Fri Jul 09 2010 - 22:06:18 CEST

This archive was generated by hypermail 2.2.0 : Fri Jul 09 2010 - 22:12:02 CEST