Re: [JBoss-dev] DataSourceLoader...
I did briefly, but what I really want is a conversion guide. I did not have
much luck with taking bist from jboss-auto.jcml. I could try again though.
I am using the loader in the time being.
--jason
On Thu, 16 Aug 2001, David Jencks wrote:
> Did you try the autoconverter XADataSOurceLoader? it worked for
> XADataSourceImpl (won't work now, had to jimmy the config).
>
> Will look more later
> david
>
> On 2001.08.16 18:25:18 -0400 Jason Dillon wrote:
> > In XAManagedConnectionFactory.getXADS() is returning null due to the
> > return
> > null at the bottom of the method. It looks like this wants either an
> > xaDataSourceClass or xaDataSourceName to be set, if not it returns null.
> > Which then causes the pooling stuff to hang indefinently.
> >
> > This is confusing me a little. Where do I specify these values? The
> > examples you gave were both based on the local tx stuff, but I want to
> > use
> > the xa tx stuff.
> >
> > Any advise? I am stuck in the water until I can get the DS back online.
> >
> > --jason
> >
> >
> > On Thu, 16 Aug 2001, David Jencks wrote:
> >
> > > ResourceAdapterName identifies which resource adapter supplies the
> > > ConnectionFactory (and ManagedConnectionFactory etc etc) for the
> > > ConnectionFactoryLoader to load. (It's the display-name tag in ra.xml)
> > If
> > > you were using firebird as your database, this could be the firebird
> > > jca/jdbc driver. Since we are mostly stuck with jdbc only drivers,
> > this is
> > > typically one of the 2 Minerva wrapper adapters. With the jdbc (local
> > > transaction) wrapper, the "Properties" attribute, which is for
> > configuring
> > > the Resource Adapter, contains the db url which is enough to figure out
> > > which db driver we are using. With enough luck, mainstream db vendors
> > will
> > > decide to supply jca .rar versions of their drivers soon so we don't
> > always
> > > need the Minerva wrappers.
> > >
> > > david jencks
> > >
> > > On 2001.08.16 14:35:00 -0400 Jason Dillon wrote:
> > > > What is ResourceAdapterName used for?
> > > >
> > > > --jason
> > > >
> > > >
> > > > On Wed, 15 Aug 2001, David Jencks wrote:
> > > >
> > > > > Hi,
> > > > >
> > > > > This discussion comes up in various places on various lists. Since
> > you
> > > > > don't mention otherwise I assume you are planning to decrypt in
> > code
> > > > > without manual intervention. As I understand the consensus is,
> > Don't
> > > > do
> > > > > this. You need some code to unencrypt the password to send it to
> > the
> > > > db,
> > > > > if someone can find your jboss.jcml file they can find the
> > unencryption
> > > > > code. Thus you have implemented only security by obscurity and
> > only
> > > > > succeeded in making life harder for the users and probably given
> > them a
> > > > > false sense of security, encouraging carelessness that a determined
> > > > hacker
> > > > > can exploit.
> > > > >
> > > > > Secrets and Lies by Bruce Schneier is fun to read and explains this
> > > > really
> > > > > well.
> > > > >
> > > > > If you want more security yet don't want to give each user their
> > own
> > > > > password and have per-subject pools, how about writing a
> > > > > ConnectionFactoryLoader that pops up a password dialog on startup (
> > in
> > > > > initService). It's inconvenient, but at least it doesn't try to
> > fool
> > > > > people into thinking their passwords are hidden. Of course, it
> > could
> > > > be
> > > > > hard to figure out where to pop up the dialog...
> > > > >
> > > > > How about simply encrypting all of jboss.jcml say using pgp and
> > > > requiring a
> > > > > manually entered password to unencrypt to start jboss?
> > > > >
> > > > > In any case if you wish to modify the datasource loading procedure
> > I
> > > > > suggest you work on the jca resource adapter version since
> > > > > {XA|JDBC}DataSourceLoader will not really exist in rh. (they will
> > set
> > > > up
> > > > > connectionFactoryLoader mbeans).
> > > > >
> > > > > david jencks
> > > > >
> > > > > On 2001.08.14 19:12:14 -0400 "Ferguson, Doug" wrote:
> > > > > > What do you guys think about implemented a version of the
> > DataSource
> > > > > > loader
> > > > > > that
> > > > > > allows for encrypted passwords?
> > > > > >
> > > > > > I am required to use encrypted db passwords..
> > > > > > And I was thinking that even if I encrypt once I write the
> > jboss.jcml
> > > > > > It is now clear text again..
> > > > > >
> > > > > > d.
> > > > > >
> > > > > > ___
> > > > > > Jboss-development mailing list
> > > > > > [EMAIL PROTECTED]
> > > > > > http://lists.sourceforge.net/lists/listinfo/jboss-development
> > > > > >
> > > > > >
> > > > >
> > > > > ___
> > > > > Jboss-development mailing list
> > > > > [EMAIL PROTECTED]
> > > > > http://lists.sourceforge.net/lists/listinfo/jboss-development
> > > > >
> > > >
> > > >
> > > >
Re: [JBoss-dev] DataSourceLoader...
In XAManagedConnectionFactory.getXADS() is returning null due to the return
null at the bottom of the method. It looks like this wants either an
xaDataSourceClass or xaDataSourceName to be set, if not it returns null.
Which then causes the pooling stuff to hang indefinently.
This is confusing me a little. Where do I specify these values? The
examples you gave were both based on the local tx stuff, but I want to use
the xa tx stuff.
Any advise? I am stuck in the water until I can get the DS back online.
--jason
On Thu, 16 Aug 2001, David Jencks wrote:
> ResourceAdapterName identifies which resource adapter supplies the
> ConnectionFactory (and ManagedConnectionFactory etc etc) for the
> ConnectionFactoryLoader to load. (It's the display-name tag in ra.xml) If
> you were using firebird as your database, this could be the firebird
> jca/jdbc driver. Since we are mostly stuck with jdbc only drivers, this is
> typically one of the 2 Minerva wrapper adapters. With the jdbc (local
> transaction) wrapper, the "Properties" attribute, which is for configuring
> the Resource Adapter, contains the db url which is enough to figure out
> which db driver we are using. With enough luck, mainstream db vendors will
> decide to supply jca .rar versions of their drivers soon so we don't always
> need the Minerva wrappers.
>
> david jencks
>
> On 2001.08.16 14:35:00 -0400 Jason Dillon wrote:
> > What is ResourceAdapterName used for?
> >
> > --jason
> >
> >
> > On Wed, 15 Aug 2001, David Jencks wrote:
> >
> > > Hi,
> > >
> > > This discussion comes up in various places on various lists. Since you
> > > don't mention otherwise I assume you are planning to decrypt in code
> > > without manual intervention. As I understand the consensus is, Don't
> > do
> > > this. You need some code to unencrypt the password to send it to the
> > db,
> > > if someone can find your jboss.jcml file they can find the unencryption
> > > code. Thus you have implemented only security by obscurity and only
> > > succeeded in making life harder for the users and probably given them a
> > > false sense of security, encouraging carelessness that a determined
> > hacker
> > > can exploit.
> > >
> > > Secrets and Lies by Bruce Schneier is fun to read and explains this
> > really
> > > well.
> > >
> > > If you want more security yet don't want to give each user their own
> > > password and have per-subject pools, how about writing a
> > > ConnectionFactoryLoader that pops up a password dialog on startup ( in
> > > initService). It's inconvenient, but at least it doesn't try to fool
> > > people into thinking their passwords are hidden. Of course, it could
> > be
> > > hard to figure out where to pop up the dialog...
> > >
> > > How about simply encrypting all of jboss.jcml say using pgp and
> > requiring a
> > > manually entered password to unencrypt to start jboss?
> > >
> > > In any case if you wish to modify the datasource loading procedure I
> > > suggest you work on the jca resource adapter version since
> > > {XA|JDBC}DataSourceLoader will not really exist in rh. (they will set
> > up
> > > connectionFactoryLoader mbeans).
> > >
> > > david jencks
> > >
> > > On 2001.08.14 19:12:14 -0400 "Ferguson, Doug" wrote:
> > > > What do you guys think about implemented a version of the DataSource
> > > > loader
> > > > that
> > > > allows for encrypted passwords?
> > > >
> > > > I am required to use encrypted db passwords..
> > > > And I was thinking that even if I encrypt once I write the jboss.jcml
> > > > It is now clear text again..
> > > >
> > > > d.
> > > >
> > > > ___
> > > > Jboss-development mailing list
> > > > [EMAIL PROTECTED]
> > > > http://lists.sourceforge.net/lists/listinfo/jboss-development
> > > >
> > > >
> > >
> > > ___
> > > Jboss-development mailing list
> > > [EMAIL PROTECTED]
> > > http://lists.sourceforge.net/lists/listinfo/jboss-development
> > >
> >
> >
> > ___
> > Jboss-development mailing list
> > [EMAIL PROTECTED]
> > http://lists.sourceforge.net/lists/listinfo/jboss-development
> >
> >
>
> ___
> Jboss-development mailing list
> [EMAIL PROTECTED]
> http://lists.sourceforge.net/lists/listinfo/jboss-development
>
___
Jboss-development mailing list
[EMAIL PROTECTED]
http://lists.sourceforge.net/lists/listinfo/jboss-development
Re: [JBoss-dev] DataSourceLoader...
ResourceAdapterName identifies which resource adapter supplies the
ConnectionFactory (and ManagedConnectionFactory etc etc) for the
ConnectionFactoryLoader to load. (It's the display-name tag in ra.xml) If
you were using firebird as your database, this could be the firebird
jca/jdbc driver. Since we are mostly stuck with jdbc only drivers, this is
typically one of the 2 Minerva wrapper adapters. With the jdbc (local
transaction) wrapper, the "Properties" attribute, which is for configuring
the Resource Adapter, contains the db url which is enough to figure out
which db driver we are using. With enough luck, mainstream db vendors will
decide to supply jca .rar versions of their drivers soon so we don't always
need the Minerva wrappers.
david jencks
On 2001.08.16 14:35:00 -0400 Jason Dillon wrote:
> What is ResourceAdapterName used for?
>
> --jason
>
>
> On Wed, 15 Aug 2001, David Jencks wrote:
>
> > Hi,
> >
> > This discussion comes up in various places on various lists. Since you
> > don't mention otherwise I assume you are planning to decrypt in code
> > without manual intervention. As I understand the consensus is, Don't
> do
> > this. You need some code to unencrypt the password to send it to the
> db,
> > if someone can find your jboss.jcml file they can find the unencryption
> > code. Thus you have implemented only security by obscurity and only
> > succeeded in making life harder for the users and probably given them a
> > false sense of security, encouraging carelessness that a determined
> hacker
> > can exploit.
> >
> > Secrets and Lies by Bruce Schneier is fun to read and explains this
> really
> > well.
> >
> > If you want more security yet don't want to give each user their own
> > password and have per-subject pools, how about writing a
> > ConnectionFactoryLoader that pops up a password dialog on startup ( in
> > initService). It's inconvenient, but at least it doesn't try to fool
> > people into thinking their passwords are hidden. Of course, it could
> be
> > hard to figure out where to pop up the dialog...
> >
> > How about simply encrypting all of jboss.jcml say using pgp and
> requiring a
> > manually entered password to unencrypt to start jboss?
> >
> > In any case if you wish to modify the datasource loading procedure I
> > suggest you work on the jca resource adapter version since
> > {XA|JDBC}DataSourceLoader will not really exist in rh. (they will set
> up
> > connectionFactoryLoader mbeans).
> >
> > david jencks
> >
> > On 2001.08.14 19:12:14 -0400 "Ferguson, Doug" wrote:
> > > What do you guys think about implemented a version of the DataSource
> > > loader
> > > that
> > > allows for encrypted passwords?
> > >
> > > I am required to use encrypted db passwords..
> > > And I was thinking that even if I encrypt once I write the jboss.jcml
> > > It is now clear text again..
> > >
> > > d.
> > >
> > > ___
> > > Jboss-development mailing list
> > > [EMAIL PROTECTED]
> > > http://lists.sourceforge.net/lists/listinfo/jboss-development
> > >
> > >
> >
> > ___
> > Jboss-development mailing list
> > [EMAIL PROTECTED]
> > http://lists.sourceforge.net/lists/listinfo/jboss-development
> >
>
>
> ___
> Jboss-development mailing list
> [EMAIL PROTECTED]
> http://lists.sourceforge.net/lists/listinfo/jboss-development
>
>
___
Jboss-development mailing list
[EMAIL PROTECTED]
http://lists.sourceforge.net/lists/listinfo/jboss-development
Re: [JBoss-dev] DataSourceLoader...
What is ResourceAdapterName used for?
--jason
On Wed, 15 Aug 2001, David Jencks wrote:
> Hi,
>
> This discussion comes up in various places on various lists. Since you
> don't mention otherwise I assume you are planning to decrypt in code
> without manual intervention. As I understand the consensus is, Don't do
> this. You need some code to unencrypt the password to send it to the db,
> if someone can find your jboss.jcml file they can find the unencryption
> code. Thus you have implemented only security by obscurity and only
> succeeded in making life harder for the users and probably given them a
> false sense of security, encouraging carelessness that a determined hacker
> can exploit.
>
> Secrets and Lies by Bruce Schneier is fun to read and explains this really
> well.
>
> If you want more security yet don't want to give each user their own
> password and have per-subject pools, how about writing a
> ConnectionFactoryLoader that pops up a password dialog on startup ( in
> initService). It's inconvenient, but at least it doesn't try to fool
> people into thinking their passwords are hidden. Of course, it could be
> hard to figure out where to pop up the dialog...
>
> How about simply encrypting all of jboss.jcml say using pgp and requiring a
> manually entered password to unencrypt to start jboss?
>
> In any case if you wish to modify the datasource loading procedure I
> suggest you work on the jca resource adapter version since
> {XA|JDBC}DataSourceLoader will not really exist in rh. (they will set up
> connectionFactoryLoader mbeans).
>
> david jencks
>
> On 2001.08.14 19:12:14 -0400 "Ferguson, Doug" wrote:
> > What do you guys think about implemented a version of the DataSource
> > loader
> > that
> > allows for encrypted passwords?
> >
> > I am required to use encrypted db passwords..
> > And I was thinking that even if I encrypt once I write the jboss.jcml
> > It is now clear text again..
> >
> > d.
> >
> > ___
> > Jboss-development mailing list
> > [EMAIL PROTECTED]
> > http://lists.sourceforge.net/lists/listinfo/jboss-development
> >
> >
>
> ___
> Jboss-development mailing list
> [EMAIL PROTECTED]
> http://lists.sourceforge.net/lists/listinfo/jboss-development
>
___
Jboss-development mailing list
[EMAIL PROTECTED]
http://lists.sourceforge.net/lists/listinfo/jboss-development
RE: [JBoss-dev] DataSourceLoader...
Maybe it could be a key/pass combination. Once the password is entered. It is kept in mememory throughout the entire jBoss process. d. -Original Message- From: danch [mailto:[EMAIL PROTECTED]] Sent: Wednesday, August 15, 2001 11:26 PM To: [EMAIL PROTECTED] Subject: Re: [JBoss-dev] DataSourceLoader... Ferguson, Doug wrote: > Well, > > Alot of my datasources are loaded on the fly... > I can't have the type in a password when jboss starts. > Also, when there are many differnet databases... it becomes unmanagable.. > > > d. But if you encrypt the password on disk, you need a key to decrypt it with. Unless you make a sysadmin keep a floppy in a vault with this key on it and only mount that floppy when JBoss is starting, then take it out right away, you'll have to store the key on disk on the same machine where the encrypted passwords are stored. This makes the encrypted password clear-text equivalent. -danch ___ Jboss-development mailing list [EMAIL PROTECTED] http://lists.sourceforge.net/lists/listinfo/jboss-development ___ Jboss-development mailing list [EMAIL PROTECTED] http://lists.sourceforge.net/lists/listinfo/jboss-development
Re: [JBoss-dev] DataSourceLoader...
Ferguson, Doug wrote: > Well, > > Alot of my datasources are loaded on the fly... > I can't have the type in a password when jboss starts. > Also, when there are many differnet databases... it becomes unmanagable.. > > > d. But if you encrypt the password on disk, you need a key to decrypt it with. Unless you make a sysadmin keep a floppy in a vault with this key on it and only mount that floppy when JBoss is starting, then take it out right away, you'll have to store the key on disk on the same machine where the encrypted passwords are stored. This makes the encrypted password clear-text equivalent. -danch ___ Jboss-development mailing list [EMAIL PROTECTED] http://lists.sourceforge.net/lists/listinfo/jboss-development
RE: [JBoss-dev] DataSourceLoader...
Well,
Alot of my datasources are loaded on the fly...
I can't have the type in a password when jboss starts.
Also, when there are many differnet databases... it becomes unmanagable..
d.
-Original Message-
From: David Jencks [mailto:[EMAIL PROTECTED]]
Sent: Wednesday, August 15, 2001 7:52 AM
To: [EMAIL PROTECTED]
Subject: Re: [JBoss-dev] DataSourceLoader...
Hi,
This discussion comes up in various places on various lists. Since you
don't mention otherwise I assume you are planning to decrypt in code
without manual intervention. As I understand the consensus is, Don't do
this. You need some code to unencrypt the password to send it to the db,
if someone can find your jboss.jcml file they can find the unencryption
code. Thus you have implemented only security by obscurity and only
succeeded in making life harder for the users and probably given them a
false sense of security, encouraging carelessness that a determined hacker
can exploit.
Secrets and Lies by Bruce Schneier is fun to read and explains this really
well.
If you want more security yet don't want to give each user their own
password and have per-subject pools, how about writing a
ConnectionFactoryLoader that pops up a password dialog on startup ( in
initService). It's inconvenient, but at least it doesn't try to fool
people into thinking their passwords are hidden. Of course, it could be
hard to figure out where to pop up the dialog...
How about simply encrypting all of jboss.jcml say using pgp and requiring a
manually entered password to unencrypt to start jboss?
In any case if you wish to modify the datasource loading procedure I
suggest you work on the jca resource adapter version since
{XA|JDBC}DataSourceLoader will not really exist in rh. (they will set up
connectionFactoryLoader mbeans).
david jencks
On 2001.08.14 19:12:14 -0400 "Ferguson, Doug" wrote:
> What do you guys think about implemented a version of the DataSource
> loader
> that
> allows for encrypted passwords?
>
> I am required to use encrypted db passwords..
> And I was thinking that even if I encrypt once I write the jboss.jcml
> It is now clear text again..
>
> d.
>
> ___
> Jboss-development mailing list
> [EMAIL PROTECTED]
> http://lists.sourceforge.net/lists/listinfo/jboss-development
>
>
___
Jboss-development mailing list
[EMAIL PROTECTED]
http://lists.sourceforge.net/lists/listinfo/jboss-development
___
Jboss-development mailing list
[EMAIL PROTECTED]
http://lists.sourceforge.net/lists/listinfo/jboss-development
Re: [JBoss-dev] DataSourceLoader...
We need to think about integrating the JBossSX security manager
into the JCA layer and elsewhere to obtain a consistent view of
security. Right now security is very fragmented.
- Original Message -
From: "David Jencks" <[EMAIL PROTECTED]>
To: <[EMAIL PROTECTED]>
Sent: Wednesday, August 15, 2001 5:51 AM
Subject: Re: [JBoss-dev] DataSourceLoader...
> Hi,
>
> This discussion comes up in various places on various lists. Since you
> don't mention otherwise I assume you are planning to decrypt in code
> without manual intervention. As I understand the consensus is, Don't do
> this. You need some code to unencrypt the password to send it to the db,
> if someone can find your jboss.jcml file they can find the unencryption
> code. Thus you have implemented only security by obscurity and only
> succeeded in making life harder for the users and probably given them a
> false sense of security, encouraging carelessness that a determined hacker
> can exploit.
>
> Secrets and Lies by Bruce Schneier is fun to read and explains this really
> well.
>
> If you want more security yet don't want to give each user their own
> password and have per-subject pools, how about writing a
> ConnectionFactoryLoader that pops up a password dialog on startup ( in
> initService). It's inconvenient, but at least it doesn't try to fool
> people into thinking their passwords are hidden. Of course, it could be
> hard to figure out where to pop up the dialog...
>
> How about simply encrypting all of jboss.jcml say using pgp and requiring
a
> manually entered password to unencrypt to start jboss?
>
> In any case if you wish to modify the datasource loading procedure I
> suggest you work on the jca resource adapter version since
> {XA|JDBC}DataSourceLoader will not really exist in rh. (they will set up
> connectionFactoryLoader mbeans).
>
> david jencks
>
> On 2001.08.14 19:12:14 -0400 "Ferguson, Doug" wrote:
> > What do you guys think about implemented a version of the DataSource
> > loader
> > that
> > allows for encrypted passwords?
> >
> > I am required to use encrypted db passwords..
> > And I was thinking that even if I encrypt once I write the jboss.jcml
> > It is now clear text again..
> >
> > d.
> >
> > ___
> > Jboss-development mailing list
> > [EMAIL PROTECTED]
> > http://lists.sourceforge.net/lists/listinfo/jboss-development
> >
> >
>
> ___
> Jboss-development mailing list
> [EMAIL PROTECTED]
> http://lists.sourceforge.net/lists/listinfo/jboss-development
>
___
Jboss-development mailing list
[EMAIL PROTECTED]
http://lists.sourceforge.net/lists/listinfo/jboss-development
Re: [JBoss-dev] DataSourceLoader...
Hi,
This discussion comes up in various places on various lists. Since you
don't mention otherwise I assume you are planning to decrypt in code
without manual intervention. As I understand the consensus is, Don't do
this. You need some code to unencrypt the password to send it to the db,
if someone can find your jboss.jcml file they can find the unencryption
code. Thus you have implemented only security by obscurity and only
succeeded in making life harder for the users and probably given them a
false sense of security, encouraging carelessness that a determined hacker
can exploit.
Secrets and Lies by Bruce Schneier is fun to read and explains this really
well.
If you want more security yet don't want to give each user their own
password and have per-subject pools, how about writing a
ConnectionFactoryLoader that pops up a password dialog on startup ( in
initService). It's inconvenient, but at least it doesn't try to fool
people into thinking their passwords are hidden. Of course, it could be
hard to figure out where to pop up the dialog...
How about simply encrypting all of jboss.jcml say using pgp and requiring a
manually entered password to unencrypt to start jboss?
In any case if you wish to modify the datasource loading procedure I
suggest you work on the jca resource adapter version since
{XA|JDBC}DataSourceLoader will not really exist in rh. (they will set up
connectionFactoryLoader mbeans).
david jencks
On 2001.08.14 19:12:14 -0400 "Ferguson, Doug" wrote:
> What do you guys think about implemented a version of the DataSource
> loader
> that
> allows for encrypted passwords?
>
> I am required to use encrypted db passwords..
> And I was thinking that even if I encrypt once I write the jboss.jcml
> It is now clear text again..
>
> d.
>
> ___
> Jboss-development mailing list
> [EMAIL PROTECTED]
> http://lists.sourceforge.net/lists/listinfo/jboss-development
>
>
___
Jboss-development mailing list
[EMAIL PROTECTED]
http://lists.sourceforge.net/lists/listinfo/jboss-development
[JBoss-dev] DataSourceLoader...
What do you guys think about implemented a version of the DataSource loader that allows for encrypted passwords? I am required to use encrypted db passwords.. And I was thinking that even if I encrypt once I write the jboss.jcml It is now clear text again.. d. ___ Jboss-development mailing list [EMAIL PROTECTED] http://lists.sourceforge.net/lists/listinfo/jboss-development
