I'm having the same sort of problem as some other poster regarding JDBC.
I've tried some examples, but the problem I have is in the fact that every example seems to show hard codes of the url and password.
That's great, but is there a way to get a database connection where the url and password from the users who log on can be used to connect to the database?
I can have the users log on to secured areas on the web, then connect them to the DB using a connection pool where it's basically a standard non-expiring password/url JDBC connection to connect to a DB.
The problem is, the project i'm working on needs to know who is connecting to the DB, for how long, and for what. The DB is on a mainframe system and if a user connects to it, that is how the customer's are charged.. For mainframe usage and such.
If they log in to the website, connect through the standard connection pool, there really isn't a way to charge them without making it a drawn out difficult process that will be left to whoever is maintaining the system. For all intensive purposes, it would just look like the connection pool should be charged. that won't work.
Right now i'm using j_security_check for loggin users into secured area's on the web and because that what was recommended to me, and it's already been setup on the app server to work with the mainframe db and users/password combos. So it was the best way to get users logged in.
I need to know or need some help on a way for Me to login through j_security_check, where it checks if i am a valid user, and then it connects to the DB using their username/password and not the standard conneciton pools username/password.
If that can't be done, I could just make it where anytime somebody connects to the mainframe DB, they have to log in.
But is there a way, with j_security_check, to be able to log or follow how long a user has accessed or been logged in so the customer can actually be charged for mainframe usage.
That is the way it is done and that' s the way they want to keep it. Be able to charge the user for mainframe usage.
Maybe it's not entirely a JDBC issue, but it is a combo of JDBC issues where i need a way to connect a user to a DB using their username/pw combo and not a standard JDBC connection pool username/password and on top of that, if that isn't possible, then I have to figure out a way with j_security_check to keep a log or something.
It sounds like you are trying to use database authentication for user authentication and if so there's a good reason you're having trouble, its not a good or recommended practice. Database authentication is generally used to either read the database and/or write to the database, but user-level locking is rarely done in the contexts of an application.
There are many long answers to why this is, but the short answer is that database authentication technology was abandoned as being too difficult to use and a severely limited security module. What is generally done is that the application makes a connection to the database and it enforces user-level security with information stored in the database. For example, each user might have a security record in a database table corresponding to their ability to read/write a particular data record. You're better off creating your own security module and enforcing constraints using a unified connection. The only time you would want to change database users is if the purpose the module change, not the user (but in that case I would recommend a different module) [ January 15, 2007: Message edited by: Scott Selikoff ]
Right now, I've basically set it up to where if the user needs to access the mainframe DB, they have to login. The login portion sends them to a login page where they have a set username and password and it's using j_security_check in websphere.
I've looked at other ways that it can be done, but management and the admins use something called RACF and it's setup to work inside of websphere with j_security_check.
So basically user logs in the web, j_security_check reads something in websphere which is then sent to the mainframe via Racf.
That all works fine.. There are better ways to do it, but this is the way the system works and they don't want to change that part of it.
But the major issue is to where i use the JDBC connection to retrieve, update, change records in the DB.
I can do all that stuff now using a connection pool, but the management wants to have each user connect to the DB..
They charge each user for CPU time and so on. If there were one connection only, it becomes hard to charge each user who logs onto the mainframe system because for all intensive purposes, it's just one DB connection.
That might get around the whole connection pooling issue. Because like I said, they charge each customer/user every time they use the mainframe system.
Right now, with one connection pool, it would just show "ROLE A" always uses the mainframe. Problem is if ROLE A has 50 people doing different things.