Bug 72317

I think this requires support in both places.  Hmm, good plan for 3.3.

The main problem, IMO, is that after kwallet fills the form, it is not used again: I don't mind having to select the username field and typing in the other username - KHTML has autocompletion to aid me - but if I change the username, I expect kwallet to enter the matching password for me, like IE is doing it.

Alternatively a pop up dialog with a list of usernames to choose from, like Mozilla, will probably be a better idea.

I would really love to see it for KDE 3.3. thanks :-)

This is a really critical one for me, and the primary reason I'm still stuck with using Mozilla for most of my work. I develop web applications for which a variety of usernames and passwords must be used to test various access levels. In general, it is an important feature for anyone who manages multiple accounts of any kind accessed from a given URL, which I suspect happens often among IT professionals (as well as avid webmail users :-)

On Monday 19 July 2004 10:44, Jeffrey Froman wrote:
> ------- This is a really critical one for me, and the primary reason I'm
> still stuck with using Mozilla for most of my work. I develop web
> applications for which a variety of usernames and passwords must be used to
> test various access levels. In general, it is an important feature for
> anyone who manages multiple accounts of any kind accessed from a given URL,
> which I suspect happens often among IT professionals (as well as avid
> webmail users :-)

   This is mostly a KHTML integration issue, and until someone decides to do 
that, and tells me what else is needed (if anything), I guess it won't 
happen...

On Monday 19 July 2004 09:06, George Staikos wrote:
> This is mostly a KHTML integration issue, and until someone decides to do
> that, and tells me what else is needed (if anything), I guess it won't
> happen..

Thanks, George. I'll see what I can do to alert someone in that area.

Jeffrey

*** Bug 83819 has been marked as a duplicate of this bug. ***

*** Bug 85524 has been marked as a duplicate of this bug. ***

CVS commit by staikos: 

- Add wildcard query support to KWallet
- Add a testcase for it
- Add a new file kwallettypes for the DCOPRef additions
  (Time to move some of these into dcop/?)

Review of the interface is appreciated.  What does this get us?  Well, the
ability to find close matches for URLs.
CCBUG: 82965, 72317


  A            kwallet/client/kwallettypes.h   1.1 [LGPL (v2+)]
  M +65 -1     kio/misc/kwalletd/kwalletd.cpp   1.74
  M +4 -1      kio/misc/kwalletd/kwalletd.h   1.37
  M +23 -1     kwallet/backend/kwalletbackend.cc   1.54
  M +5 -1      kwallet/backend/kwalletbackend.h   1.21
  M +2 -2      kwallet/client/Makefile.am   1.12
  M +62 -3     kwallet/client/kwallet.cc   1.46
  M +38 -1     kwallet/client/kwallet.h   1.30
  M +17 -0     kwallet/tests/kwalletboth.cpp   1.2

*** Bug 92956 has been marked as a duplicate of this bug. ***

*** Bug 82965 has been marked as a duplicate of this bug. ***

If i go to gmx i would like to have a window where i can choose one combination of username and password. Perhaps a discription for each pair would be helpful.

*** Bug 94598 has been marked as a duplicate of this bug. ***

*** Bug 96960 has been marked as a duplicate of this bug. ***

i tink, a site with more then one account must have a editchance for delete not longer existing acounts. there must be a workaround in kwallet to do this i think. and i think, there must a questin to add a new account, if an existing account is saveed in kwallet... my thinkin ;)

*** Bug 104110 has been marked as a duplicate of this bug. ***

I agree. In my opinion, the behaviour should be as this:

When you're on a site the first time, enter id+pwd then you get asked if you want to store this id+pwd.

If you enter a site where kwallet has only one id+pwd, this one is filled in automatically, like today.

If you enter a site where multiple ids+pwds are stored, a popup should appear letting you choose from the exisiting ids OR let you select an entry like "leave empty", so the id+pwd fields are not auto-filled, you can enter a completely new id+pwd and you get asked if you want to store these too. Instead of a popup, which just gets in the way, perhaps the login name field could somehow extend to a multiple-line-choice field where you can select one of the entries. Pressing DEL could delete an entry (as you can also delete it in kwallet itself).

Tom

I rather like Firefox's method, whereby the form isn't automatically filled in when you have multiple saved entries. When you start typing in, for example, your username it drops down an auto-complete box, and selecting that then fills in the rest of the form accordingly.

My only gripe with that is that there's no indication that it has remembered your values until you start typing... but that could be done, and it's certainly nicer than a pop-up dialogue.

I would like to keep the "auto fill in" method for cases where only one set of data is saved in kwallet. This way I can select a bookmark (with the mouse) and then click on "Submit" in the ready filled form (mouse) without having to use the keyboard in between (better usability).

I'd even vote for an "auto-fill+submit" so you save yourself the trouble of finding the "LOGIN" button every time (but this would probably not work with javascript based form submits).

Thanks! :)

Jens

is there any documentation how to use the wildcards in kwallet URLs?

Is it regular expressions?  or shell wildcards?  or something other?


thx


S.

On Monday 28 November 2005 05:07, Susanne Oberhauser wrote:
> is there any documentation how to use the wildcards in kwallet URLs?
>
> Is it regular expressions?  or shell wildcards?  or something other?


  Shell wildcards.  It doesn't work from KHTML yet though. The UI isn't done.

What's the current status? Is it being worked on?

*** Bug 120804 has been marked as a duplicate of this bug. ***

*** Bug 126031 has been marked as a duplicate of this bug. ***

I like Firefox's way of handling it as well. Another issue to this form remembering is that it should be to the domain, not the page that your on. I have started using Konqueror as my default browser rather than Firefox because of the load time and that it is accually working for some of our websites that we are developing.

1. It should remember multiple logins.
2. If there are multiple logins, user should have to start typing in username in, and a dropdown list should appear. User can select which user they want to choose.
3. Once selected, Konqueror should put in correct password which which user they chose.
4. Konqueror should also be sensitive to words like "UserID, ID" instead of just "Username"

*** Bug 132750 has been marked as a duplicate of this bug. ***

*** Bug 123622 has been marked as a duplicate of this bug. ***

I agree with Mr Webb, except I'm not sure about ignoring the page.  Perhaps the page could select the default entry?

Any chance of this happening this decade? 

*** Bug 148934 has been marked as a duplicate of this bug. ***

For me it's more a bug than a feature we wish. All Konqueror's interest is affected. Very boring for persons they make webdeveloppment or making moderation on a site. They must have several accounts attached on the same domaine name.

are we there yet? it's another reason to use ffox for me, which is slower than konq in certain places, and takes up gtk2 into memory.

Obviously not, otherwise this report would be marked as FIXED. Please keep the "noise" ratio down -- thank you in advance for understanding.

Since the http://bugs.kde.org/show_bug.cgi?id=123622 was marked as duplicate, one note -- there should be a way to simply overwrite the old values with new ones, as well (so not only having multiple accounts).

*** Bug 185102 has been marked as a duplicate of this bug. ***

This bug is almost five years old ... do KDE developers use Konqueror at all? ;)

*** Bug 220239 has been marked as a duplicate of this bug. ***

Created attachment 49409 [details]
Enable multiple accounts in KHTML (/Konqueror)

Hi,

I tried to add support for multiple accounts and it seams I succeeded. By that I mean I successfully recompiled KDE trunk and KDE 4.3.3 (my desktop's version) with this patch and tried multiple accounts in konqueror and it works. Also, accounts are saved for the whole site, not just for the specific URL like it was the practice before.

Key features of my approach are the following:

Login page is identified by having 2 form input fields, one that is plain text field, and the other that is the password field. All other form types are dropped to old behaviour.

Login on one site is universal on that site. That means if you can login using multiple URLs (like on bugs.kde.org), the login data will be stored only once and used on all login pages.

All account usernames on the site are stored as PASSWORD value in the FormData folder of Network KWallet with the key:

accounts_SITE

All passwords are stored as PASSWORD value in the FormData folder of the Network KWallet with the key:

account_SITE_USERNAME

When you come to the SITE's login page, the system offers you to autocomplete username. When you select some username from the autocomplete list, the system autofills the correct password.

No username if prefilled, but that could be easily done (for example, by selecting the first username from the accounts list or by keeping record which username was last used).

I made this patch from the current kdelibs trunk checkout, yet I tested it also on kdelibs 4.3.3 and it applies correctly (actually it doesn't since the copyright comments don't apply correctly, but if you ignore that one error as it is only related to comments, the patch does apply). Therefore, it is safe to assume this patch works on all versions of kdelibs from 4.3.3 to trunk (possibly with some older versions, but I didn't check that).

It is worth noting that I marked all changes I made with

// BEGIN CHANGE [BRCHA]
...
// END CHANGE [BRCHA]

comments, so that the changes are easily visible and searchable on the kdelibs checkout with the applied patch.

Also, I didn't add support for KHTMLWalletQueue and marked the point with // TODO [BRCHA]. I will investigate KHTMLWalletQueue implementation and add support for that in some near future. Luckily I still didn't get to the point where WalletQueue is used, but it is probably useful to add support for that as well ;). KHTMLWalletQueue supports only Maps (as maps were the only thing used in the old approach), so I'll have to add support for Password storing.

Created attachment 49730 [details]
Save multiple web accounts in KWallet

I ran this patch for a week, found some errors (1: system offered to save
password always, not only when it is new or changed + 2: you had to click on
the password field so that it gets filled with the password because I didn't
"setFocusNode" before setting the value) and fixed them. Also, I added support
for writing password values using KHTMLWalletQueue as well.

Please, test this on your systems (don't blame me if your computer explodes, although that is unlikely), and report if you encounter some error.

*** Bug 249346 has been marked as a duplicate of this bug. ***

Filip:

You should post your patch at the KDE reviewboard, that way it won’t be overlooked that easily :-)
http://reviewboard.kde.org/

Please see bug #143307

Hi,

kdelibs (version 4 and earlier) is no longer maintained since a few years.

KDE Frameworks 5 or 6 might already have implemented this wish.

If not, please re-open against the matching framework if feasible or against the application that shows the issue.

We then can still dispatch it to the right Bugzilla product or component.

Greetings
Christoph Cullmann