I have recently built an inventory system for a c# portfolio project and I have all the main functionality of the program down, the database is built and all the passwords are hashed and somewhat secure etc, but I wanted to something a bit more technical as i think it would be good on my portfolio. I was informed that a good way to secure my database would be to build a web service layer that I would call instead of directly calling to the database and also not having my connection string saved in a variable in the program itself, but im not sure where to start with building the web service as I have never done anything before and I wanted to ask if anyone could point me in the right direction if they arent busy, I would really appreciate the help.
Related
Alright so this is about a game, but more generally this can probably be done for all games, I just want to figure out how the application accomplishes it.
So it's for a game called League of Legends, huge game, has an executable file and a massive LoLClient where you can view all data specific to your account, you can queue for games etc.
Now what this app does (that I've came across) is it logs into the league client, grabs all info related to the character and logs out) but it does this without even displaying the client on the users screen, how is this possible? bare in mind it isn't using a server.
A broad question perhaps, but I'm sure there's a straightforward question (app developed in C#)
Riot has a Json API for devs to use and poll their servers for information they need to create websites and applications. It's not even touching the client; if it is, the dev of the app is either a little slow or scraping more than just 'champion information'.
In general if an application from an untrusted source is asking for login credentials, do some research and figure out why - after that use your best judgement. With that said, in most cases, if it is asking for such things and you didn't create any to use with that application itself, it's probably not a good idea.
If it is asking for authentication from a known good source (twitter, fb, google apis for eg) then make sure you check which permissions it's asking for before authorizing it to use your account. In some cases, it's just as good as giving them your username and password - the only difference being generally you can remove the authentication if weird behaviour starts up.
Riots API
I'm about to release a small tool which uses a database connection for storing data. The question is: How can I prevent people reverse engineering my code and getting the Username and Password to gain access to the database?
For earlier projects (which were used only by myself), I defined the connection-string just as a global variable inside my app. But that's highly unsafe as it only takes minutes to get this string out of the exe.
Also a lot of methods to obfuscate code can be reversed.
I am really a big fan of providing code but I don't know what to post. This is more a question about the theory. Coding is the part I'll take care of myself.
Here is a small idea from me which I don't really like that much:
I could place a second tool on the server. The real app would connect to this second tool, give over the data and the second data would finally connect to my database itself. This way the connection-string would be stored inside the second app where nobody can grab it.
The fact of the matter is that storing sensitive information on the client machine is highly vulnerable to attacks against your database. A suggestion you can look into is a Three-tier architecture model for your application (http://en.wikipedia.org/wiki/Multitier_architecture#Three-tier_architecture). In a Three-tier architecture, you have your presentation layer (your application), your logic tier (this layer will be the central pit stop for all your clients will have access to your database), and you have your database layer (the server where your database is). With this architecture, you can ensure all the data being stored and being retrieved from is from a singular source and high level security.
In the past (and still in the present), programmers would have to create their own socket servers or do advance network programming to develop a solution like this, however Microsoft has developed a tool called Windows Communication Foundation (WCF) which takes away the pain of coding your own socket server and lets you focus on developing your own implementation. Be warned though, WCF is secure by default, but it is no excuse not to research into ways of making your product robust against hackers (like knowing what protocol you are going to use, what security measures you are going to use (Transport vs Message, etc), encrypting data on client side so potential viruses don't uncover sensitive informations, etc). In saying that, WCF is a highly polished service and is really easy to get something up and running.
A good beginner video tutorial on WCF can be found here: https://www.youtube.com/playlist?list=PLhq7kqloVlM-bI9W_7iDZhObAeyrFt1y_
EDIT: The playlist for the videos are gone, but the videos themselves are still there. Just search through all his videos looking for the keyword 'WCF'
Here's the link: https://www.youtube.com/user/JesseDietrichson/featured
Please forgive the newbie question. I've spent the last three hours researching this, and I can't quite find the right answer, or perhaps I just don't believe it's as simple as it looks.
I need to deploy an application such that an application on the server-side does the heavy lifting, database wise, and the client-side version is fairly lightweight.
I have built a Data Access Layer class library (or at least a dll) that does all the heavy lifting. I have built a Windows Forms application that could serve as the lightweight client. They see each other. They talk to each other. They work happily together.
I'm kind of hoping all I need to do is put the dll on the server, point the reference to it in the client, and all will be well. The dll will run its code on the server, using server resources, and the client will run on the client. It's what the various websites seem to suggest, but it looks too simple.
Do I need to configure something like remoting on the server? Do I need to use System.Runtime.Remoting for something? Or is it really as simple as it looks?
Again, please forgive so basic a question.
what you are trying to do is build Client/Server application,
where you have
Client
client domainDomain
server Domain
Dal
Data
you will need to enstablish http conntection between client domain and server domain .
the common way to do this is using WCF
Explain the different tiers of 2 tier & 3 tier architecture?
http://www.codeproject.com/Tips/642296/Hello-World-Basic-Server-Client-Example-of-WCF
http://www.codeproject.com/Articles/14493/WCF-Basic-Client-Server
oh and welcome to stack overflow!
Well, you could use System.Runtime.Remoting, but that is a deprecated technology, i suggest using WCF for communicating between the client and the server.
I created a Windows Form executable in .NET 3.5 that uses a dll to communicate with a machine that scans checks. I'm eventually going to need to move from an executable to a Web Form that can do the same thing. This will be months from now, but I wanted to start doing the research now as I have not done this before. I'm going to need to use ActiveX in order to communicate with the device via a Web Form. I've also not done this before.
I'd like to keep the functionality of my existing executable without having to rewrite most of it, although I do understand that some of it will need to be rewritten. I've done research on ActiveX and how to use it, but I wanted to know if someone has had a similar situation as this. What did you do to convert an exe to a web program? Are there good, specific sources out there that I'm overlooking that can point me in the right direction for this situation? Is there any advice that you can give from your experiences that can help me to reduce mistakes? The company that I work for does not have anyone else here that has done this before, so I've got to teach myself everything needed to do this.
Thanks in advance.
This is where separation of concerns and n-tier design shine through. Hopefully your UI layer is loosely coupled from your domain model. If this is the case, you can code a second IU layer for the web. And not have to change your domain model at all. Then you can compile for each scenario.
*note - In practical use I have always had to extend my business domain to account for some issues with the second UI, but those modifications have usually been minor, and have pointed out places where I had coupled too tightly anyway.
Another option you may consider is creating a web services layer over your business domain code. And then coding a web application that communicates with your domain model via those web services calls. This may have performance implications, and would not be my preferred method of accomplishing this. Though you may find it more manageable if you don't have a well designed application to start with.
"I'd like to keep the functionality of my existing executable without having to rewrite most of it"
In general if you extract as much logic as possible into its own assembly/dll, you can reuse that from whatever UI framework you want. Just make sure you're not doing anything UI specific in there (throwing up dialog boxes, etc).
Normally, converting winforms to webforms is quite possible, although typically a slow development process. Even if you've got the cleanest domain layer in the world, the fact that objects in your web page are thrown away every time means that a web domain layer is normally written very differently to a desktop domain layer.
However, in your case the device - server communication is going to be extra difficult.
Have you looked at xbap? It's basically a way to deploy WPF applications into a web page. It requires your clients to have the right version of .NET installed, but it's going to be the easiest path for you, especially considering that you can host winforms in WPF...
You may take a look at Silverlight 4,
http://silverlight.net/getstarted/silverlight-4-beta/
It contains many features that ASP.NET Web Forms hasn't.
If your team can accept something like ActiveX, why not Silverlight 4? The only disadvantage is that SL4 is still in Beta.
I've been asked to research approaches to deal with an app we're supposed to be building. This app, hypothetically a Windows form written in C#, will issue commands directly to the server if it's connected, but if the app is offline, the state must be maintained as if it was connected and then sync up and issue data changes/commands to the server once it is connected.
I'm not sure where to start looking. This is something akin to Google Gears, but I don't think I have that option if we go a Winform route (which looks likely, given that there are other functions the application needs that a web app couldn't perform). Is the Microsoft Sync framework a viable option? Does Silverlight do anything like this? Any other options? I've Googled around a bit but would like the community input on what's best given the scenario.
The Microsoft Sync Framework definitely supports the scenario you describe, although I would say that it's fairly complicated to get it working.
One thing to understand about the Sync Framework is that it's really two quite distinct frameworks shipping in the same package:
Sync Framework
ADO.NET Sync services v. 2
The ADO.NET Sync services are by far the easiest to set up, but they are constrained to synchronizing two relational data stores (although you can set up a web service as a remote facade between the two).
The core Sync Framework has no such limitations, but is far more complex to implement. When I used it about six months ago, I found that the best source to learn from was the SDK, and particularly the File/Folder sync sample code.
As far as I could tell, there was little to no sharing of code and types between the two 'frameworks', so you will have to pick one or the other.
In either case, there are no constraints on how you host the sync code, so Windows Forms is just one option among many.
If I understand correctly, this doesn't sound like an actual data synchronization issue to me where you want to keep two databases in sync. it sounds more like you want a reliable mechanism for a client to call functions on a server in an environment where the connection is unstable, and if the connection is not present at the time, you want the function called as soon as the connection is back up.
If my understanding is right, this is one option. if not, this will probably not be helpful.
This is a very short answer to an in-depth problem, but we had a similar situation and this is how we handled it.
We have a client application that needs to monitor some data on a PC in a store. When certain events happen, this client application needs to update our server in the corporate offices, preferably Real-Time. However, the connection is not 100% reliable, so we needed a similar mechanism.
We solved this by trying to write to the server via a web service. If there is an error calling the web service, the command is serialized as an XML file in a folder named "waiting to upload".
We have a routine running in our client app on a timer set for every n minutes. When the timer elapses, it checks for XML files in this folder. If found, it attempts to call the web service using the information saved in the file, and so on until it is successful. Upon a successful call, the XML file is deleted.
It sounds hack-ish, but it was simple to code and has worked flawlessly for five years now. It's actually been our most trouble-free application all-around and we've implemented the pattern elsewhere successfully