On martedì 31 ottobre 2017 01:47:37 CET Allan Sandfeld Jensen wrote: > On Sonntag, 29. Oktober 2017 09:47:24 CET Stefano Crocco wrote: > > Hello to everyone, > > I'm working on making QWebEngine work correctly in Konqueror when > > downloading files (although I didn't have much time to spend on this in > > the > > last months). > > > > The problem is that instead of downloading the correct files, in some > > cases > > Konqueror download html files. This only happens from sites requiring > > authentication (I first noticed when trying to download a file from my > > bank's web page); besides, it only happens if I try to use KIO for the > > download, for example calling KIO::copy from a slot connected with > > QWebEngineProfile::downloadRequested. The file downloads correctly if > > Konqueror downloads it using the mechanism provided by QWebEngine, that is > > calling QWebEngineDownloaditem::accept. > > > > I believe that the issue is caused by cookies, and in particular by the > > fact that QWebEngine doesn't share its cookies with KIO so that, when KIO > > attempts to download the file, it doesn't have the cookie(s) associated > > with the session opened in the browser and the web page refuses to let it > > download the file (indeed, one of the sites where this happens returned a > > login page instead of the PDF I wanted to download). > > > > Looking at the documentation both for QWebEngine and for KIO > > regarding cookies. I found out two classes: > > * on QWebEngine's side, there's QWebEngineCookieStore, which provides > > signals emitted whenever a cookie is added or removed and which, according > > to documentation [1], "can be used to synchronize cookies of Chromium and > > the QNetworkAccessManager" > > * on KIO's side, there's KIO::Integration::AccessManager, which derives > > from QNetworkAccessManager and which should work along > > QWebEngineCookieStore. > > > > The example in the documentation for KIO::Integration::AccessManager > > refers > > to QWebView and says to call QWebPage::setNetworkAccessManager to have the > > QWebView and KIO to use the same access manager. Unfortunately, QWebEngine > > can't be integrated with a QNetworkAccessManager: not only QWebEnginePage > > doesn't have a setNetworkAccessManager method, but the documentation for > > QWebEngine explicitly says that it doesn't use QNetworkAccess. Because of > > this, I thought to do things the other way round: I created a > > KIO::Integration::AccessManager and, used slots connected with > > QWebEngineCookieStore signals, to add cookies to it. > > > > Unfortunately, this doesn't fix the issue. I believe this is because I > > haven't told KIO to use the new access manager. The problem is that I can > > see any way to do it. Does anyone have suggestions on how to do this? > > KIO has its own cookie-store separate from QNAMs cookie store. So there > are three cookie stores. QtNetwork's, KIOs, and QtWebEngine's. Of course the > easiest solution would be to let QtWebEngine handle the downloading, but > that wouldn't integrate into normal KDE download mechanisms. So you need to > bridge QtWebEngine's cookies into KIOs cookie store and ignore QtNetwork's. > > 'Allan
The problem is that I can't find any documentation on how to interact with KIO's cookie store. On KIO::AccessManager, it is stated: "IMPORTANT This class is not a replacement for the standard KDE API. It should ONLY be used to provide KDE integration in applications that cannot use the standard KDE API directly". Unfortunately, it doesn't mention which is the standard KDE API. Looking at accessmanager.cpp, I see (in the code for KIO::Integration::CookieJar) DBUS calls to the "org.kde.cookiejar5" interface. Is this the "standard KDE API"? If so, is there a place where it's documented? I think I already tried to use it to solve this problem, but without success. However, tomorrow I'll give it another try. Stefano
