HI All,
i wish begin to work about a feature new for me ,i'n my project i have a database( with SqlServer) and an application (developing in WPF) the purpose of this application is to manage/handle about Accountancy and other Departement,so i created a Passwords and Roles(for Users) to access in the application ,now i will create a system to knows how many Usera are connected to the Application(via Database )and show that in a listBox(for example like a normal Chat Application i wish knows who is online and offline) but i don't know where i need begin to work out this feature ,i'm strange to this feature so if you have any suggestion,link and else i will appreciate so much your help.
Thanks so much.
P.S. if my question is not clear i will rewrite it...however sorry in anticipate
Without knowing the details of your application, I would suggest setting a timestamp field in the database when they log in, and then set it again every X minutes while they are logged in. This has two advantages over just setting a flag:
1) If the application crashes, or the user's machine crashes, the flag will not be reset, and you will have no way of knowing that they are not still logged in.
2) The timestamp will tell you the last time each user was logged in, even if they are not logged in currently.
Maybe in the database itself? When the user logs in, you can set a flag for each user "LoggedInd = true", and when they log out "LoggedIn = false". And do a query on that flag "SELECT * FROM Users WHERE LoggedIn = true"
Related
I had some problems with using the authorization before so I got a brand new everything - new computer, new OS, fresh installation of VS, new app and DB in a new resource group on the Azure. The whole shabang.
I can confirm that I can log in to the Azure DB as the screenshots below show.
I can see the databases, tables, users etc.
The problem is that, although it works locally (using the default connection string provided automagically for me), it doesn't perform very well in the Azure (although I'm using the publish file from there). It said something about the file not being found and according to this answer, I needed to change the connection string.
After I've altered it, I get the following error. Please note that the firewall is open and that I can access the DB when I run the code of my applications. I feel that there's something that goes wrong when the authentication part is automatically configured. I'm out of ideas on how to trouble-shoot it, though.
[SqlException (0x80131904): Login failed for user 'Chamster'.
This session has been assigned a tracing ID of '09121235-87f3-4a92-a371-50bc475306ca'. Provide this tracing ID to customer support when you need assistance.]
The connection string I'm using is this.
Server=tcp:f8goq0bvq7.database.windows.net,1433;
Database=Squicker;
User ID=Chamster#f8goq0bvq7;
Password=Abc123();
Encrypt=True;
TrustServerCertificate=False;
Connection Timeout=10;
This issue's bothered me for a while and I'll be bounting it in two days. Any suggestion's warmly appreciated.
I believe I've managed to resolve this weird issue. It appears that the user I'm using, despite being admin with all bells and whistles isn't recognized as admin when used in the connection string and trying to create the tables (which is the case at the first registration).
My solution was to create two logins - one with db_owner role and one with db_datareader and db_datawriter. First, I've used the elevated user in my connection string and registered a single user. That created the tables in the database as shown below.
Then, while able to continue as admin, I realized that we should try the demoted user and tada!, it worked perfectly. Once the tables were there, the whole shabeling behaved as expected.
To be perfectly sure, I dropped the tables from the database and there it was - the same issues as before. When I changed to the elevated user, the tables were restored allowing me to get back to the demoted one.
I also tried dropping the tables, confirming the issues to re-appear and then creating the tables manually. That works too! So basically,the only gotcha that caused it all was the original admin who's not treated as admin.
It might have to do with the fact that my Azure account's getting a bit old, LiveID used there is ancient and that didn't have an updated version of DB in Azure (the pull-up to v12 was carried out the 18th of December, so it's possible that it also was a requirement to get it working). I'm too tired and lazy to check that out and I realize that I've no idea how to get an "old" type of account. Besides, the issue will decrease and gradually vanish because the old accounts get upgraded eventually.
I can login with username and password when internet is connected. If I disconnect internet when logged in I can still listen to offline lists. If I reconnect internet I get full functionality again without any actions on my part.
But when internet is unavailable when I start my application I cannot login to listen to offline tracks.
I have tried to login with blob instead of password without success (with or without internet). I have also played around with "rememberme" but that does not seem to survive a restart of my application.
I have tried empty strings ("") as well as IntPtr.Zero for password and blob when using the other.
No success. What am I doing wrong?
I think that #Kendall Frey hit the nail on the head, offline support is implemented in libspotify, but you probably at least need to be online to get it started. This isn't the case in Spotify's mobile and desktop clients, however they are not built on libspotify. So sorry, I don't believe that there is any way around this limitation.
Offline login should actually work in libspotify using the credentials blob under the following conditions:
The user has successfully logged in online at least once before.
You are allowing libspotify to create and maintain an on-disk cache.
libspotify is able to correctly write credentials to that cache and verify them next time.
You are correctly allowing libspotify to clean up as your application exits.
The cache is the important part here. You must pass libspotify a location on-disk that's readable and writeable.
Also very important is logging out correctly. You must either log out the user and wait for that process to complete as your application exits or call flush_caches() and wait for that to complete. Otherwise, libspotify won't be able to correctly write to the cache to enable offline login next time. If you're just exiting your process without proper libspotify cleanup, offline login won't work.
You were absolutely correct iKenndac!
In fact the problem was behind the keyboard, as I got confused by the connection states and the sp_error of the login callback.
I did in fact log in successfully the same way as I did when connected. That is with username and password and "remember me".
Confusion came from the comments in api.h
SP_CONNECTION_STATE_LOGGED_OUT = 0, ///< User not yet logged in
SP_CONNECTION_STATE_LOGGED_IN = 1, ///< Logged in against a Spotify access point
SP_CONNECTION_STATE_DISCONNECTED = 2, ///< Was logged in, but has now been disconnected
SP_CONNECTION_STATE_UNDEFINED = 3, ///< The connection state is undefined
SP_CONNECTION_STATE_OFFLINE = 4 ///< Logged in in offline mode
When I start my app without internet connection I first get login callback saying SP_ERROR_OK and then I get SP_CONNECTION_STATE_DISCONNECTED (Was logged in, but has now been disconnected)
I expected SP_CONNECTION_STATE_OFFLINE (Logged in in offline mode) when not connected to internet.
But "now working"
I have a desktop C# application, several clients are connected into SQL server. Each user has an ID and Password. what do i want is to prevent an already logged-in user to log-in from another computer.
I have implemented it by updating a Field in the database 'UserLoggedIn'=true at the login, and when the user logs out the Field Updated into False. But this solution is not optimal, in which if the system crashed or the computer shutdown unexpectedly, the value will stay 'UserLoggedIn'=True in the database and this user will never can log-in again to the system.
What is the optimal solution for that, and prevent an already logged-in user from logging-in from another computer?
Instead of true, store a timestamp in the database. Make sure that you update it periodically while the user is logged in.
When they log in, allow them if it's not too new. That is: if you've seen them from another PC within the last (say) 30 seconds, then consider that session still live, and reject the new login.
This way, if their other PC crashes, the timestamp will not be updated, and will eventually expire.
The update frequency should be about twice the expiry timeout. For example, if you want a session expiry of 1 minute, you should update the timestamp every 30 seconds.
I would suggest that you check if the user has already established a connection to the database using the following query
SELECT loginame as LoginName,program_name
FROM sys.sysprocesses
WHERE db_name(dbid)='my_database' and loginame='test_user'
If the number of records returned is greater than zero then you can assume that a user has already connected to the database from your application.
If you look at the connection string property in MSDN, you will find the following properties of interest. These 2 properties can be added to your existing connection string to further improve the filters that can be defined in the query above
Application Name - The name of the application, or '.Net SqlClient Data Provider' if no application name is provided. (=program_name in the table above)
Workstation ID - The name of the workstation connecting to SQL Server. (=hostname in the table above )
I believe that this solution will work irrespective of crashes on the client side and does not require that you save the state in any table.
In my database on my SQL Server I have a table with users. This table have a column named logged_on which is a bit, either true or false. When someone log on the column will be true, else false. If something ever happens when someone is using my wpf-application, like the power disappears and the application couldn't log out the user this column will be true and the user will not be able to login again, because the application will tell this user that he is already logged on. Is there something i could do to avoid this situation? On the server-side or in the application?
Any sugestions are appreciated :)
I think you'll need a "LastActive" date-time stamp. Then run a scheduled job that says "if you've been inactive for X minutes, change the state of the logged_on flag".
Are you trying to insure that only one login can be active at the same time? Is that the end game?
Sounds like you need to change the approach a little, perhaps tracking last interaction date/time (every time the WPF app calls SQL) and enforcing a session timeout limit instead. You could use that DateTime to automatically log out anyone that hasn't interacted with the server in several minutes by checking it in addition to the *logged_on* bit field (always switching *logged_on* to false if the DateTime is too stale).
Is there an important reason you can't just throw away the old login in situations where the user logs in again without logging out first?
Why does the drop user a_2 command not work when I try to use it in C#, while when I tried it in SQL Server Management Studio, it works there !!???
This is the code that I used it when I create the user & give it a permission:
use DataBaseName;
create login a_2 with password='Aa123';
create user a_2 for login a_2;
grant insert to a_2;
..........
The connection string used :
Data Source=TheServerName;Integrated Security=True;database=master
Note:
I tried to drop a database from C# and it works perfectly without any problem, but when I use it to drop a user the problem raised here !!!
This is the exception that gets raised
Exception is: Cannot drop the user
'a_2', because it does not exist or
you do not have permission.
I believe your problem is that "you do not have permission". Your application is running as a different user from you. You can solve this by either giving the default application user the necessary permissions on the database (not a good idea) or by creating a special user in the database for your application and having the application run as that user.
Be aware that giving your application (or any user, for that matter) permissions to drop users could be very risky if someone figures out how to hack your application. And you aren't actually including the ability to drop the database in your app, are you? Think about it. Instead of creating users in the database, consider creating a Users table just for your application. Then your users won't have such extensive rights to your actual database.
DROP USER would require use DataBaseName;
Or a different connection string
Data Source=TheServerName;Integrated Security=True;database=DataBaseName
That is, the DROP USER only makes sense in the context of your database. When you run it later you are in the context of master = fail.