Version: unknown (using KDE 3.1.94 (CVS >= 20031206), compiled sources) Compiler: gcc version 3.3.2 (Debian) OS: Linux (i686) release 2.6.1dell-optiplex After creating a 'war' (using the archive webpage konq plugin) and clicking on it I was surprised to get a question if I wanted to accept a cookie. The cookie domain was empty leading me to believe some javascript wanted to set a cookie, which, from the local HD, seemed a silly thing to ask permission for. Please make sure the cookies are always accepted when no domain is given to sent them back to.
Created attachment 4206 [details] The web archive that asks for a cookie to be accepted.
I think you misunderstood the problem here. This problem has nothing to do with the cookiejar. A site can send cookies without any "domain=" information. In that case you would get a blank domain entry. The most common examples of this are session cookies and there is no reason why cookiejar should not show you those cookies! The actual problem here is that when you were browsing the local archive (.war file), khtml attempted to download some file from a remote site or a javascript inside the HTML page attempted to set a cookie. That is the only way you would get a cookie prompt. But this is not a problem the cookiejar can and should resolve. Hmm... perhaps the cookiejar should reject cookies whose URL is "file://", but still this is not a cookiejar issue. In fact this issue seems to be more related to the caching bug reports.
> The most common examples of this are session cookies and there is no reason why cookiejar should not show you those cookies! Sorry for asking for more info; a cookie is only a security (/privacy) risk if it is ever returned to the remote host, agree? A cookie that has no domain= info and comes from something like file:// (i.e. no http) _can_ not be returned to any remote host because we strictly disallow cross-site cookie exploits. Right? If it is not a security risk, kcookiejar should not ask the user to set the thing; it should just set it. Isn't that the problem in kcookiejer? If the problem occurs elsewhere; please create a new bugreport or reassign this one. Thanx.
> a cookie is only a security (/privacy) risk if it is ever returned to the > remote host, agree? Correct > A cookie that has no domain= info and comes from something like file:// > (i.e. no http) _can_ not be returned to any remote host because we strictly > disallow cross-site cookie exploits. Right? Yes and no. Yes, we do not allow cookies from file to be sent to any site, but it has nothing to do with cross-site cookie exploits. It is simply because the file:// URLs hostname will not match that of any other remote site... > If it is not a security risk, kcookiejar should not ask the user to set the > thing; it should just set it. Isn't that the problem in kcookiejer? You mean it should simply ignore it since the cookie is useless, no ? Anyways, the cookiejar should reject all cookies if the protocol is file:// or the hostname is empty since hostname information is a requirement for dealing with cookies. Already put in the check for this in kio_http_experimental branch. Will see about backporting it...
This bug is still visible in 3.5 branch
Interesting - compare this with Bug 110248, which -asks- for file:/// cookies to work :)
The real bug to me is that the dialog pops up asking for cookies to be accepted or not. And it pops up every time. I don't care either way if the cookies are accepted or send to the file:// so bug 110248 is not incompatible AFAICT :)
Aye, silently accepting all local cookies would solved both request. I am not sure if local cookies should be treated differently, though. Think testing an application locally and wanting to test without cookies, not wanting to leave a trace of using a local application or similar. Not extremely likely and one should design for the common case, but the common case is 'anything wants to set a cookie', not 'a local resource wants to set a cookie'. PS: By local, I mean file-based, not localhost, of course.
(In reply to comment #7) > The real bug to me is that the dialog pops up asking for cookies to be accepted > or not. And it pops up every time. I don't care either way if the cookies are > accepted or send to the file:// This bug is still really annoying nearly 4 years later, in KDE 4.7.4! My locally installed Qt documentation insists on setting cookies (__utma et al) - which itself is silly. It asks me EVERY SINGLE TIME. The online Qt documentation doesn't have this problem because the domain is non-empty. I told it to reject all cookies from this (empty) domain. It still tasks me EVERY SINGLE TIME. I told it to accept all cookies from this domain. It still tasks me EVERY SINGLE TIME. I don't care whether the cookies are accepted or not either. I just want it to stop asking all the time. I should also point out that Rekonq suffers from the same problem. Steve
We have very little usecases where this issue is hit, so lowering prio.