[jbosstools-issues] [JBoss JIRA] (JBIDE-21043) Create a credentialing framework

[Rob Stryker (JIRA)]

    [ https://issues.jboss.org/browse/JBIDE-21043?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13125059#comment-13125059 ] 

Rob Stryker commented on JBIDE-21043:
-------------------------------------

>  what will a plugin store in its setup instead of the username/password ?

Ideally it would store a domain / username combination.  Some may not even need to store the hostname, as they're already limited to using jboss.org / rht credential systems  (see dl.runtimes)....

Or, as another idea (not yet coded), it could also allow "Default Username" as an option... so for each host you could have multiple usernames but mark one as the default.   Clients who want can store host+username,   others could store host+"default username" option, which would allow them to resolve not only the password but also the username.  But this seems a niche case... users aren't often changing usernames and deleting the old ones, but it does happen. 

> i.e. how is it ensured that when I change the setting in my credentials page it will be updated in the other plugin ? 

The other plugins should be dynamically pulling the password.

> when does it make sense to only add a domain ? 

A plugin may contribute a domain  (possibly through extension point? Currently just hard-coded jboss.org and access.redhat.com).  It may make sense to put the domain in there for a few purposes:     1)  The plugin must query for usernames at a given domain.  By contributing the domain directly, the plugins can ensure the domain is properly typed in and has the exact id they will query on, minimizing error for users.   2) Users can see where they need to add the credential, so it helps guide the user as well. 

> why not just entries with username + host that you then can show by domain or if you wanted by user ? 

Well,  for example dl-runtimes or openshift may need to query on a specific domain string, looking for all usernames with a given host. Users may not be consistant with how they declare the domain.  They may type in 'jira.jboss.org' instead of just jboss.org,  and then dl.runtimes won't know to query on jira.jboss.org.   I also made this design decision because the tree is also easily navigable now in the secure storage page, split by domain, and properly encrypted, and I feel easier to read through in the case of debugging or digging around... 

I admit the PR is a work in progress, and I welcome all feedback for enhancement to cover more usecases. I like the idea of having configurators respond to changes in the credential model and then update dependent models  (such as mylyn jira / bz) that cannot automatically reference this new credential area. 

> Create a credentialing framework
> --------------------------------
>
>                 Key: JBIDE-21043
>                 URL: https://issues.jboss.org/browse/JBIDE-21043
>             Project: Tools (JBoss Tools)
>          Issue Type: Feature Request
>          Components: common/jst/core
>    Affects Versions: 4.3.0.Final
>            Reporter: Rob Stryker
>         Attachments: JBIDE-21043.png, JBIDE-21043a.png
>
>
> There should be a unified framework for storing credentials to various domains. As of now, download runtimes (in astools) requires redhat or jboss credentials, and I've heard that others are also storing the credentials for some of those domains as well. 



--
This message was sent by Atlassian JIRA
(v6.4.11#64026)