[FdoSecrets] Only show unlock prompt before search if there is no unlocked & exposed database #7574
Comments
|
Unlock before search was introduced in #6943. Usually the client calls search on the whole service, which will search each collection in the service, thus trying to unlock every one of them. However, only databases with an exposed group have the corresponding collection. So if you only have one such database, KPXC shouldn't unlock others. @CrfzdPQM6 could you verify that other databases don't have an exposed group set? And here's a command to show all collections |
|
I upgraded from 2.6.6. to 2.7.0 this morning and before then I'd never encountered this behaviour. I believe, @Aetf , that this is the only database with an exposed group. And, indeed, if I issue the command that you wrote, I get a single dict entry in an array returned. |
|
Yes, 2.7.0 is the first version containing the new "unlock before search" . Could you describe in more details about your setup? You have multiple databases in tabs, but all of them are locked, right? Then when you use secret-tool to search, you see multiple database unlock dialogs? |
|
I've faced same issue. |
|
I now get it. Locked databases are assumed to be exposed because the exposed settings are saved in the db. For now, the behavior can be disabled by unchecking "Application Settings -> Secret Service Integration -> Prompt to unlock Maybe a more useful setting would be unlocking a specific database before searching? |
|
Or show the database unlock dialog, let the user choose the right database to unlock, then roll with it. If the collection is not found you can either re-issue the unlock dialog or error out. |
|
I don't think the database unlock dialog allows selecting database? Without that, in the worst case, the user still has Given that most likely people will have only one database exposed, just letting the user set that database file path in This should cover most use cases. |
I have multiple database tabs, all locked except for the one that also contains the SS integration, and that one is unlocked. Before 2.7.0 I learnt that I had to have that tab active/selected/focused in order for the SS query to succeed. But now when I issue a secret-tool query, it insists that I unlock the other tabs before it issues a dialog about access to SS in the original one. |
Yes, that works for now, as long as I have the db unlocked. Yes, prompting to unlock a specific database would be a really useful feature because I haven't yet figured out how to queue automatically-starting services/applications behind my manual unlocking of keepassxc, and I think this would give me a (short) window to do it before those applications fallback on manual password entry. |
|
@Aetf the database unlock dialog let's you choose now in 2.7.0 |
Ah good. I didn't notice that. So with this, the logic could be: If there's already an unlocked collection, just use that (even though this is not fully confirming to the spec which |
Aetf
changed the title
|
I can't work on this right away so anyone feels free to take a shot. It shouldn't be too complex. |
|
Thank you, @Aetf . I've no experience with the keepassxc codebase so I probably wouldn't be the right person to attempt this. For now the workaround is OK. Grateful for all your efforts. |
|
Hello, |
|
Maybe remember the last database that was used for Secret Service, and separately the last database that was used for Auto-Type. Then the unlock prompt can pre-focus the appropriate DB depending on where the request is coming from. |
The current logic is: * If there're already unlocked collections, just use those, * otherwise, show the unlock dialog until there's an unlocked and exposed collection. Fix keepassxreboot#7574
The current logic is: * If there're already unlocked collections, just use those, * otherwise, show the unlock dialog until there's an unlocked and exposed collection. Fix keepassxreboot#7574
The current logic is: * If there're already unlocked collections, just use those, * otherwise, show the unlock dialog until there's an unlocked and exposed collection. Fix keepassxreboot#7574
The current logic is: * If there're already unlocked collections, just use those, * otherwise, show the unlock dialog until there's an unlocked and exposed collection. Fix keepassxreboot#7574
This sounds reasonable. The info should be saved similarly to the last window position, last file dialog path, etc., as local state data, separated from normal config. From a quick glance of the code, it seems KPXC doesn't save any of these yet. Adding them would be not trivial (although shouldn't be hard, either), so this bit isn't included in the PR. |
This commit implements the following logic: * If there're already unlocked collections, just use those, * otherwise, show the unlock dialog until there's an unlocked and exposed collection. * Fixes keepassxreboot#7574
This commit implements the following logic: * If there're already unlocked collections, just use those, * otherwise, show the unlock dialog until there's an unlocked and exposed collection. * Fixes #7574
This commit implements the following logic: * If there're already unlocked collections, just use those, * otherwise, show the unlock dialog until there's an unlocked and exposed collection. * Fixes #7574
This commit implements the following logic: * If there're already unlocked collections, just use those, * otherwise, show the unlock dialog until there's an unlocked and exposed collection. * Fixes keepassxreboot#7574
This commit implements the following logic: * If there're already unlocked collections, just use those, * otherwise, show the unlock dialog until there's an unlocked and exposed collection. * Fixes #7574
I had the same problem using secret-tool to provide login to a caldav server. Another oddity is that every time an access request is triggered, keepass first insists on unlocking all databases that are in tabs within the KeePassXC application, and only then goes to the one (that was in scope at first) that has the Secret Service access available. I only encountered this before when another tab was active, different to the one that had the Secret Service integration.
Originally posted by @CrfzdPQM6 in #7571 (comment)
The text was updated successfully, but these errors were encountered: