Bug 108052 – Expose WebContext::setCookieStorageDirectory() to Qt API

• Status: RESOLVED
• Resolution: INVALID
• Component: WebKit Qt

[Alberto Mardegan]

Use case: a client wanting to provide the user the possibility of browsing the internet under different user identities, where the cookies obtained while browsing under one identity would be kept completely separate from those from other identities.
In our specific case, we need this trick for the Ubuntu Online Accounts project, where we provide web-based authentication to user applications; and supporting multiple user accounts for the same provider is an important use case for us.

If my understanding of the WebKit UIProcess is correct, this could be achieved by calling WebContext::setCookieStorageDirectory() before starting the navigation, and specifying a different cookie storage directory every time that the user changes identity.

However, this functionality is not exposed in the Qt API. This bug, therefore, is about adding a "cookieStorageDirectory" property to the QQuickWebViewExperimental class. Please let me know if there are objections to this addition, otherwise I will start working on the implementation (unless someone more familiar with webkit development volunteers to work on this).

[Jocelyn Turcotte]

I didn't read deeply through the code, but a comment in Source/WebKit2/UIProcess/API/C/WKContextPrivate.h says:
// FIXME: These functions are only effective if called before the Web process is launched. But
// we should really change these settings to be on WebPreferences and changeable at runtime.

So you would have to fix this first, else you might notice that WKContextSetCookieStorageDirectory won't have any effect unless you kill the process.

You also shouldn't need to move it to the public C API to be able to use it from the Qt API, this is the public API in our case.

[Alberto Mardegan]

(In reply to comment #1)
> I didn't read deeply through the code, but a comment in Source/WebKit2/UIProcess/API/C/WKContextPrivate.h says:
> // FIXME: These functions are only effective if called before the Web process is launched. But
> // we should really change these settings to be on WebPreferences and changeable at runtime.
> 
> So you would have to fix this first, else you might notice that WKContextSetCookieStorageDirectory won't have any effect unless you kill the process.

I see. In my case it might not be something I would worry about, as I would set this setting only when instantiating the WebView and I wouldn't change it later -- but I see that it could be a problem. 

I've been trying to follow the execution flow to find out what pieces I need to change, and so far I've come up with these:

- WebCore/page/settings.in (definition of the cookieStorageDirectory preference)
- WebKit2/Share/WebPreferencesStore.h (setter and getters)
- WebCore/platform/network/qt/CookieJarQt.cpp (implementation of the cookie jar)

However, I still didn't figure out how the CookieJarQt class could access the value of cookieStorageDirectory from the WebPreferences and how to get notified of its changes.
I see that the WebProcess receives the PreferencesDidChange message and processes it by updating the preferences in the WebCore::Settings object, but I don't understand how and when the CookieJarQt object could pick the setting from there. Can someone help me with this?

[Jocelyn Turcotte]

(In reply to comment #2)
> (In reply to comment #1)
> > I didn't read deeply through the code, but a comment in Source/WebKit2/UIProcess/API/C/WKContextPrivate.h says:
> > // FIXME: These functions are only effective if called before the Web process is launched. But
> > // we should really change these settings to be on WebPreferences and changeable at runtime.
> > 
> > So you would have to fix this first, else you might notice that WKContextSetCookieStorageDirectory won't have any effect unless you kill the process.
> 
> I see. In my case it might not be something I would worry about, as I would set this setting only when instantiating the WebView and I wouldn't change it later -- but I see that it could be a problem. 

The thing is that WebContext applies to all web view. The context is destroyed after the last web view closed, but still waits something like 30 seconds before closing the WebProcess. So this would ultimately force you to restart your whole UI process as well to work around this, probably not what you want.

> 
> I've been trying to follow the execution flow to find out what pieces I need to change, and so far I've come up with these:
> 
> - WebCore/page/settings.in (definition of the cookieStorageDirectory preference)
> - WebKit2/Share/WebPreferencesStore.h (setter and getters)
> - WebCore/platform/network/qt/CookieJarQt.cpp (implementation of the cookie jar)
> 
> However, I still didn't figure out how the CookieJarQt class could access the value of cookieStorageDirectory from the WebPreferences and how to get notified of its changes.
> I see that the WebProcess receives the PreferencesDidChange message and processes it by updating the preferences in the WebCore::Settings object, but I don't understand how and when the CookieJarQt object could pick the setting from there. Can someone help me with this?

The issue is that WebPreference applies on a WebPage level, and this wouldn't make sense for the cookie jar, which applies to all pages. There is no mechanism currently, as far as I know, to update WebContext/WebProcess parameters after the web process creation.

We also make sure that all other WebKit2 ports are updated if we change the way this behaves.