Re: using a datasource connection pool resource with username and password supplied by user

2005-10-10 Thread Bob Hall
Jefferey, Coming into this thread late, but I'm curious. Why do you want each user to obtain a connection to the database, effectively logging into the DB, instead of using a connection pool with a single, application specific, DB userid/password? - Bob --- [EMAIL PROTECTED] wrote: Thanks

RE: using a datasource connection pool resource with username and password supplied by user

2005-10-10 Thread Akoulov, Alexandre [IT]
Hi Jeff, I will implement storing the connection in the session with the log out killing the connection. what happens if the user never logs out? then your Tomcat might end up with quite a few open connections that it cannot close and the only way to close such connections would be to

Re: using a datasource connection pool resource with username and password supplied by user

2005-10-10 Thread jeffery . s . eaton
Good question Bob, This system may eventually be implemented for the government department I work for in Queensland, Australia. This project is a pilot one which will involve four separate district offices in four different cities. The department has policies on data security which includes

RE: using a datasource connection pool resource with username and password supplied by user

2005-10-10 Thread jeffery . s . eaton
That's right Sasha, I will have to ensure connections are closed down automatically if the user doesn't log out, but at this stage I will note your comment for further research. Thanks, Jeffery S. Eaton Opinions contained in this

Re: using a datasource connection pool resource with username and password supplied by user

2005-10-10 Thread Bob Hall
Jefferey, Are the uses going to be allowed to execute ad hoc queries? If yes, I can see why you would choose to take the take the direct DB authentication route. If not, then a a JDBCRealm could be used and specific role(s) assigned to each user that would govern what they could do in the

Re: using a datasource connection pool resource with username and password supplied by user

2005-10-10 Thread jeffery . s . eaton
Thanks for the suggestion Bob, I think what you are saying about realms is valid and most likely the easiest way to enforce security. It would be my choice if it wasn't a corporate standards issue. I will read up on the link you sent and see if I can get away with it in terms of meeting with

[OT] Re: using a datasource connection pool resource with username and password supplied by user

2005-10-10 Thread Bob Hall
If the DB login requirement is removed you might want to take a look at Apache Turbine, it supports finer-grained access to a web app. http://jakarta.apache.org/turbine/index.html - Bob --- [EMAIL PROTECTED] wrote: Thanks for the suggestion Bob, I think what you are saying about realms is

RE: using a datasource connection pool resource with username and password supplied by user

2005-10-09 Thread Caldarale, Charles R
From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] Subject: using a datasource connection pool resource with username and password supplied by user But what I really want to do is to get a database user and password from the user and (after validating it) write this to a session

Re: using a datasource connection pool resource with username and password supplied by user

2005-10-09 Thread Parsons Technical Services
Chuck is right in that it can't be done with the standard pool that Tomcat has. Due simply to the fact that the pool is established before anyone has made a call to the server. But what you could do is to create a connection for that user when they authenticate and hold on to the connection

Re: using a datasource connection pool resource with username and password supplied by user

2005-10-09 Thread jeffery . s . eaton
Thanks Doug and Chuck, I suspected as much re. the connection pool. This sort of negates the value of it a little (for me anyway). My original plan was to go with saving the connection to the session once it was established but I had read somewhere that connections are not 'serializable' and