Merge lp:~apachelogger/desktopcouch/kwallet-support into lp:desktopcouch
| Status: | Rejected |
|---|---|
| Rejected by: | Vincenzo Di Somma on 2010-11-02 |
| Proposed branch: | lp:~apachelogger/desktopcouch/kwallet-support |
| Merge into: | lp:desktopcouch |
| Diff against target: |
109 lines (+60/-4) 1 file modified
desktopcouch/local_files.py (+60/-4) |
| To merge this branch: | bzr merge lp:~apachelogger/desktopcouch/kwallet-support |
| Related bugs: |
| Reviewer | Review Type | Date Requested | Status |
|---|---|---|---|
| Rodrigo Moya (community) | Needs Fixing on 2010-08-06 | ||
| Tim Cole (community) | 2010-07-28 | Approve on 2010-08-02 | |
|
Review via email:
|
|||
Description of the Change
Store tokens also if KWallet (if pykde is available). Please note that this will work with either pykde or python-
Also: currently the ubuntu packaging depends on gnome-keyring that probably should be changed to recommends on pygnomekeyring | pykde.
| Harald Sitter (apachelogger) wrote : | # |
IMHO a library to throw content at should be possible and would be a good idea (supposedly it could use the same approach to cover both gnomekeyring and kwallet).
For now however I would just like to get this in as-is to make the way free for ubuntuone-kde stuff.
| Rodrigo Moya (rodrigo-moya) wrote : | # |
Wouldn't it be easier to use python-keyring? Also, the way the code is written, it will always check for kwallet first and then, whether it found it or not, check again for gnomekeyring:
22 + if ctx.wallet is not None:
...
43 if ctx.keyring is not None:
| Harald Sitter (apachelogger) wrote : | # |
IIRC python-keyring has at least on the KWallet side of things a desktop experience flaw because it will trigger authentication (to the wallet) for Python and not the particular app.
Eitherway I wanted it to be as non-intrusive as possible as to prevent regression.
The fact that it does look for kwallet and keyring is intentional since one user can run apps that try to access either backend, since the specification @ fdo does not go into any detail regarding multiple keyrings. In one implementation it is entirely possible that someone writes a KDE library that only accesses kwallet (which is entirely valid considering the spec says that one has to get the token from the keyring, but not any specific one or in any particular order), so if desktopcouch can access kwallet then it _must_ drop its token there (and technically any other keyring system it can find as to not limit client implementations).
If it did not do that then it sort of requires client implementations to search all keyring systems for tokens since desktopcouch might have dropped them in either of them.
| Vincenzo Di Somma (vds) wrote : | # |
Due to changes this branch doesn't apply anymore.
Unmerged revisions
- 168. By Harald Sitter on 2010-07-28
-
add as non-intrusive kwallet support as possible

Looks like a good start. Is this something we can factor out into a library?