[DBCP] Why Not Supported? BasicDataSource.getConnection(String username, String password)

[Mark Barnes <ma...@coat.com>]

Hi, All -

I originally submitted this to Commons User some time ago, but no reply.

I know that method org.apache.commons.dbcp.BasicDataSource.getConnection(String username, String password) winds up throwing an UnsuppoterdOperationException via its delegate, org.apache.commons.dbcp.PoolingDataSource.

My question is, can anyone who knows why this was done please let me know?




I've googled and googled for an answer, but have not been able to find one.




Why the non-standard API?

Why methods getUsername() and getPassword()?

Why store the username and password as plain text?




On my current project, placing the database username and password in a file on disk is not allowed, due to security concerns, so using a Container-managed DataSource is not possible.




My thanks to anyone who can provide information and insight.
---Mark

---------------------------------------------------------------------
To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: commons-dev-help@jakarta.apache.org

Re: [DBCP] Why Not Supported? BasicDataSource.getConnection(String username, String password)

[Phil Steitz <ph...@gmail.com>]

On 10/3/06, Mark Barnes <ma...@coat.com> wrote:
> Hi, All -
>
> I originally submitted this to Commons User some time ago, but no reply.
>
> I know that method org.apache.commons.dbcp.BasicDataSource.getConnection(String username, String password) winds up throwing an UnsuppoterdOperationException via its delegate, org.apache.commons.dbcp.PoolingDataSource.
>
> My question is, can anyone who knows why this was done please let me know?
>
I can't speak for the original designers, but it makes sense to me
that a connection pool wrapper such as BasicDataSource would not
support this.  BasicDataSource provides access to a pool of
connections that with a common set of connection properties when it is
initialized.  To support getConnection(username, password), the pool
would have to be recreated if the actual parameters were different.  I
suppose that is possible and the same thing should be possible using
setUsername, setPassword, getConnection; but the latter actually does
not work.  If you (or anyone else) feels strongly enough about the
need to be able to regen the pool with different user, pass
credentials, then pls open a ticket.  It looks like support for doing
this after the setXxx above was planned at some point, but never
implemented (cf restartNeeded instance variable).
>
>
>
> I've googled and googled for an answer, but have not been able to find one.
>
>
>
>
> Why the non-standard API?
>
> Why methods getUsername() and getPassword()?
>
All config properties are exposed via javabeans properties. Is your
concern about this security-related?

> Why store the username and password as plain text?
>
I don't know what you mean here.  These parameters are passed to the
connection factory used to open the actual connections. They are not
"stored" anywhere other than in memory.
>
> On my current project, placing the database username and password in a file on disk is not allowed, due to security concerns, so using a Container-managed DataSource is not possible.
>
Do you mean stored in the code?  If you want to store the credentials
encypted somewheret and have a component decrypt and pass them to
BasicDataSource at initialization time, you can do that, but there is
no facility built in to [dbcp] to support the crypto, and I don't
think that we be good separation of concerns.  The [dbcp] component
just needs the unencrypted parameters to store in memory and pass on
to the driver.  If having these credentials in memory as properties is
a concern, that will be difficutl to address.

Phil
>
>
>
> My thanks to anyone who can provide information and insight.
> ---Mark
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
> For additional commands, e-mail: commons-dev-help@jakarta.apache.org
>
>

---------------------------------------------------------------------
To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: commons-dev-help@jakarta.apache.org