Version: 3.3 (using KDE 3.3.0, Gentoo) Compiler: gcc version 3.3.3 20040412 (Gentoo Linux 3.3.3-r6, ssp-3.3.2-2, pie-8.7.6) OS: Linux (i686) release 2.6.8-gentoo-r3 I have a FTP link in my bookmarks with a password included (like ftp://user:pass@host/path) Pressing the link works well, the ftp site opens imediately without having to enter a password. Using the back button also works, but as soon as I press the "up" button, Konqueror asks for a password again.
SVN 3.5 of April 7th opening a sftp kio works fine, also somtimes the password dialog filled with the correct userid/password pops up and asks for confirmation. IMHO the password dialog should be suppressed for all URLS of the same [host:port] for real transparency. A ONE time identification should be enough. (Note: A different port (not 22) is definend for ssh access on my firewall) Tthis is specially true for opening sftp-files with kate. "keep password" keeps the password, but the password dialog pop ups again and again even opening the same file.
I can reproduce this in both Konqueror 3.5.9 and 4.0.4. When the up button is pressed for the first time, the password is asked. After that (at least in my brief testing rounds) the password is not asked again. Off-topic comment to comment #1: While I tested the sftp:// kioslave, the password was not asked even when moving up. It also wasn't asked when opening files.
Here's the steps to reproduce once again, if they weren't clear enough in the initial posting: 1. Log in to a FTP site using ftp://user:pass@ftp.example.com 2. Click into a subdirectory 3. Press the up button Result: Password dialog opens Expected result: The password is not asked again.
Is this with or without checking on the "remember password" checkbox? Hmm, I can't reproduce the bug either way (using 4.1.1-soon-4.1.2). Does the command "qdbus org.kde.kded" list a line saying /modules/kpasswdserver? (It should, it's the module which stores passwords)
I can't reproduce this anymore with KDE 4.1.2. (note the original report is about KDE 3).
being unable to reproduce this bug too, I think we can consider this as fixed in KDE4. KDE 3 version of konqueror is no more mantained so this bug can be closed.