Bug 323663 - Password is not stored
Summary: Password is not stored
Status: RESOLVED WORKSFORME
Alias: None
Product: kdelibs
Classification: Frameworks and Libraries
Component: kdewebkit (show other bugs)
Version: 4.10.5
Platform: openSUSE Linux
: NOR normal
Target Milestone: ---
Assignee: webkit-devel
URL:
Keywords:
: 297799 (view as bug list)
Depends on:
Blocks:
 
Reported: 2013-08-18 07:07 UTC by Volker Kuhlmann
Modified: 2023-02-09 03:54 UTC (History)
2 users (show)

See Also:
Latest Commit:
Version Fixed In:
Sentry Crash Report:


Attachments
screenshot (214.40 KB, image/png)
2013-08-28 12:37 UTC, Dawit Alemayehu
Details

Note You need to log in before you can comment on or make changes to this bug.
Description Volker Kuhlmann 2013-08-18 07:07:34 UTC
On pages which require a password to be entered the password is not stored by kwallet - konqueror doesn't even ask to store it.
Entering it manually into kwallet does nothing - konqueror doesn't fill it in.

This has last worked with konqeuror3 and it's very irritating!

Reproducible: Always

Steps to Reproduce:
1. https://lists.sourceforge.net/lists/admindb/smartmontools-database
2. Enter some random stuff
3.
Actual Results:  
konqueror fails to ask to store the password in kwallet.

Expected Results:  
Password is stored in kwallet and retrieved from there.
Comment 1 Dawit Alemayehu 2013-08-22 11:56:39 UTC
Which browser engine are you using? Do you have this problem only for this site or every website where you enter your credentials?
Comment 2 Volker Kuhlmann 2013-08-22 12:33:07 UTC
webkit - the default. khtml stopped being functional on too many websites a long time ago.

I am seeing this problem on a number of sites and will start making a list. It was much worse on KDE 4.7.2, but has not been solved completely. konqueror 3 never had this problem.

There are websites now setting a "do not store these passwords" flag so browsers need a corresponding "ignore this nonsense" setting, but I didn't think sourceforge uses it. I used to use konqueror 3 for sourceforge because passwords worked.
Comment 3 Dawit Alemayehu 2013-08-23 01:16:30 UTC
(In reply to comment #2)
> webkit - the default. khtml stopped being functional on too many websites a
> long time ago.

> I am seeing this problem on a number of sites and will start making a list.
> It was much worse on KDE 4.7.2, but has not been solved completely.
> konqueror 3 never had this problem.

Right. Providing actual sites means I can see if I can reproduce the problem or not. And unfortunately some of the remaining sites will never be completely in the short term because of very difficult technical reasons. For example see https://bugs.kde.org/show_bug.cgi?id=287689.

> There are websites now setting a "do not store these passwords" flag so
> browsers need a corresponding "ignore this nonsense" setting, but I didn't
> think sourceforge uses it. I used to use konqueror 3 for sourceforge because
> passwords worked.

I can tell you that the wallet integration for kdewebkit honors the autocomplete attribute for input elements and the fact that there is no way for the user to override that functionality is a known issue. See https://bugs.kde.org/show_bug.cgi?id=322270. Having said that, I cannot reproduce the problem at sourceforge. I tested it by purposefully filling in the login form with bogus login information I was prompted to save the password.
Comment 4 Volker Kuhlmann 2013-08-23 03:45:16 UTC
Thanks! Also for the two reportlinks, bug#322270 is also what I am seeing.

My take on autocomplete="off" is that it was invented for protecting less capable users from themselves (to put it politely). That browsers, especially Linux ones, get the capability to deal with the changing times (and not just by turning the KDE wallet subsystem into a pumpkin) can be called an ehancement request, not a bug. I see that that is a technical problem because of the number of parts involved by different projects. Thanks muchly for the explanartion in bug#322270!

In this particular case konqueror does not ask me to store the password; possibly because it is already stored. This comes from a KDE 3 .kwl file I copied over, and me entering URLs and passwords anually into kwallet in an attempt to get this to work with 4.7.2.
Unfortunately the password does not get filled in by konqueror either.
I checked and that sourceforge mailman page does not use the autocomplete attribute or javascript, and looks like straight html to me.
konqueror neither asks to store the password or fills it in, so for me it's a bug.
If you can suggest more things to test I will do so.
Comment 5 Volker Kuhlmann 2013-08-28 11:16:03 UTC
https://lists.sourceforge.net/lists/admindb/smartmontools-support
Does not ask me to store a password. I had cleared all my existing entries for lists.sourceforge.net/lists/admindb from the wallet. That page is very trivial - no scripts, nothing much to it. I don't understand why the password storage doesn't work.
Comment 6 Dawit Alemayehu 2013-08-28 12:37:13 UTC
(In reply to comment #5)
> https://lists.sourceforge.net/lists/admindb/smartmontools-support
> Does not ask me to store a password. I had cleared all my existing entries
> for lists.sourceforge.net/lists/admindb from the wallet. That page is very
> trivial - no scripts, nothing much to it. I don't understand why the
> password storage doesn't work.

It does for me. See the attached screenshot. Have you clicked on never for this site by mistake before? Do you see a little wallet icon on the bottom right corner of Konqueror's status bar when you visit that page? If so, right click on it and if you see "Allow password caching for this site", then that means you have asked for the password not to be remembered at some point in the past. Click on that option to allow password to be stored going forward. Otherwise, I dunno what to tell you. Perhaps you might want to check you wallet settings to make sure you did not accidentally forbid Konqueror from using it?
Comment 7 Dawit Alemayehu 2013-08-28 12:37:43 UTC
Created attachment 81992 [details]
screenshot
Comment 8 Volker Kuhlmann 2013-08-28 20:17:56 UTC
Hi Dawit, thanks muchly, you did something very valuable - you showed that it is supposed to work, so I started looking elsewhere. No such wallet symbol in the bottom right, and passwords work for some few sites in my konqueror.
With a new user account it works indeed as expected, so I started changing the browser settings. I can only regard browsing all sites with java turned on as brain-dead, and I won't browse with javascript turned on everywhere either (although the white-list in konqueror is pretty cumbersome).
Passwords will not be stored or filled on lists.sourceforge.net after I turned javascript off. White-listing this domain only makes passwords work again there. However, as best as I can tell, there is no javascript whatsoever on that site.
As a very wild guess, is it possible that the password handling requires javascript? And with webkit, that's obeying the permissions from the preferences even though the sites does not use javascript? I.e., konqueror won't store/insert passwords unless javascript is enabled for that domain? ARRRGHHHH!!!!! I'd see that as a bug.
Comment 9 Dawit Alemayehu 2013-10-10 11:09:14 UTC
(In reply to comment #8)
> Hi Dawit, thanks muchly, you did something very valuable - you showed that
> it is supposed to work, so I started looking elsewhere. No such wallet
> symbol in the bottom right, and passwords work for some few sites in my
> konqueror.
> With a new user account it works indeed as expected, so I started changing
> the browser settings. I can only regard browsing all sites with java turned
> on as brain-dead, and I won't browse with javascript turned on everywhere
> either (although the white-list in konqueror is pretty cumbersome).
> Passwords will not be stored or filled on lists.sourceforge.net after I
> turned javascript off. White-listing this domain only makes passwords work
> again there. However, as best as I can tell, there is no javascript
> whatsoever on that site.
> As a very wild guess, is it possible that the password handling requires
> javascript? And with webkit, that's obeying the permissions from the
> preferences even though the sites does not use javascript? I.e., konqueror
> won't store/insert passwords unless javascript is enabled for that domain?
> ARRRGHHHH!!!!! I'd see that as a bug.

Yes, unfortunately password management requires the Javascript to be enabled in kdewebkit. That is because the built-in API does not work under all circumstances and my effort to have that issue resolved upstream did not pan out. See https://bugs.webkit.org/show_bug.cgi?id=63603. As a result, we use javascript to find and fill out forms on web pages.
Comment 10 Dawit Alemayehu 2013-12-15 13:35:44 UTC
*** Bug 297799 has been marked as a duplicate of this bug. ***
Comment 11 Andrew Crouthamel 2018-11-11 04:21:07 UTC
Dear Bug Submitter,

This bug has been stagnant for a long time. Could you help us out and re-test if the bug is valid in the latest version? I am setting the status to NEEDSINFO pending your response, please change the Status back to REPORTED when you respond.

Thank you for helping us make KDE software even better for everyone!
Comment 12 Andrew Crouthamel 2018-11-21 04:36:33 UTC
Dear Bug Submitter,

This is a reminder that this bug has been stagnant for a long time. Could you help us out and re-test if the bug is valid in the latest version? This bug will be moved back to REPORTED Status for manual review later, which may take a while. If you are able to, please lend us a hand.

Thank you for helping us make KDE software even better for everyone!
Comment 13 Justin Zobel 2023-01-10 01:52:24 UTC
Thank you for reporting this issue in KDE software. As it has been a while since this issue was reported, can we please ask you to see if you can reproduce the issue with a recent software version?

If you can reproduce the issue, please change the status to "REPORTED" when replying. Thank you!
Comment 14 Bug Janitor Service 2023-01-25 05:05:46 UTC
Dear Bug Submitter,

This bug has been in NEEDSINFO status with no change for at least
15 days. Please provide the requested information as soon as
possible and set the bug status as REPORTED. Due to regular bug
tracker maintenance, if the bug is still in NEEDSINFO status with
no change in 30 days the bug will be closed as RESOLVED > WORKSFORME
due to lack of needed information.

For more information about our bug triaging procedures please read the
wiki located here:
https://community.kde.org/Guidelines_and_HOWTOs/Bug_triaging

If you have already provided the requested information, please
mark the bug as REPORTED so that the KDE team knows that the bug is
ready to be confirmed.

Thank you for helping us make KDE software even better for everyone!
Comment 15 Bug Janitor Service 2023-02-09 03:54:00 UTC
This bug has been in NEEDSINFO status with no change for at least
30 days. The bug is now closed as RESOLVED > WORKSFORME
due to lack of needed information.

For more information about our bug triaging procedures please read the
wiki located here:
https://community.kde.org/Guidelines_and_HOWTOs/Bug_triaging

Thank you for helping us make KDE software even better for everyone!