[jbosstools-dev] Secure Storage default password dialog

Max Rydahl Andersen max.andersen at redhat.com
Mon Feb 11 13:16:42 EST 2013


> It is likely that some work could be done here as the current code is built on the concepts of
> teiid's admin being on a separate port to that of jboss admin (teiid 7.7.x and jboss 5). Only in
> teiid 8.x and so Designer 8.x does the jboss admin password and port get used.

oooh - didn't consider this was also for previous JBoss versions - yes for those servers it would happen/be needed.

> However, the password and port are still taken from the jboss settings and passed to a Teiid
> AdminFactory, which in turn creates a proxy of the teiid Admin interface. Whether it is necessary
> for this interface to still require the password, is better answered by the Teiid guys.

hmm - so you are using some other interface...most likely the "pure" http version which does not support
connecting locally without username/passwords ;(

> Incidentally, the teiid server settings are stored separately as an historic consequence of the
> TeiidServerManaager being saved to XML.

> This should be removed but at the moment is too large a
> change for this development cycle. The upshot is that remove/local does not matter, as the secure
> storage password dialog is displayed.

Hmm - thats not great. We moved to secure storage for the server adapter since we had a security concern reported to us.

Is this username/password managed by TeiidServerManager a pure eclipse tooling thing ? Is it only stored if you actually
use the teiid tools or does it happen just by having the teiid tools installed ?

/max

> 
> Thx
> 
> PGR
> 
> 
> On 02/11/2013 03:41 PM, Max Rydahl Andersen wrote:
>>> I take your points so considering an alternative that will address the deficiencies of the current
>>> implementation. One point to address though ...
>>> 
>>>> Btw. from what I can tell this dialog will only show up *once* per machine and only when using Linux and in context of teiid/server adapter only if your server is remote (i.e. it won't 
>>>> need to ask when using local servers)
>>> 
>>> The dialog (on linux) will always appear at the start of the session asking for the secure storage
>>> password, due to the teiid runtime client needing the admin password for communication with the
>>> teiid server.
>> 
>> Doesn't Teiid use the connection jboss server adapter creates ? Thus teiid should not need this unless the Teiid server is remote, right?
>> 
>> Thus this issue (at least from Teiid perspective) is only for Linux with the Teiid server being remote, right?
>> 
>>> Looking into the fragment issue, it seems eclipse defies its own extension by using a fragment for
>>> windows and macosx. The extension point provides a priority so that multiple password providers can
>>> be offered yet the fragment does not use it. So ...
>>> 
>>> I could separate out my code into a linux-only fragment, and remove the specific references to JBoss
>>> and Teiid in the dialog messages, thereby 'genericising' it. This would ensure that those users
>>> running linux, who are the only ones to see it, would get a dialog with much more information
>>> regarding what the password is for - the primary purpose of overriding the dialog in the first place.
>> 
>> This sounds like a plausible idea.
>> 
>> /max
>> 
> 
> -- 
> Paul Richardson
> 
>  * p.g.richardson at phantomjinx.co.uk
>  * p.g.richardson at redhat.com
>  * pgrichardson at linux.com
> 
> "I know exactly who reads the papers ...
> 
>  * The Daily Mirror is read by people who think they run the country.
>  * The Guardian is read by people who think they ought to run the country.
>  * The Times is read by people who do actually run the country.
>  * The Daily Mail is read by the wives of the people who run the country.
>  * The Financial Times is read by the people who own the country.
>  * The Morning Star is read by the people who think the country ought to be run by another country.
>  * The Daily Telegraph is read by the people who think it is."
> 
> Jim Hacker, Yes Minister
> 




More information about the jbosstools-dev mailing list