I need some help for a noob programmer. I have an application I built > assetcat.app
I am venturing into the depths of networking and looking to rebuild the app using a host / client system.
I have been building the foundation for this with WCF. But it has been a struggle with roadblocks at every breakthrough, I expected to get simple host/client environment with authentication setup no problems. But I have had issues with the network access on different IP's, certificate issues, and even just finding information on MSDN that shows example that doesn't use the app.config. As I need to do most stuff dynamically for portability.
I'm sure if I continue with WCF I will succeed but I'm starting to wonder if there is something more simple. It seams WCF is more suitable to some kind of in-house development were the company of the app also runs the server.
What I want to be able to achieve:
-User installs and manages their own instance of the server software.
-They create accounts witch anyone who downloads the client can point to.
So Bob wants to make a game and is working in a team, Bob installs the server app and sets up some user logins. Bobs team mates install the client app, set the pointer to the IP of his server app, and login. Everyone in his team enjoys access to content managed by the server app.
In this situation, should I continue with WCF? My concern is also around certificates, from what I have gathered I can just chare a development certificate for everyone to use. Each person who installs the server software is also going to have to create or buy a certificate? That seems like a whole lot of mucking about that nobody is gonna do.
WCF has been around for a long time and before what APIs generally look like today. WCF like SOAP/WSDL allowed for strongly typed contracts and in general (before JSON was a thing) shared messages via XML documents. Many enterprises still have WCF services for integration points.
Today, the modern trend is to have less strongly typed contracts, and share messages via JSON payloads. Rather than SOAP/WSDL endpoints you have basic HTTP listeners that can accept requests (usually POSTs) and parse the JSON to business objects. Many folks prefer to create stateless and Restful (or Rest APIs) as this aids with scalability and fault tolerance.
WCF would seem like the wrong way to go for game development. Restful APIs can still use transport and message encryption, but be a lot lighter weight than WCF which adds a lot of overhead and complications (contracts etc) that you probably dont need.
In terms of encryption, you could add SSL/HTTPS using a Let's Encrypt certificates. These are free to obtain.
Related
I have been looking but cannot find a good answer that can help me in my case. To explain the situation, I am creating a Unity3D game which will have a multiplayer system. In order to keep the player data as secure as possible (so people doesn't cheat easily), I decided to implement a Web API 2 service that connects to a SQL Server database. I designed the Web service in such a way that only if the request contains specific data the request is processed. What I am now having problem is to design a solution that will let me send/retrieve data from the web service. I implemented SHA-512 to send the password so packet sniffers wouldn't get it in plain text, and I am planning to implement HTTPS but Unity classes makes it very hard. I thought of implementing RijdnaelManaged as a more secure algorithm for the accounts but in Unity the code is easily reverse-engineered.
Would this model be secure enough to stop script kiddies from hacking player accounts?
HTTPS
I implemented SHA-512 to send the password so packet sniffers wouldn't get it in plain text,
That's not helping for as far as your webservice goes, it now uses the hash as its password, so anybody sniffing it will still capture it.
Use https, not http to get it right.
If you really cannot: build a system where the service first issues a challenge, and where the client then "signs" that challenge and sends the signature back. That's still by far not as good as https, but it'll prevent a few things (but not e.g. a man-in-the-middle attack).
Security
If you look at analyzing the risks, you need to take care to address users of your game as well as 3rd parties.
The 3rd parties, with good passwords (good luck with that) or proper 2 factor authentication, https etc. you can cover the bases rather well. Add in some security in the webservices and you should be a good way along the path.
But you also have to deal with users of the game. And that's harder than it might seem as they could run your game in a debugger and figure out how the game communicates with the server and what it sends when, what the effects are of that etc. Nw if you have a multi-player game typically that involves virtual goods and/or currency that can be obtained and/or traded. Devious players will try to get it the easy way, so you need to protect somehow against that as well.
The easiest to do that is to move the game logic into the server and use the client only for visualizing things - but that obviously means you make much more use of server resources ...
Trusting your client is running, unmodified, and you're talking to it: you can't ...
I have this Windows Service that communicates with TCP/IP.
What I want to know is a method for a Windows Form Application to able to modify the setting of this service, such as remote host address and port to connect, timeout length, and log settings.
I have researched about NamedPipe, WCF Service, and IPC, but I can't decide what matches my scenario the best.
Will be nice to able to change the service settings by doing something like this from the client side.
[Service].SetTimeout(3000);
Any suggestions?
If you want that kind of programmatic control, then WCF is your best bet. With WCF, you get to define the API yourself, e.g., what methods to call, what messages to pass, etc. The WCF framework takes care of exchanging the data for you. And with the WCF config files, changing the back-end data exchange mechanism is trivial. For example, you could replace a NetNamedPipeBinding used for same-machine communication with a NetTcpBinding for cross-machine communication simply by modifying the config file(s). Full disclosure, though, if you haven't done WCF before, my experience was that the barrier to entry was pretty high. Of course, I took my lumps with Visual Studio 2008. It might be much easier in a more recent version. Here's an answer I gave a while back with some tutorials that helped me.
For me personally, I've replaced the early WCF implementation with a TCP-based version over localhost in the project I work on. The front-end application receives constant information from the Windows service when things are "running," and at the time of our decision, WCF streaming was not documented very well. We also saw evidence of problems, although that might simply be because we did it wrong. In any case, I'm very pleased with the solution we've come up with.
I can't speak to named pipes directly, but from what I've read, they're easy to use.
HTH.
I need multiple clients that talk to a WCF service. The WCF service also must be able to connect to any one of the clients also.
So - it sounds like the server and the clients need to have both a WCF server and client built into each one.
Is this correct or is there some way to do this?
I was looking at NetPeerTcpBinding, but that is obsolete. To be fair I'm not sure if that is a valid solution either.
Background:
I plan to have a Windows service installed on hundreds of machines in our network with a WCF service and a WCF client built in.
I will have one Windows service installed on a server with a WCF service and a client built in.
I will have a Windows Forms application
I will have a database
The clients on the network will connect to the service running on the server in order to insert some information on the database.
The user will use the Windows Forms application to connect to the Windows service on the server and this Windows service will connect to the relevant client on the factory floor (to allow remote browsing of files and folders).
Hence I believe the machines on the floor and the server both require a WCF cleint and service built in.
The reason people are recommending wsHttpDualBinding is because it is in itself a secure and interoperable binding that is designed for use with duplex service contracts that allows both services and clients to send and receive messages.
The type of communication mentioned 'duplex' has several variations. Half and Full are the simplest.
Half Duplex: Works like a walkie-talkie, one person may speak at any given time.
Full Duplex: Like a phone, any person may speak at any given time.
Each will introduce a benefit and a problem, they also provide ways to build this communication more effectively based upon your needs.
I'm slightly confused, but I'll attempt to clarify.
You have an assortment of approaches that may occur here, a Windows Communication Foundation (WCF) Service requires the following:
Address
Binding
Contract
Those are essentially the "ABC's" for WCF. The creation of those depicts a picture like this:
As you can see the Service will contain:
Host
Service
Client
The host houses the service which the client will consume so those service methods perform a desired task. An example representation:
As you see Client-1 is going through the Internet (HTTP, HTTPS, etc.) then will hit the Host, which will have the service perform those tasks.
Now Client-n is consuming the service locally, so it is talking over (TCP, etc.) as an example.
The easiest way to remember: One service can be consumed by however many clients require those methods to perform a task. You can create very complex models using a service-oriented architecture (SOA).
All WCF is, is a mean to connect your application to a host or
centralized location you may not have access to.
As you can see in the above image, the Client communicates through a Service to the Host. Which performs a series of task. WCF will talk over an array of protocols. Hopefully this will provide a better understanding of how WCF is structured.
There are a lot of tutorials and even post to get you started. Some excellent books such as "WCF Step by Step".
Essentially your looking for an asynchronous full duplex connection, or a synchronous full duplex service. As mentioned above, your task in essence is the point of a Service.
The question: How does this work best?
It will boil down to your design. There are limitations and structures that you will need to adhere to to truly optimize it for your goal.
Such obstacles may be:
Server Load
Communication Path
Security
Multiple Clients Altering UI / Same Data
Etc.
The list continues and continues. I'd really look up tutorials or a few books on WCF. Here are a few:
WCF Step by Step
WCF Multi-Tier Development
WCF Service Development
They will help you work with the service structure to adhere to your desired goal.
Remember the "ABCs" for the most success with WCF.
Use wsDualHttpBinding if you want your service communicate with your clients.
Read WS Dual HTTP.
You might want to try out creating a WCF service using netTcpBinding. It will work for your requirements. You can use the article How to: Use netTcpBinding with Windows Authentication and Transport Security in WCF Calling from Windows Forms as a start:
Also, there are many examples included within the WCF Samples package which you can use.
I have an existing asp.net c# application for which I'd like to implement a feature that allows users to post content via email. A user would send an email to a designated address and the system would parse the email and create database entries using the email subject, body and any attached images. My proposed approach is to create a windows service that pings a pop3/imap enabled email provider to retrieve incoming emails. The service would then parse the emails using an existing library I found here http://www.lesnikowski.com/mail/. The user would be matched according to the email address in the from field to the asp.net membership and then new records would be inserted from the contents of the email for that user. Initially the windows service would run on a separate EC2 instance that I'll set up for this purpose since the current host does not permit root access. But eventually I'll probably migrate the entire site to EC2.
Before I dive in I wanted to get some feedback from you all on my overall approach and architecture. More specifically:
Is what I described above the approach you would take?
Would you recommend implementing a web service to manage the interactions between the windows service and the database of the asp.net site? Or would you recommend hitting the database directly?
If I program the windows service to
ping the email provider every 30
seconds, will that be a problem?
Do you foresee any security issues with this approach I've outlined?
What about issues with reliability (needs to be a 24x7 service)?
Additional Background --- the asp.net website is an inventory system where each entry has a name, description and optional images. From the email the subject will become the name, the body will become the description and the images are the images. If you're familiar with the Posterous blogging platform you'll have an excellent reference point for what I am trying to accomplish.
Is what I described above the approach you would take?
It would be better if you could set up an Exchange server or sth similiar where you get notifications about new emails, so you don't have to ping every 30 minutes, but I never did it this way and cannot tell you if this is even possible.
The approach itself sounds plausible, because sending emails is really easy and everybody knows how to do that.
Would you recommend implementing a web service to manage the interactions
between the windows service and the
database of the asp.net site? Or would
you recommend hitting the database
directly?
I would recommend an extra abstraction layer, because it is not much effort and improves the design. This decreases performance (shouldn't be that much), so it depends on your requirements.
If I program the windows service to ping the email provider every 30
seconds, will that be a problem?
Depends on your email provider. Normally and if they allow it: No. You should definetly ask them first.
If it's your own: You're good to go.
There can be problems however if you're doing this inside a thread and you're accessing the IMAP multiple times at the same time. You should try to avoid that.
Do you foresee any security issues with this approach I've outlined?
Yes. You can easily forge the "from" field of an email you've send. There can be issues then, if the email is known. You should definetly add some kind of extra security like sending the mail to <SaltedHashThatIsDifferentForEachUser>#example.com. (Facebook does this too for example)
What about issues with reliability (needs to be a 24x7 service)?
I see more problems with the reliability of your email provider than with your service, because as long as the emails are saved, you can still parse them later.
You should investigate the maximum size of your imap to avoid rejected mails (e.g. delete them once you've successfully parsed them)
Would you recommend implementing a web service to manage the interactions between the windows service and the database of the asp.net site? Or would you recommend hitting the database directly?
There is no need to have a web service, it will just add complexity as well as introduce another attack target on your web server. Having your windows service hit your database directly will be simpler and more secure.
If I program the windows service to ping the email provider every 30 seconds, will that be a problem?
Should not be a problem ... Email providers provide POP3 and IMAP so that external services can use them (outlook, thunderbird, iphone) so they expect them to be constantly pinged.
Do you foresee any security issues with this approach I've outlined?
As Simon stated, emails can be easily forged, providing a security vulnerability. This link discusses a hacking incident on posterous and the trade off between ease of use and security. As a CISSP, I tend to lean toward security, especially when the vulnerability very easy to exploit.
The unique, "secret" email address is a better solution in terms of security. However, it takes a lot away from your goal of simplifying the update process. It also makes your solution more complex and costly since you will need to be able to support (and programmatically create) an unique address for every user.
What about issues with reliability (needs to be a 24x7 service)?
Most mainstream email providers have outstanding availability. In regards to the availability of this solution (without the preexisting factors such as your current hardware and hosting facility), you would want to ensure the windows service was well written and included some "fault tolerance". For example, the services i have written in the past handle a few select errors caused by external dependencies (database or email being unavailable) so that it does not crash but just waits until its back online. This provides better availability since the service is ready to go when the dependency is ok again, without someone required to manually restart the windows service.
Is what I described above the approach you would take?
Due to the security vulnerability exposed by relying on the sender of the email for authentication and authorization, I would not take this approach. If the main goal was to simplify and streamline the addition of new items from mobile platforms, I would probably create a "mobile friendly" web page to accomplish this.
I just returned from a web design conference in Seattle and it was heavily focused on "non-pc" platforms. After listing their very innovative ideas and best practices for designing for the mobile industry, I can see a web app being a great solution to achieving this goal.
I need to expose our repository which resides in our server machine to clients. The clients should be authenticated, and read write permissions are enabled. We are having doubts regarding which way to go with the implementation:
We already have client based COM layer so we can wrap it with some C# UI.
Server rest services, and then writing rest services based UI in C#/GWT/etc.
Implement WebDav protocol and get free client (windows, total commander, others)
What do you think is the best approach?
I don't know what kind of repository you are talking about, and what your clients need to do with it. But if it's plain reading and writing of files, I'd say WebDAV is the best way to go: It's supported widely across all platforms, has loads of free clients, can be set up on a Windows machine within minutes, supports SSL (I think) and is very easy to use.
If you need to do more fine-grained things like protocol changes, have you considered using source control software like Subversion, Git or Mercurial? They would give great possibilities, but the learning curve for your clients would be very steep. I wouldn't recommend this for a non-techie audience.
WebDAV or SFTP (SSH File Transfer Protocol) server would work. They offer similar functionality, with SFTP being more widespread.
I'm not sure what you have in the way of infrastructure, but I'd suggest putting the server in a DMZ so if anyone breaks in they can't do too much fdamage to the rest of your network.
How are you going to authenticate users? ASP.NET 2.0+ has some useful libraries that provide some excellent out-of-the-box capability fo managing users which integrates with FormsAuthentication; this will gove you options for identity and access management - assuming you write a asp.net front end.
What ever approach you take, I'd suggest PEN testing it - either yourselves or by a third party security specialist.