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

[Stefano Crocco]

On domenica 22 settembre 2024 18:40:29 CEST Steven Robbins wrote:
> 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

Thanks for your answer. If I understand correctly what you mean, I think I was 
aiming for a solution with slightly different results than yours:
- what I wanted was I migration from old to new entries which would solve all 
ambiguities. Referring to the example above, from the http://xyz.com# entry,
I wanted to determine whether it referred to the form f1 or to the form f2 and 
to create either the http://xzy.com#f1 or the http://xyz.com#f2 entry but not 
both
- what you are suggesting instead, is to keep the ambiguity  by creating two  
entries with the new names, one for each form, having the same contents.
In the example, this would mean creating both the http://xzy.com#f1 and the 
http://xzy.com#f2 entries. Is this correct?

Thinking about it, your suggestion makes a lot of sense since, as you pointed 
out, it doesn't worsen the current situation and it's easier to implement. The 
only downside is that Konqueror will need to checks for two entries instead of 
only one every time the user visits a page with forms. However, I doubt it 
will be noticeable.

I'll try implementing this as soon as I have a bit of time.

Stefano