[prev in list] [next in list] [prev in thread] [next in thread] 

List:       konq-bugs
Subject:    [Bug 280277] defective password handling (old password can't be
From:       Dawit Alemayehu <adawit () kde ! org>
Date:       2011-09-27 15:45:52
Message-ID: E1R8Zqy-0002Gw-4u () bugs ! kde ! org
[Download RAW message or body]

https://bugs.kde.org/show_bug.cgi?id=280277





--- Comment #3 from Dawit Alemayehu <adawit kde org>  2011-09-27 15:45:51 ---
(In reply to comment #2)
> I just tried it, and it worked (though see below): But that is very-well hidden
> --- It never occurred to me that any action would be associated we any of these
> tiny symbols, and I don't think there is anything about it in the Handbook
> (available under Help), nor could I find anything about this in the
> Internet (by a general search). And then *only* a right-click does something ... 
> well hidden.

Those options and icons are part of the browsing rendering engine which
konqueror embeds and not konqueror itself. In your case you seem to be using
KHTML as the default browsing engine, "Settings->Configure Konqueror->Default
web browser engine". Otherwise, a left click on the said icon should launch the
Wallet management tool if it is installed on your system.

> Perhaps something explicit could happen at the time when the
> password is entered; best, perhaps(!), if Konqueror would detect the
> password failure and would then offer a menu.

There is no way for the rendering engine, which is embeded into konqueror, to
know when a login at a remote site failed unless it uses something hacky and
even then it won't work properly all the time ; so no this is not a possiblity.

> Better, the password-related action must make it into the main menus, a
> new entry "Password handling". I think it is about *explicit* action,
> controlled by the user (it just doesn't work too many times, the clever
> hidden actions, hiding everything under the hood).

You mean hidden in plain site ? Anyhow, those icons on the bottom are not there
for decoration, they must serve a purpose, right ? I do however agree that
there might be lack of documentation, but that is why there are many support
forums where you could easily ask this question and get an answer.

> As I said originally, in my understanding the best solution (ever) is just
> to make all configuration file-based, with the possibility to edit the files.
> Just compare how easy it is to do all sorts of configurations with git ---
> no need to search for anything, but just go to .git/config !

Hmm... you just claimed about how difficult it was to find the option and now
you advocate we hide it in some obscure file which the user has to manipulate
manually ? How does that make sense ? 

Anyhow, this cannot be done simply because the passwords are stored in an
encrypted file. However, the wallet comes with its own management application
tool that you can use to modify and delete passwords for any website. If this
tool is installed on your system, you can simply lanuch it by typing
kwalletmanager in KRunner (ALT+F2) or alternatively you can click on
K->Applications->System->Wallet Management Tool. The passwords by default
should be located under  "Form Data->Maps" in the "kdewallet" wallet.

> Another example for the superiority of an explicit configuration
> management via files (which would also be always the same --- for all
> KDE applications!) comes now, that I have successfully deleted the password
> on the site mentioned above --- I can't store the new one now! Since the
> site quickly changes to a different page, the little menu with "store" etc.
> appears only for such a short time, that although I tried at least 10 times
> (really) there is no chance to press on that button. The back-button doesn't
> work. If there would be a file-based configuration, then I would just add
> an explicit entry for that website, and that would be it.

That is a bug in the rendering engine of your choice, pure and simple. Sorry,
but modifying a configuration file is not a superior approach simply because of
a bug in the current implementation. You should open a bug report against the
rendering engine that you are currently using and have that issue addressed. I
cannot reproduce this problem here, but I only tested it with the WebKit
rendering engine.

> Or, with a menu-entry "Password handling", likely best under "Tools", there
> should be an explicit action for storing passwords.

That is possible so long as someone steps up to write the necessary plugin. All
the items you see under Tools in Konqueror are plugins/extensions that are
outside of Konqueror.

> In any case, it seems very strange to me that that these buttons for storing
> passwords are affected in any way by the actions of the website --- it is a
> Konqueror-internal thing, and thus should be completely unaffected by anything
> which happens on the webpage. (And, by the way, these buttons etc. should
> give more explicit information: At least which URL (or is it a regular
> expression) is concerned, to inform the user. All that missing information,
> it is so tedious (and actually depressing -- brave new world).)
> 
> I finally just managed to press quickly enough on the store-button, to get it
> all working again (as I said, more than 10 trials). I don't think that many
> elderly persons for example would be able to move the mouse quickly and
> precisely enough.
> Quite an amount of work ...

Again that is a bug and you should open a bug report against the appropriate
rendering engine. In this case it seems to be KHTML, but you can find out what
you are using through the steps mentioned above.

> In any way, the whole issue here then should likely be moved to user-interface
> issues.

-- 
Configure bugmail: https://bugs.kde.org/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the assignee for the bug.
_______________________________________________
Konq-bugs mailing list
Konq-bugs@kde.org
https://mail.kde.org/mailman/listinfo/konq-bugs
[prev in list] [next in list] [prev in thread] [next in thread]