Return-Path: Delivered-To: apmail-db-derby-user-archive@www.apache.org Received: (qmail 89944 invoked from network); 28 Nov 2007 20:47:15 -0000 Received: from hermes.apache.org (HELO mail.apache.org) (140.211.11.2) by minotaur.apache.org with SMTP; 28 Nov 2007 20:47:15 -0000 Received: (qmail 22095 invoked by uid 500); 28 Nov 2007 20:47:01 -0000 Delivered-To: apmail-db-derby-user-archive@db.apache.org Received: (qmail 22063 invoked by uid 500); 28 Nov 2007 20:47:01 -0000 Mailing-List: contact derby-user-help@db.apache.org; run by ezmlm Precedence: bulk list-help: list-unsubscribe: List-Post: List-Id: Reply-To: "Derby Discussion" Delivered-To: mailing list derby-user@db.apache.org Received: (qmail 22052 invoked by uid 99); 28 Nov 2007 20:47:01 -0000 Received: from nike.apache.org (HELO nike.apache.org) (192.87.106.230) by apache.org (qpsmtpd/0.29) with ESMTP; Wed, 28 Nov 2007 12:47:01 -0800 X-ASF-Spam-Status: No, hits=-2.8 required=10.0 tests=RCVD_IN_DNSWL_MED,SPF_NEUTRAL X-Spam-Check-By: apache.org Received-SPF: neutral (nike.apache.org: 32.97.182.143 is neither permitted nor denied by domain of Stan.Bradbury@gmail.com) Received: from [32.97.182.143] (HELO e3.ny.us.ibm.com) (32.97.182.143) by apache.org (qpsmtpd/0.29) with ESMTP; Wed, 28 Nov 2007 20:47:02 +0000 Received: from d01relay02.pok.ibm.com (d01relay02.pok.ibm.com [9.56.227.234]) by e3.ny.us.ibm.com (8.13.8/8.13.8) with ESMTP id lASKkdj0029181 for ; Wed, 28 Nov 2007 15:46:39 -0500 Received: from d01av01.pok.ibm.com (d01av01.pok.ibm.com [9.56.224.215]) by d01relay02.pok.ibm.com (8.13.8/8.13.8/NCO v8.7) with ESMTP id lASKkdLn474948 for ; Wed, 28 Nov 2007 15:46:39 -0500 Received: from d01av01.pok.ibm.com (loopback [127.0.0.1]) by d01av01.pok.ibm.com (8.12.11.20060308/8.13.3) with ESMTP id lASKkdC1009598 for ; Wed, 28 Nov 2007 15:46:39 -0500 Received: from [127.0.0.1] (sig-9-48-107-161.mts.ibm.com [9.48.107.161]) by d01av01.pok.ibm.com (8.12.11.20060308/8.12.11) with ESMTP id lASKkbFK009542 for ; Wed, 28 Nov 2007 15:46:38 -0500 Message-ID: <474DD3AC.8040703@gmail.com> Date: Wed, 28 Nov 2007 12:46:36 -0800 From: Stanley Bradbury User-Agent: Thunderbird 2.0.0.9 (Windows/20071031) MIME-Version: 1.0 To: Derby Discussion Subject: Re: Storing session/connection data. References: <1196216828.23491.22.camel@antonio-laptop> In-Reply-To: <1196216828.23491.22.camel@antonio-laptop> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit X-Virus-Checked: Checked by ClamAV on apache.org 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 > >