Password Settings not Supported

[hugosenari]

Current version can't use plugin_support.UserNamePassword as plugin setting type.

Actual Behaviour

raise ImportError "Keyring is not supported"

Expected Behaviour

Maybe use Keyring to implement this feature.

[hugosenari]

Added three possible solutions for this:

• Enable plugin to define any specific type hugosenari/kupfer@51660c8
• Add keyring support again using simplified version of old code hugosenari/kupfer@02b9033
• And both hugosenari/kupfer@1afc584

I created the first (and last) option because plugins can define other auth strategy (IE. OAuth) and fields.

[bluss]

I haven't used the keyring support before. Does it work well for you?

I'm skeptical of it: when I look at GData APIs (google) all the user+pass authorization options seem deprecated, and I would prefer if we didn't have to handle passwords at all.

Either way I also hope that user sources may be a back door in for users to do all kinds of data gathering that they'd like.

[hugosenari]

Keyring support works fine to me, but I don't know for edge cases or tested with all kind of backends.

I had this issues with Jira Plugin:

• How old kupfer handle OAuth or SAML flow?
  • It doesn't, so I can only enable User/Pass auth.
• How new kupfer store pass?
  • It doesn't, then to support new kupfer version pass is text/plain.

User sources can't make new actions (call webservices in my case).

I'm not defending my implementation only that some is required.
I'll be glad if we can find plugin solution that doesn't change kupfer.

[bluss]

We should add back the UserNamePassword setting type I think.

UserNamePassword2 looks good to me. Does it need more error handling?

[hugosenari]

Added error if backend is fail.Keyring.
Removed check if is encrypted and add name.
Ge/Set pass can raise errors, they shows at stdout and don't crash kupfer settings.