disallow multiple connections for a login
-
Hi there! is there a way to disallow multiple connections for a login? During login, I would like the server to check whether the login is already connected or not. If it is, I would also want to send a message to the user's client that the login used is already connected. I just want to avoid the case where a user may run a client more than once with each instance connected to the server. Thanks in advance.
-
Hi there! is there a way to disallow multiple connections for a login? During login, I would like the server to check whether the login is already connected or not. If it is, I would also want to send a message to the user's client that the login used is already connected. I just want to avoid the case where a user may run a client more than once with each instance connected to the server. Thanks in advance.
Assuming you are using SQL SErver (we need to know this as servers are different). I would expect this to be a client requirement, most apps use a SQL Server set of credentials to connect. However sql server can identify the workstation connection if it is in the connection string and if you are using Windows authentication yeck the database knows who you are. You can always rat through the sysobjects and find this information, it will be a challenge getting the connection event and informing the client. As said this should be done at the client.
Never underestimate the power of human stupidity RAH
-
Assuming you are using SQL SErver (we need to know this as servers are different). I would expect this to be a client requirement, most apps use a SQL Server set of credentials to connect. However sql server can identify the workstation connection if it is in the connection string and if you are using Windows authentication yeck the database knows who you are. You can always rat through the sysobjects and find this information, it will be a challenge getting the connection event and informing the client. As said this should be done at the client.
Never underestimate the power of human stupidity RAH
Thanks Holmes. I was wondering whether there is a command to set this check on the server. With the presence of the 'InfoMessage' event in the 'ADO.Net' provider, I thought of sending the message from the server so that it will be trapped in the 'InfoMessage' event for the client. My first try was checking the connection and login from 'master..sysprocesses' using the client. I think I will have to stick to that if it will be difficult doing it on the server and also send the message.
-
Hi there! is there a way to disallow multiple connections for a login? During login, I would like the server to check whether the login is already connected or not. If it is, I would also want to send a message to the user's client that the login used is already connected. I just want to avoid the case where a user may run a client more than once with each instance connected to the server. Thanks in advance.
I don't think what you describe would work very well -- what if the client crashes and tries to get reconnected? What I do is have the login process assign a GUID to the "session" and the client must provide that GUID with each following access. But I have a second login effectively log the other session out.
-
Hi there! is there a way to disallow multiple connections for a login? During login, I would like the server to check whether the login is already connected or not. If it is, I would also want to send a message to the user's client that the login used is already connected. I just want to avoid the case where a user may run a client more than once with each instance connected to the server. Thanks in advance.
-
Dan_K wrote:
I just want to avoid the case where a user may run a client more than once with each instance connected to the server.
Why? That is really a problem for the client app, not the database.
I do understand your point jschell. But I want to know how the database server can provide support. In Win32 API programming, FindWindow() can be used to detect whether the client application is already running on the computer so that I disallow multiple instances. I wrote the client application in .Net but I do not know the way around it in this Framework. But even if that is solved, a user can run the client application from different computers using the same login name. That's what I want to avoid and the reason why I am thinking of a support from the database server.
-
I do understand your point jschell. But I want to know how the database server can provide support. In Win32 API programming, FindWindow() can be used to detect whether the client application is already running on the computer so that I disallow multiple instances. I wrote the client application in .Net but I do not know the way around it in this Framework. But even if that is solved, a user can run the client application from different computers using the same login name. That's what I want to avoid and the reason why I am thinking of a support from the database server.
Dan_K wrote:
a user can run the client application from different computers using the same login name
That is a different issue to the multiple logons. PieBalds response addresses this, if you don't kill the initial session you are going to run into timeout issues. How does the server know if the initial client logon has not in fact logged off the client - you don't. There is not built in server functionality for this as it is not a server function. There have been many kludges to address the issue, keeping track of connections/logons etc. All have their shortcomings.
Never underestimate the power of human stupidity RAH
-
I do understand your point jschell. But I want to know how the database server can provide support. In Win32 API programming, FindWindow() can be used to detect whether the client application is already running on the computer so that I disallow multiple instances. I wrote the client application in .Net but I do not know the way around it in this Framework. But even if that is solved, a user can run the client application from different computers using the same login name. That's what I want to avoid and the reason why I am thinking of a support from the database server.
-
Dan_K wrote:
That's what I want to avoid...
Still back to my point - why is that a problem? What business requirement is going to fail if it does happen?
Well, users will be working on confidential data. I have been thinking of more possible threats and thought that a user may give his/her login details to someone not supposed to be part of the work who may connect from another system just to influence the results in their favour. jschell, do you think it cannot happen?
-
Well, users will be working on confidential data. I have been thinking of more possible threats and thought that a user may give his/her login details to someone not supposed to be part of the work who may connect from another system just to influence the results in their favour. jschell, do you think it cannot happen?
Dan_K wrote:
Well, users will be working on confidential data.
Define what type of "users". A help desk person? Operations? A consumer?
Dan_K wrote:
I have been thinking of more possible threats and thought that a user may give his/her login details to someone not supposed to be part of the work who may connect from another system just to influence the results in their favour.
I don't know what the last part of that means but as for the first exactly what are you doing to protect from the following scenario? User A gives their credentials to X. User A works on something then logs off. User X logs on then does something 'wrong' then logs off.
-
Well, users will be working on confidential data. I have been thinking of more possible threats and thought that a user may give his/her login details to someone not supposed to be part of the work who may connect from another system just to influence the results in their favour. jschell, do you think it cannot happen?
Your client can place locking records in your database to point out that a user has loged in (like semaphore locks). At closure of the client the record must be removed. In our system we have a special server application that checks every minute whether a lock is still valid, and otherwise removes it. Upon a crash of a client you wont have a lockout for long. To be able to see who has accessed the data, you could make an audit system: Log which user signed in from which computer, what he has done etc. This can be done by various methods: - the client app writing extra records - triggers in the database - the higher versions of SQLServer have tables that store information about performance of performed queries etc. Maybe those are helpfull also. - ...
Regards ... OttO
-
I do understand your point jschell. But I want to know how the database server can provide support. In Win32 API programming, FindWindow() can be used to detect whether the client application is already running on the computer so that I disallow multiple instances. I wrote the client application in .Net but I do not know the way around it in this Framework. But even if that is solved, a user can run the client application from different computers using the same login name. That's what I want to avoid and the reason why I am thinking of a support from the database server.
Hi Dan, I don't know what programming language you are using, but here is the logic. I'm sure you can apply it on any language; 1. Create a shared folder with read/write authorization for Everyone on the server. 2. In my apps, every user has their own GUID primary key on the database. 3. Suppose one user has a primary key 0D5FF2C1-9710-47EF-86FE-164E6170EEFD . Each time this user log in to the system, check if there is a text file named 0D5FF2C1-9710-47EF-86FE-164E6170EEFD.TXT in the shared folder on the server. If it doesn't exist, go to step (4). If it exists, try to delete it. If the deletion success, then continue to step (4). If the deletion fail, then other workstation is using this login ID is being used. You might want to show some message and redirect the program flow to the exit routine. 4. Create a text file named 0D5FF2C1-9710-47EF-86FE-164E6170EEFD.TXT on the server and keep it open while the apps is open (don't close the file handle). 5. Upon exit, close the TXT file handle and delete the text file. By locking the handle, as long as the user is login, other client could not delete the file. If the initial client crash somehow, then the lock to the text file would be released by the server OS, thus, other workstation would be able to delete the text file (and login with the user id). Others might have better solution. Yes, this is not a SQL solution. And might not be elegant enough for most programmers/system developer. But it works :) hth, foxyland