All systems are Windows 7, programming will be done in C#, targeting .NET 4.5.2.
The goal is to have a core program (I hesitate to refer to it as a service because I don't want to muddy the waters) that runs regardless of what user is logged in to the PC. The core program will run all the time. Users will log in (at least to the client program by authenticating against an internal system, if not the PC using Active Directory) and client programs will send and receive data to and from the core program. Since these PCs are in common areas of a secure facility, they currently auto-log-in as a generic user. This may or may not change, but the program requirements dictate that they will at least have to log into the client program.
What is the best solution for this scenario?
I had thought this would involve a Windows service and named pipes, but I haven't found a working solution yet. I have tried several WCF named pipe examples that work wonderfully if both the client and server are in the same user session, but have not found the key to getting them to work across user session boundaries. Now I'm wondering if I should take advantage of the fact that a generic user is logged in automatically and have the core program run as that user.
This is my first SO question, so Hello World!
[Edit]
The 'core' and 'client' programs will reside on the same PC, there is no need to communicate with the network. The core will retrieve data from a database and pass data on to a piece of industrial equipment. The core would also need to receive data from the industrial equipment and communicate that data to any clients that are listening, if any. It also logs that that data on the PC. The client program will display the data from the industrial equipment as a chart. I'm trying to be as clear as I can, but I don't know which pieces are important.
Related
I am planning in creating a student information system where multiple computers can access the same server through LAN connection. The server will have a database about the students information. I pretty much have a background in creating a program similar to this but i was only able to make it for 1 computer. I don't know how to connect that database to another computer. Like for instance:
Teacher A uses Computer 1 to access the Student Information System and
Teacher B uses Computer 2 to access it as well. Any modification done
by Teacher A will be updated to the database and it will be seen as
well for Teacher B.
And my other concern is whether I should make it web-based or not. I only have an experience with using WPF Application for this kind of system but someone told me that its easier if i used a web-based instead in this kind of networking idea. Can you tell me the advantages and disadvantages of using a web-based and its counterpart.
to summarize:
How can I connect multiple computers to access a single database system.
Which is better to use if its web-based application or desktop application.
Much appreciated.
Couple of points
Set up a machine for making it a server where your database will be residing. All the machines will be pointing to this server and database using LAN.
You can create both web based and desktop based application. I would prefer to go for web based application so that in future you can extend to access this system outside the college premises.
Both Web based and desktop based application can work for you in this case. For the database you can use SQlServer2008 and share this database over the LAN so that it can be accessed from all the computers in the network.
You must create one server machine for the database which will be accessed by other client machines on your LAN.
It is quite easy you just need to give the ipaddress of sql machine in connection string instead of "." And every thing else will be same .
You will have more than one solution to make the database be used in different locations.
1- Regarding the desktop application we can setup the application on a terminal server (considering the server configurations and how many users will access the server) and the user will access the sever through the terminal service (the application will access only one database for all users in different locations.
2- The desktop application can be run in a several locations accessing a database at the same location, By using the (Database Replication) we will have an updated data in all location.
3- The application that the users access over the internet is called a (web application), it is a software that is accessed through a web browser running on client’s machine called a web application, the application will access only one database for all users.
4- Adding a (web service) to the desktop application will allows different machines to interact with each other through a network.
The question is which is the best solution?
Option (1) is the easiest one because we don't need changing anything in the application but if the internet connection is disabled no one can access the application and if a bad internet connection then we will facing many complaints from the users.
Option(2) is good because we don't need changing anything in the application as well the database server will replicate the information with each other and update the information for all locations.
I prefer option(4) when designing a new application.
I prefer option(2) when the application is old and there is no ability to modify or it will take a lot of time to modify.
Our company uses a system of which I am the sole developer. It is a C# based desktop application that is run on some 50 workstations or so and all connect to one central SQL Server database.
Our network administrator is now looking at presenting the application through Terminal Services, something that I know nothing about, yet.
As I started Googling around I saw that, apparently, some applications do not work under Terminal Services. MS Paint is mentioned as an example. So this got me wondering, what does a developer need to know to make sure that his/her application works in Terminal Services?
I don't have the time right now to investigate TS in depth but I'm hoping there might be an article somewhere that is written for developers. As in "Things not to do when you develop an application that will be run in Terminal Services".
Terminal Service RemoteApp works pretty well if you application is designed to be multi-user compatible. so you will need to ensure user session related data is not shared, but placed in isolated storage with IsolatedStorageContainment set to DomainIsolationByUser for example.
here are some useful links:
http://www.fmsinc.com/microsoftaccess/terminal-services/remoteapp.htm
https://www.youtube.com/watch?v=Nf20-76dMcg
https://msdn.microsoft.com/en-us/library/3ak841sy%28v=vs.110%29.aspx
I have to work with 3rd party tool that connected on different DBs/Servers to collect some data and do some work. It is not important what this app do just note that it connects to Server1\DB1 and Server2\DB2 on Domain1. Both servers use ONLY Windows Authentication (i.e. client have to connected with IntegratedSecurity=true). This approach works pretty well in Domain1. But one day we decided to move this app working on another domain (business reasons). We created mirror of Server1\DB1 on another domain (let call it Server1IOtherDomain\DB1). Currently this app can work with Server1OtherDomain\DB1 because I run it as user of new domain and it seems everything OK. We just need support fresh version of DB on our environment. However few days ago we have recognized that connection string to Server2\DB2 is hardcoded and we can't do the same with Server2\DB2 (to create mirror on our OtherDomain). Obviously, some part of functionality is not working just because it can't reach Server2\DB2 in Domain1.
To summarize I have picture:
My 2 questions:
Is it possible to run somehow application in OtherDomain to have it connected to both DBs in different domains ?
Is it possible to make C# program that can be connected for various servers in different domains? For example using different Windows Authentication to different hosts, how to manage such cases?
To answer your second question:
It is possible to have a C# program that can be used across different domains, have a look at this answer for a simple C# implementation, this Q/A for more details about cross domain authentication and this question for a bit more specific issue related to SQL Server and cross domain authentication.
There are steps that you will need to take to make both domains trusted by each other to allow for a connection from the one to the other, this however also opens both domains to more security concerns and such decisions need to be evaluated and made by the network administrators.
I would also recommend that you have a look WindowsIdentity.Impersonate and WindowsImpersonationContext for examples and additional information as to how to specifically implement impersonation.
This isn't exactly a code question as much as it is an advice question. I currently working on a program for a small business. This program does a multitude of things from updating their local access database, edits and updates Word and Excel docs, etc. Now I have the WPF/C# based program running on a Windows 8 computer but they would like to be able to run it from multiple computers. My first instinct was to make the project again as a WPF Browser application. My questions is how would one set something like that up? Would I have to dedicate a computer with special software to handle just this program, the database, and their documents? Any Suggestions or tips would be greatly appreciated.
It doesn't have to be a WPF Browser App to run on multiple PCs. I suggest using Click Once deployment, where all users automatically get the latest version from a shared folder on an office server or just one of the other PCs in the office.
If they want all of these instances of your application to connect to a common data source or sources, then you will need one computer that hosts the server application and its database (you'll now have 2 projects: the server application, which might run as a Windows Service and have no UI, and the client application, which is the WPF app).
This computer be an existing Windows server in the office or it can even be just one of the PCs in the office, but that PC must be kept on for others to use the app and if anyone reboots it in the middle of the day others could lose some of the data they were updating.
Fundamentally, you need to alter the WPF application so that it fetches and sends its data from/to the "server," most likely using WCF services.
It is a lot to digest, but in incremental steps you can get there. The biggest hurdle will be getting your first successful WCF communication between server and client. Once you cross that threshold you'll be well on your way!
The basic question
How do I know that it is my publicly accessible (client) application that is sending my service messages? How do I know that it is just not some other application that is impersonating my application?
Some Background
Currently we log all errors that occur on our websites via log4net and WCF to a database. This works well because the web server (accessible from the web - Partly Trusted) reports there errors to the WCF service running on the application server (inaccessible from the web - Trusted) via a trusted relationship. We therefore know that all error logs are real and we need to investigate them.
With our new sites we plan to make use of SilverLight to liven things up a little. The problem we are faced with is how to report errors back from the SilverLight application running on the web consumer's PC (Untrusted) to our application server (inaccessible from the web - Trusted).
We can solve the inaccessibility problem of the application server by making the client communicate via a service facade on the web server, so that is no worry. The problem occurs when we need to be sure that the application sending the messages really is our application and not just an impersonator.
Some Thoughts
The code will be written in C# and be running in a SilverLight application that runs locally on the client PC, so we cannot be guaranteed that it will not be decompiled and used to send fake messages to our service.
The above means that we cannot make use of conventional symmetric encryption because we can't store our private key in the application (it can be decompiled). Similarly we can't use asymmetric encryption since it could just be impersonated (the attacker could just sign messages with the stored public key and send them - the messages would look real)
In the case of this application there is no user authentication, so we cannot use that to provide us with trust.
Yes, I know this is rather bizzare with the error logs being better protected than the data the application displays, but it is the case :)
Any thoughts or help would be greatly appreciated!
Impossible.
You can authenticate users, but not the application.
Let's say you decide to digitally sign the application. This signature is then read at runtime by your client application checking its own executable binaries against this signature. There is nothing that prevents the adversary from simply removing this check from your application.
Even if you make it close to impossible to reverse engineer your application, the adversary could always look at the communication channel and write an imposter that looks indistinguishable from your client to your server.
The only thing you can do is validate the actions on the server against a user identity.
Presumably, your server is creating the web page that the Silverlight application sits in. You could create a short-lived temporary "key" that only that web page contains. When the Silverlight app starts up, it reads this key and uses it. Because the server itself has a constantly changing, very short list of allowed keys, you can be more sure that only your app is accessing your services.
The best advice for you in this matter is to hire a security expert to help you. This is not a unique or unusual problem -- consider any game (like WoW for example) that is attempting to determine if it is speaking to a true client or a fraudulent client. Even with a massive amount of effort (look up Blizzard Warden, I'm not going to link it here), they still have issues. The problem boils down to exactly how much time and effort your attacker is going to invest in thwarting your attempts to make thing hard on him. Just be sure to validate everything on the server-side. :)