db-derby-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Stanley Bradbury <Stan.Bradb...@gmail.com>
Subject Re: Storing session/connection data.
Date Wed, 28 Nov 2007 20:46:36 GMT
Hi Antonio -
If you require username and password authentication at both the database 
and the client/application level then I cannot think of an easy way to 
avoid duplicating the client/application and database logins.  If, on 
the other hand, you do not need authentication active in Derby you can 
just pass the username on the connection URL and this will be picked up 
by CURRENT_USER.  Example:

ij version 10.3
ij> connect 'jdbc:derby:103toursdb;create=true';
ij> values current_user;
1
-------------------------------------------------------------------------
APP

1 row selected
ij> connect 'jdbc:derby:103toursdb;user=FRED';
ij(CONNECTION1)> values current_user;
1
-------------------------------------------------------------------------
FRED

1 row selected
ij(CONNECTION1)> connect 'jdbc:derby:103toursdb;user=SUSAN';
ij(CONNECTION2)> values current_user;
1
-------------------------------------------------------------------------
SUSAN

1 row selected

HTH

Antonio David Sánchez Nadal wrote:
> Hello.
>
> Is there any way I can store data for a connection session? I am talking
> about the equivalent of session data in a web application, for instance.
>
> This my requirement: 
> I am developing a client/server Java application using derby, any Java
> client will have its own connection to the database (no multi-tier). The
> application manages its own table of users and connects to the database
> with a different, specific derby database user. I also need to audit the
> database on the basis of the application user by means of triggers. But
> I don't know how to make derby remember the application user for the
> current session/connection, CURRENT_USER function retrieves the derby
> dabase user tha was used to connect the database (the same for all
> application connections). I would also prefer to avoid a database
> request from client in order to carry out the audit operation, i.e., not
> using triggers.
>
> If it is not possible to do this, is it a standard practice in an
> application like this to map application users to database users? I
> prefer avoiding this for aplication security and maintainability
> reasons.
>
> Hopefully someone can help me with this.
>
> Thanks for your time and kind regards.
> Antonio.
>
>
>
>
> 		
> ______________________________________________ 
> LLama Gratis a cualquier PC del Mundo. 
> Llamadas a fijos y móviles desde 1 céntimo por minuto. 
> http://es.voice.yahoo.com
>
>   



Mime
View raw message