Fwd: Re: Suggestion

[Anders Lund]

On Saturday 04 December 2004 04:11, Matt Rogers wrote:
> Hi,
>
> George forgot to CC you, so i'm passing it along.
Thank you very much

> On Friday 03 December 2004 17:49, Anders Lund wrote:
> > Hi,
> > This is a suggestion for improving the form data memory of KHTML.
> >
> > It seems to me that KHTML associates the form data (including passwords)
> > with the URL where the data was typed. This is not working for many
> > community type portals, because the URL where you type your login data
> > (and other data as well) are often different.
> >
> > So my suggestion is that KHTML associate the data with the target of the
> > form in which they are typed instead. That way, a user is saved either
> > looking his password up manually, or going to a location for which KHTML
> > remembers them.
> >
> > I'm not on this list, so if you answer please CC me.
>
>   Nice idea, but actually this suffers the same problem I think.  I've seen
> sites that have constantly changing targets but the login is always the
> same. I have some better solutions already.  See bugs.kde.org for more
> info. Basically it would use fuzzy searching (wildcards) to try to find the
> best match if one doesn't exist, but some close ones do.

That sounds good. Maybe a combination? 

The typical problem is login boxes, which common scripts like drupal or 
phpnuke puts on all pages. The form target is the same, for example for 
drupal /usr/login or /?q=/usr/login.

At http://www.kde-look.org, the login form is presented at your current URL if 
you are not logged in, and have no explict target, so in that case the target 
would fail as a key.

So matching both the form target *and* the URL presenting the form, in that 
order might be the best.

-anders

-- 
Homepage: http://www.alweb.dk
Jabber address: anderslund at jabber.dk