Advice request on how to handle change in how Konqueror stores login information

[Steven Robbins]

On Sunday, September 22, 2024 2:10:52 A.M. CDT Stefano Crocco wrote:
> On sabato 21 settembre 2024 14:34:57 CEST you wrote:
> > One more option: Keep the old load code as a fallback to the new load
> > code. You can drop the old save code, but the old load code probably
> > has to be kept forever.
> > 
> > -Jin
> 
> This is what I thought to do at the beginning, but I realized that things
> weren't so simple. The problem is that, if a page contains two forms without
> names, it's not possible to determine which of them the old entry refers
> to.

What does the current code do in that situation?  Does it not have the same 
problem? 

> For instance, suppose that the page http://xyz.com contains two forms, with
> id f1 and f2 and without a name. The form where the user should enter login
> information is f1. The old name of the KWallet entry with the login
> information is http://xyz.com#, while the new name is http://xyz.com#f1.
> 
> When Konqueror navigates to http://xyz.com, it should do the following:
> - determine which forms are in the page
> - look for entries http://xyz.com#f1 and http://xyz.com#f2: if it finds
> them, good: nothing else to do
> - look for entry http://xyz.com#
> - if the entry exists, try to decide whether it refers to form f1 and f2.
> This can be done comparing the name of the fields of each form to those
> stored in the KWallet entry.
 
> There are two things I don't like here:
> - Konqueror would look for the old entry for any page with forms, as it
> can't know whether the new key doesn't exist because the user never logged
> in the page or because it is stored in the old format

If I'm understanding what you describe above, I think it would look for the 
old entry *only if the new entry was not present*?  Again, is that any 
different than the code today?

> - the process of determining which form in the page the old entry refers to
> could fail in some (very unlikely, I admit) circumstances.

Does it fail any differently than current code would do?
 
> However, your suggestion gave me an idea which I think is a good compromise:
> use the procedure I described above but not automatically. I'll add a menu
> entry which attempts to recover login information from the old KWallet
> entry for the current page and a message box displayed on startup warning
> the user of the situation and informing him of the new menu entry.

I'd guess that users would prefer an automatic solution.  I realise that I've 
repeated the same question three times -- I don't mean to be hectoring but I 
have failed to see why there isn't a solution that is no less robust than 
current code.

-Steve
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 833 bytes
Desc: This is a digitally signed message part.
URL: <http://mail.kde.org/pipermail/kde-devel/attachments/20240922/f18ab145/attachment.sig>