To reproduce: - delete all cookies - login to bugzilla - set .kde.org cookies policy to "Always" (but not "until end of session") - restart the session - start Konqueror again Actual result: - you have to login to bugzilla again Expected result: - the login is remembered
(In reply to comment #0) > To reproduce: > - delete all cookies > - login to bugzilla > - set .kde.org cookies policy to "Always" (but not "until end of session") > - restart the session > - start Konqueror again Sorry, but this is not a bug. You changed the per domain policy too late. You need to set the policy and login to bugzilla, not the other way around. Otherwise, the cookie would be created using your default domain policy. IOW, you cannot change the policy of cookies that you already accepted using a given set of policies.
I wonder why you can click "Change Policy..." on an existing cookie then. The issue is that I just updated to latest master, and then opening bugs.kde.org I noticed that the site lost my login. It should have kept any previous cookies. Also it now often forgets the login cookie, even if I do not exit the session. I tried many things to restore it to remember my cookies, but either the dialog just crashes, or I have to login manually to the site again. It also forgets the bugzilla colum settings, which is annoying for my triaging work. I will do more checks.
> It should have kept any previous cookies. Actually, the cookies were still listed, but for whatever reason, not sent to buzilla site.
To reproduce: 1. kill konqueror and kded4 killall -9 konqueror killall -9 kded4 2. remove all cookies and cookies config: rm ~/.kde/share/apps/kcookiejar/cookies rm ~/.kde/share/config/kcookiejarrc 3. start kded4 kded4 4. start Konqueror, login to bugzilla, then exit Konqueror konqueror https://bugs.kde.org/show_bug.cgi?id=307832&GoAheadAndLogIn=1 5. after some time (5 minutes?), kded4 writes cookie config to file, wait until it appears: more ~/.kde/share/apps/kcookiejar/cookies # KDE Cookie File v2 # # Host Domain Path Exp.date Prot Name Sec Value [.kde.org] bugs.kde.org "" "/" 2145916800 0 Bugzilla_login 7 90038 bugs.kde.org "" "/" 2145916800 0 Bugzilla_logincookie 7 csvGuHWhNQ 7. restart KDE 8. check that cookies are still saved: more ~/.kde/share/apps/kcookiejar/cookies # KDE Cookie File v2 # # Host Domain Path Exp.date Prot Name Sec Value [.kde.org] bugs.kde.org "" "/" 2145916800 0 Bugzilla_login 7 90038 bugs.kde.org "" "/" 2145916800 0 Bugzilla_logincookie 7 csvGuHWhNQ 9. start Konqueror, go to bugzilla site (not login, assuming it still knows you) konqueror https://bugs.kde.org/show_bug.cgi?id=307832 Actual result: The site says you are not logged in Expected result: The site should have remembered your login
Cannot reproduce using the steps as outlined in comment #4. I works fine for me here. I tried it multiple times.
*** Bug 311975 has been marked as a duplicate of this bug. ***
I confirmed it with Bug 311975. - Create new VM Guest with Kubuntu 13.04 daily build. - Start rekonq, and login to launchpad.net, (select keep me logged in). - Close rekonq, and shut down the VM - Start the VM and open rekonq. - Go to Launchpad.net, and see you are not logged in.
Note that this is reproducible in rekonq and konqueror, but not in Google Chrome, which I assume does not use KDE's cookie handling.
If you guys are reporting these bugs against KDE 4.10 branch, then this issue is probably caused by the kconfig update not taking effect. Can anyone of you open your "kcookiejarrc" file and see if it contains any "Id=" entry ? If it does, does it have "kde4.10/git" ?
I do not have any "Id=" entries: mparillo@ubuntu:~/.kde/share/config$ cat kcookiejarrc [$Version] update_info=kcookiescfg.upd:kde2.2/b1,kcookiescfg.upd:kde3.1/cvs,kcookiescfg.upd:kde4.10/git mparillo@ubuntu:~/.kde/share/config$
That is my mistake. I wanted the "update_info" line and it contains the "kde4.10/git" entry ; so your config file was updated successfully. I dunno why you guys have this issue at this point. Can you post the contents of your "kcookiejarrc" file ? I suspect it would look ok, but might be worth checking.
Thank you for looking into this, but that was the entire contents of my kcookiejarrc file. I think I had a pretty generic Kubuntu 13.04 new installation from a recent daily build with: rekonq Version 1.80 Using KDE Development Platform 4.9.90 I only downloaded konqueror from the Ubuntu repositories to see if it shared rekonq's cookie behavior, and it did (unlike Google Chrome which handle cookies differently).
As indicated in comment #4, the issue also shows when starting without a config file.
Unchanged for rekonq Version 1.80 Using KDE Development Platform 4.9.97
commit 794b14b8af5b610fc3eed6945f93f0c69dd49a9a Author: Thiago Macieira <thiago.macieira@intel.com> Date: Fri Jan 18 19:12:34 2013 +0800 Initialise the mCrossDomain member variable in the cookies For several months now, all my cookies would be forgotten after a kded restart. After debugging the problem, turns out that mCrossDomain was of value 127, which makes no sense for a boolean. This variable has been present since 2002, which means that the "reject cross domain cookies" feature has been broken for 10 years and 8 months. http://commits.kde.org/kdelibs/794b14b8af5b610fc3eed6945f93f0c69dd49a9a
Git commit 54223f6c88edd2a2aedf4d92df3facadefe00401 by Dawit Alemayehu, on behalf of Thiago Macieira. Committed on 18/01/2013 at 12:12. Pushed by adawit into branch 'KDE/4.10'. Initialise the mCrossDomain member variable in the cookies For several months now, all my cookies would be forgotten after a kded restart. After debugging the problem, turns out that mCrossDomain was of value 127, which makes no sense for a boolean. This variable has been present since 2002, which means that the "reject cross domain cookies" feature has been broken for 10 years and 8 months. FIXED-IN: 4.10 (cherry picked from commit 794b14b8af5b610fc3eed6945f93f0c69dd49a9a) M +1 -0 kioslave/http/kcookiejar/kcookiejar.cpp http://commits.kde.org/kdelibs/54223f6c88edd2a2aedf4d92df3facadefe00401