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.
Related
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.
I am building a program for myself that will save my passwords. Now I have the following questions. Because I have a lot of computers (one for work, three for myself), I want to keep the passwords in sync with a server. But now my question is what is the safest way to send data over the internet with c#? Is it possible to make the connection so safe that I can send passwords over it? And maybe any suggestions for the app.
Yes, you can make it reasonably secure. First, I would recommend against writing your own protocol stack, simply because it is so incredibly easy to make a simple mistake that would make it trivial to hack the security.
( Obviously there are plenty of already existing services (like 1password, passpack, etc) but I assume you know that already. )
I would recommend that you focus on the syncing and UI and leave the security to alredy proven libraries. One such solution is to use SSH with RSA authentication and known host keys. This is in use on many production sites and AFAIK considered reasonably secure (though there was one hole in one of the most popular implementations, OpenSSH, some years ago that was pretty bad). The SSH protocol can be used as a carrier for all kinds of different protocol, including your own password-syncing protocol (for that you could just use SOAP or JSON-RPC or something similar that there are plenty of libraries for).
You can then integrate directly with C# by using a SSH client library (https://sshnet.codeplex.com was the first Google hit). I have no experience using C# directly to talk SSH, though. What I usually do is to let an existing SSH client (PuTTY, for example) open up a port forward and then use regular TCP sockets. It all depends on how slick you want the sync app, but since you are writing it for yourself only, I would go with the latter.
If you are clever writing your app, you don't need a server part except of your own (for example, SSH implements SFTP for file storage).
A similar idea is to use SSL. If you pre-trust the certificate chain, this can be made secure enough but my experience is that the default SSL socket API in C# is way too much tied into the Windows architecture, making things like custom certificate validation trickier. Using a publicly exposed server to your service (directly of via IIS) also opens up a lot of new attack vectors.
I am working on an media application for which I would like to provide an external API library that would allow another application to communicate with mine an query status information. My application is written in C# and the API DLL will be the same. Initially my thought was to simply use WCF and Named Pipes since it would provide an extremely easy way to code up the whole interface.
However, I realized that doing this would pretty much preclude any other languages or platforms from communicating with the application if I ever wanted to make, for example, an android or Web remote for it.
So, what protocol could I use that would allow a fast and simple interface from within my C# code, but also allow APIs to be written in other platforms.
Basic requirements are:
Local and Remote communication
Low overhead
Procedure Calls
File transfer (to send media)
Pre-Existing C#, open source library would be nice.
I've looked at a lot of the options, used XML-RPC and JSON-RPC before, but would like to know what the community thinks is the best option.
I think using WCF it's the best way to do what you want. It will be simple in maintenance, cover all your requirements and easy to extend. Just don't restrict the access to your API only by net.pipe. I think you should use net.pipe, net.tcp and maybe basic http as primary bindings. I mean several endpoints for each service. So, a client app, no matter what language it is written, will be able to choose what binding to use to access your API server.
For example:
C# client app on the same machine - use net.pipe
PHP client app in web - use basic http
Java client app on another machine - use net.tcp
As an example:
http://www.kevingao.net/wcf-java-interop/java-client-and-wcf-server.html
I am looking forward to make a sort of a chat application using C# and WCF, yet before I start I wanted to clear a few things, so that I don't get carried in the wrong direction. :)
the application should be able to both make event ( send messages ) and listen to events ( receive messages ), therefor if I understand it right, the application should be both the client and the server at once?
what binding should I use? If I understand right, basicHttp binding hard to configure and is used when a WCF app needs to connect to non-WCF app? While for connecting two WCF apps its better to use NetTcpBinding?
how would this applications find each other, considering that they are running on different machines? should there be a central server, to which the app would connect first, saying "I'm user123, my IP is that and that, I'm free for chat" and look for other user IP addresses there? Or is there some other ways for apps to find each other without the central server?
maybe you could direct me to some examples or tutorials on this topic? ( tried googling, no luck ).
Thanks! :)
If your peers (machine that can operate as a client & server) are going to be behind NATs/firewalls then you will have a very very tough time building a chat application using WCF. If the peers will all be on the same network WCF is workable.
To write a chat application from scratch using WCF you will be re-inventing the wheel. Why not employ an existing protocol that's been designed precisely for the purpose such as XMPP. There are XMPP libraries around for .Net. You will need a central server but if you use XMPP you could feasibly piggyback onto one of the many existing free servers.
You can use netPeerTcpBinding.
See also:
http://blogs.interknowlogy.com/2009/08/05/building-a-really-simple-wcf-p2p-application/
http://msdn.microsoft.com/en-us/library/bb690929(v=vs.90).aspx
http://www.codeproject.com/KB/WCF/Chat_application_using_WC.aspx
There is no right and wrong answer to your question - it all depends on what you require. You then can choose the best architecture for your needs, and then the best technology for that architecture.
There are two things to consider - how will users find people to chat to, and then once they have found someone - how do the applications connect to each other.
For users to find each other, you either need to connect to a central server, which will then show a list of all connected users, or users need to enter the IP address of the person they want to chat to. Note that some firewalls will block incoming connections in this second case, so this may not be feasible in some cases.
Next, once you have found the person you wish to chat to, you need to decide whether messages will route directly to the other user, or if you want to continue to go through a central server.
If you choose to go through a central server, then your application will be functioning as a client, and will therefore pass through firewalls without a problem. However if you connect directly to the other user, both copies of the application will be acting as a client and a server (P2P topology), and therefore firewalls may be an issue. Having said that, you could designate one of the applications to be a server, with the other acting as a client, in which case only the server side needs to worry about the firewall.
Without knowing exactly what you are trying to achieve, it is hard to recommend which architecture will work best for you.
Earlier today I came across Kaazing's WebSocket API for HTML5.
Looks fantastic, but as I am only now researching WebSocket possibilities for real-time financial updating, I would like to hear some recommendations, and pitfalls to avoid when planning out this architecture.
I'm looking at ASP.Net MVC, and possibly some WPF/Silverlight MVVM.
Are there other WebSocket API's that are better (and why), and some good examples?
Also, what kind of traffic can WebSockets handle? I mean, if we have over a million users on a system updating real-time, how do hardware requirements change because the software architecture implements WebSockets?
A late answer. Here is a WebSocket Server (framework) that is based on .NET and has support for modelbinding / controller and validations etc. in a way that reminds of MVC. It is very easy to get started using it. Just create a new MVC3 Project and type:
Install-Package XSockets
Using the Package Manager Console in Visual Studio
More info on http://xsockets.net
And yes, it supports RFC6455 and Hibi00 and has a fallback for "older" browsers.
I figured I'd come back at this, now that I have a solution ready for production. I took a look at a few vendors that basically charge a lot of money for something you can essentially build yourself. They all have good products, and if your time to market is critical, those prefab options may be the best in the short run.
After poking around with Node.JS with Socket.IO, I shifted my attention to SignalR - an asynchronous signaling library for .NET to help build real-time, multi-user interactive web applications, and used the hub implementation.
It manages all the heavy lifting and connection building with just a few lines of JavaScript, and automatically selects the appropriate transport protocol for the connection.
For a load-balanced environment, implementation of a caching server such as Redis is required.
Here's a C# implementation of a Web Socket client and server on CodeProject:
Web Socket Server
I think following links will help you..
The WebSockets prototype with Silverlight, HTML Bridges and JavaScript
Silverlight and WebSockets (Mike Taulty's blog)
https://github.com/Olivine-Labs/Alchemy-Websockets
Here's an open source websocket server and client library. C#/Javascript. Includes fallback to flash sockets for browsers that don't have websockets yet. Tested on most web browsers including mobile ones, works everywhere.
Realtime financials? I don't know how many connections you plan on handling but this one is also the most scalable solution available right now.
Although the number of browsers are quite limited for websockets, mobile browsers have support for that. But i would be considering the use of more cross browser friendly choices like PokeIn reverse ajax library