1. Why not just let the user log in using the SQL Login and don't store the info in the connection. I don't populate those fields since they are not secure.
2. Putting a copy of the .DBC on the client machine would solve this and other issues.
BOb
<i><font color="#663300">Hey all,
I have another question. I am developing a Client/Server app which is using ODBC to connect to an Oracle database. My remote views are using a connection in the database container. When a user logs on providing a username and password, the application alters the userid and password of the connection. Now only the data available to the currently signed on user is pulled from the database, all other data access returns an error that the table or view does not exist. A problem became apparent when a second user logged on. The second user altered the database connection to reflect their userid and password, exposing only the data available to their login. Unfortunately, since I am only using one connection, now both users have the same data rights and privileges, which is not the behavior that I want, as you can imagine.
I came up with two options. One would be to create a connection for every user. The other would be to create a new connection for each user as they logged on, and delete the connection when they logoff. Both would solve my problem.
The issue I have now is that, while the users are logged on, their userid and password information is stored in the dbc file, available to anyone on the network who knows where the dbc is located and who has VFP loaded on their machine.
My assumption is that there is a more secure way of doing this, and my
plea is for someone to give me options.
I do not want to store versions of the dbc on all the user's local machines. I am not sure what including the dbc in the project when I create the exe will accomplish.</font></i>
©2002 Bob Archer |
