I have been doing much research into this and was wondering what the best approach is, imagine the scenario where you have a WPF application that is being distributed to many users, this application has to connect to a database server. Connecting to a database is not a problem its how secure the connection is as external users will have access to the application.
within the app.config file connection strings can be pointed to the server, however releasing the password and server IP address is not a good idea. from research, other people recommended encrypting the data, but sure this is still got a degree of vulnerability.
the next approach is to use WCF, this i have limited knowledge on and not sure if this approach is correct.
Am I safe in encrypting the connection strings or is there more to it than that, I just want to be extra careful when dealing with sensitive data.
A common way is to add a server layer between your wpf app and the database. It can be a REST api or other web services as you like. In terms of technologies you can choose, wcf is one. But wcf is not easy to get started with if you do not have experience of dealing with services. I suggest to try Asp.Net's Web Api project to quickly establish a Rest Service (http://www.asp.net/web-api/overview/data/using-web-api-with-entity-framework/part-1 ).
This server layer will protect your database information (connection string etc). Also, allowing your application directly querying the database will potentially prevent the database from evolving -- for example, the insert query may break on the client side when you add a constraint on a table. Having a server in between can solve this future headache as you can update the server side implementation and database simultaneously.
In case of data sensitive, I would like to prefer SOA architecture will most suitable to you. WCF will be good option but think about RestFulWCF or WebApi2.0 (popular for multi platform support).
Hope this will help :)
Related
I am seeking advice on making a TCP server which can store/receive the data from a friends list for a chat program. I don't have experience with databases, so I am attempting to write the information to a text file. For now I want to focus on storing username and password, but I am not completely sure how to do this. Another person on my team is creating the client, so I just need to have a server which can receive this information from the client and store it.
For providing an interface where the client can store his data use WCF or better WebApi.
How the storage is implemented server-side should be of no concern from the client.
If it's just about chat, complement it with SignalR
No need to think about the difficulties over writing a multi-threaded server implementation over sockets while you are not ready for it (as I register from your post) WCF and webapi makes the tcp details almost transparent so you only have to think about the functionality required.
For persisting the data on the server I would go for a light-weighted solution in a No-Sql database.
Easy solution to adapt to the changing requirements. Espec since it seems that there is no real design(-document) in place.
Later on you when the datamodel is more mature you can change to a SQL solution if the application (or management) requires it.
And take the modern standards about security into mind, like (for a starter) not storing password in clear text.
Hosting services commonly provide support for webapps (say ASP.net, Rails or Django) and a few databases (e.g. SQLServer, MySQL).
I prefer C# WinForms for most of my own apps (speed of graphics updates eg.), but I'd like to have a webbased DB behind it so I can access it from multiple locations.
Is there a reason that I couldn't use such a web-provider just for my databases, i.e. not serve a dynamic webpage but just answer my sql queries?
Existing posts that appear to answer similar questions exist, but I would like to obtain more clarity.
E.g. does the webserver provide additional security that is otherwise hard to obtain?
Does the 'correct' answer include the keyword WCF? Do I need the hosting service to support WCF explicitly?
There is no technical limitation in accomplishing what you are asking, but most of the hosting providers (shared hosting mainly) restrict access to their database to be within their internal network. If you can find a hosting provider who provides you the option to connect from external network you are good to go.
One thing you want to keep in mind when you are distributing your winforms client is that the connection string can be extracted by the end user if he is a smart enough person. It would be prudent to encrypt the connection string in the configuration file and also use encryption for the connection it is making to the database (SslMode=Required in the connection string).
When you are using WCF, it helps you to implement an additional layer of abstraction and protection. You can use your own membership to authenticate the user who can have access to the WCF services and not worry about connecting from the client to the database directly.
All being considered, going with a WCF or any other web service layer instead of directly connecting to the database from the client would be better approach.
My existing scenario is below:
I have an SQL server which resides in a main company office. The company has another branch which is 60 miles apart.
I have a WPF application installed in computers in the main office and the branch which connects to the SQL server in the main office for printing records etc.
I am specifying the connection parameters in the app.config file as below:
<add name="CompanyEntities" connectionString="metadata=res://*/LabModel.csdl|res://*/LabModel.ssdl|res://*/LabModel.msl;provider=System.Data.SqlClient;provider connection string="Data Source=publicIPaddress of remote SQL here;Initial Catalog=databasename;Persist Security Info=True;User ID=sa;Password=password;MultipleActiveResultSets=True"" providerName="System.Data.EntityClient" />
My problem is that the application in the branch hangs for ever at certain times. So my question is whether its the best practice to use WCF for connecting to the remote SQL server?
Which is the best way to go about it? Is there any links which best discribes this?
In your current scenario, WCF is useless to you. If you write a server side application, that manages the database connection, you can use WCF to send the data to your clients. However that requires your client side software adapted to the use of WCF also, but in that case your clients wouldn't access the database (you would change from a two-layer architecture to a three-layer architecture). It might solve your problems, and it might introduce some other problems.
The hanging problem you describe could be caused by many things. For example you can run out of database connections, get into a deadlock (altough that transaction would be terminated by the server normally), or just simply have a lock on data being edited, and the employee using it going for a break.
It is also possible, that the problem is not with the database connection, but something in the client side code. Since I have no details, I can not tell you anything more specific.
Picking on the wording you chose, I don't think you'll be "connecting to the remote SQL server" using WCF. However, you can certainly use WCF to host a service that provides your client (WPF app) with secure access to your data, though it will do so indirectly. This approach will be quite different from the approach you currently have: accessing the server directly from the WPF app.
Although I haven't used it myself, I believe one approach may be WCF Data Services. If you only need a few operations in your service (e.g. GetRecord) for printing you may also be able to just roll your own WCF service that just provides "Records" to your client app. Any introductory book or tutorial on WCF will probably get you on your way.
The above answers the questions you seemed to be asking. However, WCF doesn't solve connection issues for you: if you say "the application [...] hangs forever at certain times" you should investigate that no matter what. But that's a different question.
We are departing from our typical native application development and are developing some new web-based application services. We are using .Net and WCF and most likely hosting on IIS.
Our services will need to use a database to persist data. In all cases we intend to make the database server a different box than our host. Most of the resources we find seem to indicate storing the database connection string in the web.config (or app.config file for self-hosting). Our concern is that since the service is web-facing the box it is running on is a more likely to be hacked/compromised. If that happens, the attacker now had the DB connection string and will have full access to all of the data.
An initial thought was to make the WCF service simply proxy to a server application that lives on another machine that holds the connection information and does all the processing logic. That way, if the the web-host is compromised they would have to figure out how to communicate with our server application, or compromise that machine as well, to gain database access. Though we do have concerns of the performance costs of proxying and possibly having a bottle-neck at the server application.
The concern with that approach is that we are not finding much in the way of WCF/IIS literature that recommending on such an approach, but we might just not know what it is called in order to find such information. The question: is proxying like that a good practice and why/(why not) (or where might I find more information on this topic), or is there a better practice?
As with these things, it all depends on how secure you need things. You can encrypt your web.config:
http://msdn.microsoft.com/en-us/library/dtkwfdky.aspx
But you have to ask that if your attacker has the ability to compromise your web host machine, they will be able to find your other server, and may also then have the ability to compromise that - not 100% sure what the net gain here is (apart from making your life more difficult).
I have a task to create a desktop version of our web app that will be distributed to our customers. I decided to go with wpf. The web app is three tier app with dal, bbl and pl. I could reuse a lot of it in my wpf but question is: is it a good idea to allow remote connections directly to sql server (i could compile connection string directly into the app). Or should i go wcf way and access db through a web service (this will require wrapping business metods around with service methods. Additional coding...)?
Any input is highly appreciated.
I would HIGHLY suggest using a WCF service. That way you are in control of what is running queries against your database, and it helps with keeping code updated. A great example why remote connections are bad :
Remote Access World
You use a stored procedure GetAnObject
In the process of upgrading your software, you change GetAnObject to return something different
Now all old versions are broken =(
WCF World
You use a stored procedure GetAnObject
In the process of upgrading, you change what it returns
In your WCF you just have to write some code to convert your object into the old one and send to legacy client. New clients are using a different WCF method call.
Also, I personally am not a fan of opening up my SQL server to any joe blow on a pc who can guess the login.
If you publish a version with an error in it, you at least have a chance the error is in the WCF side and therefore don't have to hassle clients with a 'my bad' upgrade. They never have to know where was a problem.
In a perfect world your WCF service and Web app can share a codebase, so you have less to maintain.
My suggestion is to go via a service (WCF or any other). The extra layer of indirection is decoupling which helps a great deal in maintenance and scalability. For example, if you already had a service which your web application used, it would have been much easier for you to just focus on creating WPF UI.
It all depends on what you want. Are you planning to use the DB layer and business layer across applications? If your answer is yes maybe WCF is the way to go.
We have a bunch of apps where we connect to the DB from WPF app directly because we wanted to avoid the extra layer of indirection which WCF adds.