Bug 279724 - LDAP password is requested while this is already stored in kwallet
Summary: LDAP password is requested while this is already stored in kwallet
Status: RESOLVED UNMAINTAINED
Alias: None
Product: Akonadi
Classification: Frameworks and Libraries
Component: general (show other bugs)
Version: 1.5.3
Platform: Fedora RPMs Linux
: NOR normal
Target Milestone: ---
Assignee: kdepim bugs
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2011-08-09 10:30 UTC by Geert Janssens
Modified: 2017-01-07 22:09 UTC (History)
1 user (show)

See Also:
Latest Commit:
Version Fixed In:


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Geert Janssens 2011-08-09 10:30:16 UTC
Version:           1.5.3 (using KDE 4.6.5) 
OS:                Linux

I'm not sure what component is responsible for this, so I chose Akonadi - general.

Here's my use case:
When I start kontact (on one machine) or kmail only (on another machine), this will ask to open kwallet for the passwords it requires. This works fine.

If I enter the kwallet master password fairly quickly, all proceeds normally. If, however, I wait too long to enter this master password (say because I went to get some coffee first), a second dialog will pop up after the kwallet master password is entered that asks for my LDAP password.

I assume this LDAP password is required for my LDAP based address book. This LDAP password is also stored in kwallet and works fine. This should be clear from the use case where I am fast enough to unlock kwallet. In that case kontact/kmail never asks for the LDAP password and my address book works fine.

It is only when I wait long enough to unlock kwallet that I get asked for an LDAP password. And even in that case, kontact/kmail already know the password, because it's prefilled in the LDAP dialog. So with only hitting ok, I can continue.

This behaviour suggests that an LDAP connection is attempted before the user unlocks kwallet. If it takes long enough to unlock, the LDAP connection attempt times out and triggers a password request.

Reproducible: Always

Steps to Reproduce:
- Setup an LDAP address book and store the LDAP credentials in kwallet
- Log out and back in to reset the password caches
- Start kmail
- When the kwallet unlock dialog appears, wait a while (my guess would be at least a minute)
- Unlock kwallet

Actual Results:  
As soon as the kwallet unlock dialog closes, a new dialog appears to ask for the LDAP password. Note that this password is prefilled in the dialog, so clearly kmail already knows it.

Expected Results:  
The second dialog should only appear if the LDAP password was not in kwallet or the one in kwallet was invalid, not because a user takes quite a long time to unlock kwallet.

For me as an experienced user, this is only a small problem. I understand both dialogs and their purpose. But I support a number of casual users and having two dialogs pop up confuses them to no end. This is even more complicated by the fact that the kwallet master password is different from the LDAP password (for obvious security reasons). However since the users have a very hard time discriminating the two different password requests they often end up trying their kwallet passwords for the ldap password request (thinking they simply mistyped their kwalled password the first time). This of course doesn't work and worse, a wrong password then gets stored in kwallet, requiring regular administrator intervention.
Comment 1 Geert Janssens 2011-12-16 17:31:05 UTC
This behaviour is still the same in Fedora 16,
kdepim-4.7.3-1.fc16.i686
akonadi-1.6.2-2.fc16.1.i686
Comment 2 mondinmr 2012-10-24 06:12:03 UTC
Even in kubuntu 12.04 it has the same bug.
I also believe depends on the interaction between akonadi and kwallet because LDAP parameters I've set for access via akonadi.
Comment 3 mondinmr 2012-10-24 06:23:11 UTC
I forgot to indicate versions:
kdepim 4.8.5-0ubuntu0.1
akonadi 1.7.2-0ubuntu1
kontact 4.8.5-0ubuntu0.1
Comment 4 Denis Kurz 2016-09-24 20:37:31 UTC
This bug has only been reported for versions older than KDEPIM 4.14 (at most akonadi-1.3). Can anyone tell if this bug still present?

If noone confirms this bug for a recent version of akonadi (part of KDE Applications 15.08 or later), it gets closed in about three months.
Comment 5 Denis Kurz 2017-01-07 22:09:52 UTC
Just as announced in my last comment, I close this bug. If you encounter it again in a recent version (at least 5.0 aka 15.08), please open a new one unless it already exists. Thank you for all your input.