I have a WPF application that:
Takes user input, stores it into a database
Reads from a database and displays it on the screen
Currently is just using SqlConnection method to execute and query a SQL Server database
When deployed, this application will have multiple within network users that should be able to connect to the application and read/write to it as well. Of course, this database is user access controlled, and the end users don't have access to the SQL Server instance. The only ways I can think of connecting are:
Using a generic account that has access to the database and then including that in the connection string.
Creating a REST API to pass requests to the database, bit unsure on details.
What would be the best way to go about this?
REST API would add a level of complexity and additional infrastructure requirements to your application. It would also add an opportunity to use the application outside your network, so that may be a plus. However, if that's not the anticipated use case, it's probably overkill
Also, REST would still need an account to access the database, so it's not really better than your first idea. Depending on the WPF part, you may also have to change the access to the data (for example, using web service clients instead of EF).
Perhaps you can add your users to the database and give them limited privileges to only access selected tables, views or stored procedures. This can add a fine grained control of who and what on the database level. However, this requires a bit or lot of work, depending on the number of your users.
So, your first idea is the easiest one and can probably be expanded to the separate database accounts for your users, while REST probably requires a bit of additional work and setting up the web server etc.
Related
Using multiple database connection string in web application web confing and changing the connection string base on the user in app_code file
I am working on a asp.net c# web appliaction where we have multiple connection strings defined in web config with differnet names and differnet databases, where the database name is selected based on the user at login, I have defined a public static sting 'db_name' in app code file (cs) and a public connection string in the same app code and passed the 'db_name' in the name proprty of connection string.
I am facing a issue where when mltiple users login at the same time ,all the data is stored in the database of the latest user logined.
I wanted to know wether the app code file complies evry time a new user login and that complied file is used for other user
I doubt you can achieve this in a production envorment.
App_code will likely be re-compiled if you have a conneciton string class inside of app_code.
In fact, I don't use app_code anymore, since IIS will attempt to re-compile that code EVEN WHEN using a web site application that deploys compiled code.
So, I create a folder called MyCode, and place my class(s) and code inside of that.
But, your case gets MUCH worse. Since if you modify web.config, then IIS will detect this, and not only (often) trigger a re-compile of app_code, but will also do a WHOLE app_pool re-start, and that will blow out all users current session.
This idea of having each user their own database?
Nope, not even close to practial.
What happen after 50 users a and 50 databases, and you NOW want to change a database. Maybe a simple addition of a new view, or stored procedure. What now, you going to modify 50 databases?
You REALLY can't design ANY software, let alone web based software to work this way. I suppose on a desktop, ONE user can open ONE excel file, then close, and then open another.
However, in datbase land, and "espeically" web based?
You already dealing with a so called "state-less" system, and attempts to use mutliple different datbases created for each user?
Nope, not even close to ANY kind of practial design, and it NOT done, and thus even worse, the tools, the software, the system, the design approach?
ALL of your designs will have built around the assumption of a ONE database, and attempts to shoe-horn in some design that out of the blue is going to change the connection strings for one user?
You can't really do this. Each user does not have their "own" copy of the web server. You have ONE web server, and ANY user can post back a single page, and the web server's job is to process that ONE page. That use then might close their laptop, or start browsing amazon to shop. The web server has no clue that user does not exist anymore.
All you have, and ALL your designs must then assume the web server can and will process a incomming page from any and all users.
Boatloads, but beyond boatloads of designs and assumptions will have to work on this concept, and that includes things like user sessions, session management, code management (static class values are actually SHARED among all connected usres!!! - (which is why you can use static class(s) but you can NOT use static classes with variables scoped to that class!!!
As noted, you can and its often for a web site to use and connect to several databases, but NOT on per user bases - it will not work.
You can do this on a desktop, since EACH user has their own computer, own memory, and own software running on each desktop.
on a web server?
You have one computer, one system, and it has to serve "all" users, and things like connections etc. as a general rule are NOT to be "per user", but per "system".
A correctly normalized and correct database design will MORE then take care of each user needs like creating a new project, new tours or whatever.
I am working on a C# winform project and during several operations I save and retrieve data to and from my google cloud SQL database.
In order to implement this, I set up the SQL instance, allowed the public 0.0.0.0/0 IP (so I can use this app from different PCs) and created a database user with a strong password. In the connection string in my c# project I connect to the IP with the created database user + Password.
Now my question is, how save is this? For my project and the enduser it is essential, that the data is as save as it can be. The only safety I have now is basically my google account Password and the database user Password.
Would there currently be a way to bypass that and retrieve data without me noticing?
best regards
Steffen
This was fine "back in the days".
Now, it is good practice to have a front-end proxy that uses APIs to serve data to the application.
If you can build and application that will run in the Cloud, next to your database, it would be best. Have that application authenticate users of the Winform Application and send them the information they need through API calls.
Without this, and having your application access directly the database you will have 2 issues:
lower security
high latency (and this will probably be more problematic). Database requests don't really like latency.
On top of it, you could use that server-side app to cache data and do some consistency checks.
However, for DEV purposes, direct connection is acceptable. Just don't put production data there.
I am currently working on a web app that will only be used internally. Part of the application requires employee information that is currently stored in our Active Directory. I have a sql server database already set up that I was going to store the info in but I'm not sure if it's needed. I can query the AD anytime to get the info I need so is it necessary to store it a second time in sql server? Will there be any significant performance issues if I am running occasional queries against AD vs. sql server? It's probably simpler to store everything in my sql database but I wanted to get some other input/advice as I have never worked much with active directory. (Also, this is not a data/network heavy app - less than 25 people will be using it)
Honest disclosure - I also don't have substantial AD experience.
If you duplicate the information from AD into SQL server, then you face the problem of detecting when it changes and updating the SQL copy. Your SQL copy will, somehow, lag or differ from the authoritative information in AD and your application will become known as inaccurate. Caching and ensuring cache accuracy is a very hard problem. Why take it on if you don't need to.
For light usage, I think an AD domain would handle it fine. If I understand it correctly, the domain controllers are load balanced across several servers. It does this for authentication, but I'm not sure about queries.
A Directory is an entity built to be simply interogated using LDAP. The main objective of a Directory is to centralize users informations just in order to avoid duplication in multiple databases.
So the answer is SURE use your Directory and interrogate it using LDAP (via ADSI in your case).
You need to duplicate entries in a database if you begin to plan frequent updates on user datas.
I'm very new to .NET, C# and SQL Server.
I need to develop a socket application using C#. That application should insert, delete, update, etc the data in database with respect to some request.
I need to develop another windows service application using C# that sends the data in the database to the web application through http.
The both applications run in the same system. The database is SQL Server. Both the applications use the same database.
I am unsure if while one application is deleting or inserting data in the database, then is the other application still able to access the database at a same time.
Sql Server can handle multiple requests just fine. Each connected client gets a different spid.
However, it is up to your sql server code (batches or sprocs) to handle data conceurrency issues via isolation levels and transactions. So in order to control one user reading data while others are updating, deleting etc..., you need to use isolation levels and locks.
Isolation levels:
http://msdn.microsoft.com/en-us/library/aa213034(v=sql.80).aspx
Also: http://dbalink.wordpress.com/2008/05/27/isolation-levels-and-locks-in-sql-server-2005/
Good writeup on transactions:
https://web.archive.org/web/20210614153200/http://aspnet.4guysfromrolla.com/articles/072705-1.aspx
I think that the simple answer is yes - multiple applications/people can access a database at the same time.
You may want to read up on transactions within a database and concurrency:
http://en.wikipedia.org/wiki/Atomicity_(database_systems)
http://msdn.microsoft.com/en-us/library/cs6hb8k4(v=vs.80).aspx
It is possible to access the same sql server database by as many applications as you want. If you are afraid that one application can attempt to read the data being changed by another one at the same time, read about transactions and isolation. But in very short, if you make a small atomic change which requires one line of sql code only, you probably shouldn't care about this at the moment.
Greetings!
I'm needing to deploy a compact database with an application I am working on. The database acts as a cache for data the app has already seen, and that data will never change, so the cached values will never become outdated. I've chosen SQLite, and I'm writing in C#.
I'd like to protect the database files so they cannot be easily accessed or edited by the user - keeping access to my application only. Now, one option is to use password protection which is fine except that with tools like Reflector one could easily view a near original version of the source and check the passwords/how they are generated per file and replicate this.
Are there any suggestions on how to achieve this result or something close? Have people done something like this in the past?
Thanks!
Security by obscurity.
If your apps can decrypt it, then your user can do it too.
If you want to keep it secure, you'll have to keep it for yourself. Your best bet is to store the database on a server and make it available via a web service. Perform access control checks on your own server so that the application can only access the parts of the database it has to see.
I don't have a clearcut answer for you (obfuscate your code during release deployment, make the password obscenely long) as the golden rule stands: If they have physical access to the executable (substitute machine/car/door) they can get in if they want(and have skills).
All you can do is make things difficult for them.
This area is not my forte, but one thing I could suggest is to just think about what data you are actually sending and determine if there is any way that you can limit any of the more sensitive data from being transmitted to the client in the first place.
If your concern is over sending things like ID numbers account numbers to the client, then perhaps you could translate those values into a client-only version that is meaningless outside of your application. Your server could have a table that contains the translation between the real values and the client-only values.
Let's say you have this table stored in your server's database (not the client database!)
RealAccountNumber ClientOnlyAccountNumber
981723 ABC123
129847 BCD234
923857 CDE345
...
So the client only sees the account numbers in the ClientOnlyAccountNumber column, and when a client sends a request to the server for an action to be performed on account "ABC123", the server knows to translate that into account number 981723.