Version: 1.5 (using 4.4.00 (KDE 4.4.0), Kubuntu packages) Compiler: cc OS: Linux (i686) release 2.6.31-20-generic At present, it seems there is no way to override either which wallet applications check (which would be difficult to implement). With this in mind, and my irritation at Plasma for consistently asking for my wallet's password (which opens it for access by other applications as well, posing some insecurity), I created a new wallet with no password specifically for Plasma and dragged the relevant items ("Plasma-MicroBlog" and "Plasma-Twitter") from my default wallet to this new wallet. However, Plasma still asks for access to the default wallet when it first runs and obviously fails to find the password. This is undesired: it should instead just access the password-less wallet and fetch the relevant information from there. I am unsure whether this actually falls under a, "bug", or whether it is more an un-implemented wish item.
Currently I'd rather rate it a wish and partly related to bug 136094. However it's a bit different in that you want to move passwords wherever you want and want KWallet to find them, the other one wants some way of choosing where to store passwords explicitly in each application. The former will be possible when the new Secret Service API is fully implemented (it's a server-side thing), the latter might be available with a new client API (it would currently be possible but applications don't do it (yet)).
Which way do you believe is the better implementation? The former certainly seems like less work at first glance, and it means that managing which passwords go in which wallet is done in the wallet manager rather than in every single individual application that wants access to the wallet, but the latter may make it easier for the user to find while the application is querying KWallet.
I think both ways would actually make sense. If I had to take a guess, the latter is what more people want to see but I have seen several requests for the former as well. I think when the new API is ready we'll have to revise ways to use it and make some recommendations/guidelines for application developers. I'll keep both features on the radar to check what makes sense when the time comes.
I do agree, both sides of the implementation make sense in their own way, but I think it is important to look at the facts: currently no application actually offers to select a wallet to use and this is not very likely to change in my eyes. as a consequence there is no support for multiple wallets from a users point of view. Except inside kwalletmanager itself which does not make sense at all like this, it is a stub. I doubt it is very successful to promote usage of multiple wallets upon application developers. Instead it might make sense to implement some lightweight access rule management in the wallet manager. This way it is up to the user, not the application developer, which wallet to use or simply leave it to the default wallet. This without any change required for the applciation itself ("transparency"). A change in the API might not be neccessary (has to be checked) with this strategy: an application requesting a token from the wallet without explicitly choosing a wallet is served from a default wallet for this application, depending on the rule set inside the wallet system: this might be the global default if no rule exists or an "application specific default" if a rule matching this application exists. In addition, if there really is an application one day that supports choosing a wallet, it offers all those wallets offered by the wallet system by request _for_ _this_ _application_. I know this adds weight to the wallet system, but in my eyes this is the only realistic way to offer usage of multiple wallets to users. Because reality shows that no application supports choosing a wallet.
@Christian: You're right, that's the only reasonable way to handle this user request. I scheduled this on my TBD list.
@Valentin: Great news, thanks! Drop me a line if you start implementing. I stopped that attempt myself years ago when I heard about the "secret service", but that turned out to be a false alarm...
*** Bug 143795 has been marked as a duplicate of this bug. ***
*** Bug 394880 has been marked as a duplicate of this bug. ***
Related to Bug 451039 comment 2.
*** Bug 359451 has been marked as a duplicate of this bug. ***
*** Bug 136094 has been marked as a duplicate of this bug. ***
(In reply to michaelk83 from comment #9) > Related to Bug 451039 comment 2. On 2nd thought, with the Secret Secret API (KWallet Framework 5.97.0+), it's up to each application to specify which collection (wallet) it wants to use, since they can only use the `CreateItem()` method on the collection level. There's no `CreateItem()` on the service level, so the service (KWallet) can't route those requests as it pleases. https://specifications.freedesktop.org/secret-service/latest/re02.html https://specifications.freedesktop.org/secret-service/latest/re01.html Furthermore, the plan is to migrate the KDE apps to QtKeyChain, which AFAIK just uses the default collection and doesn't provide an API for specifying which collection to use. Apps could still specify the collection if they use `libsecret` instead, but that would be more the exception than the rule. So this feature request would only grow less applicable as the migration to Secret Service and QtKeyChain proceeds. (See also Bug 458318)
(In reply to michaelk83 from comment #12) > Furthermore, the plan is to migrate the KDE apps to QtKeyChain, which AFAIK > just uses the default collection and doesn't provide an API for specifying > which collection to use. Apps could still specify the collection if they use > `libsecret` instead, but that would be more the exception than the rule. Posted https://github.com/frankosterfeld/qtkeychain/issues/219 , though I don't know how likely it is to be implemented by QtKeyChain, or to be used by client apps. If not implemented, apps can still use `libsecret` directly to achieve the same result, but again, this is unlikely to become common.
That said, and especially assuming most apps would use the default collection anyway, the backend can choose to ignore the selected collection, and re-route `CreateItem()` requests as it sees fit. That somewhat breaks the Secret Service spec, but technically, it should work. Search and deletion are independent of the collection name: https://specifications.freedesktop.org/secret-service/latest/re01.html#org.freedesktop.Secret.Service.SearchItems https://specifications.freedesktop.org/secret-service/latest/re03.html#org.freedesktop.Secret.Item.Delete `Collection.SearchItems()` can be re-routed in the same way as `CreateItem()`.