Best client server setup?

Community Forums/General Help/Best client server setup?

col(Posted 2016) [#1]
Hiya,

My scenario is that I'm using server 2012 and I want clients to upload uniquely named folders and files to the server. The files will be uploaded to the server securely with encryption. I will need server side code ( dll/exe? ) that will accept the incoming folders/files so that I can log/index them into a database for quick, search based, retrieval at later times.

I don't want to start re-inventing the wheel writing tons of code for the server side programs if something already exists, or if I shouldn't really be writing .exes to begin with. Should I use IIS with a web-based approach to uploading the files? is it bad practice to have an exe running on the server listening to a port for communication?

I guess I'm asking what would the best approaches and directions that I should head towards to starting achieving this goal?

This kind of server work is all new to me and I find it quite exciting learning and venturing into new grounds.

Thanks!


RustyKristi(Posted 2016) [#2]
why not use PHP server for windows and your app is in browser gadget or at least part of it? Have them upload zip files with those unique folder/files, you can do encryption but I think that won't be necessary if you get SSL certificate for your site.

Encode some user agent magic id on your client when doing http upload/request so you can filter out direct browser access like chrome etc.


col(Posted 2016) [#3]
Hey RustyKristi,

Thanks for your input,

The client in this setup won't have control over the upload process, say via a webpage/control, it will happen in the background. What happens is the client will use a closed application on their side. This application creates the new files and folders which I can guarantee are unique. Then the client side software, as opposed to the user, should upload the folders/files that it created to the server. At a later time another client would want to search through all the uploaded files so I was going to use a database for a quick lookup. That search utility could easily have a browser front end interface. So I would write the server side code to handle the 'file copy', and also log the folder location where the server puts the folders/files into a database.

Knowing this, would that change your opinion of what kind of client-server communication would be best to use?


Derron(Posted 2016) [#4]
You cannot guarantee what isbsend to your server...as communication could get sniffed and emulated/modified.

Upload filea...store them with a user/time/...-hash together with the "original name". use this information on searches.

this should avoid name clashes.


beside that: no clue what to use of windows binaries to achieve such things... writing it in perl/php/ruby/python/java is surely not the hardest thing... if you know your language.


Bye
Ron


RustyKristi(Posted 2016) [#5]

You cannot guarantee what isbsend to your server...as communication could get sniffed and emulated/modified.


SSL is standard security technology, mostly used on top IT companies and WWW of course, that's why it's called the standard. I don't think you can get any more secure than that, unless there are inside jobs or leaked information in play.

https://www.digicert.com/ssl-cryptography.htm

@col

PHP is a language, as Derron said you use what you are most familiar with but since most websites today are powered by PHP and it is easy to use (close to C++). You can use PHP as CGI or as CLI application, pick your flavor.

That sounds more like p2p, you may just want to look for libraries that supports p2p with upload resume process cause I'm sure if your client application is closed down you need to resume that like p2p or torrent clients.

Here's one project using PHP

http://mute-net.sourceforge.net/

I know it's p2p but I'm sure you can code your way for it to be centralized using permissions. I'm also not saying I recommend this specifically but just a reference so you can get some idea to get started or what to look for.


col(Posted 2016) [#6]
I know that I've kind of vague with the specifics of the app but I can divulge a little more 'loosely related' information.

@Derron
I already do use the date/time/hash approach with an added serial number too so name clashes are impossible and can be guaranteed NOT to happen - been using it for years now on this project. It's actually a part of the spec ;-)
As far as packet sniffers go, you may have missed my other post regarding server certificates?

@RustyKristi
I guess it sounds like p2p, but this is in a very controlled environment - the servers/clients are not connected to the net but are on a network and I want/need to cover all things in case it is compromised, no matter how unlikely. The uploads have to be complete or they don't exist, resuming and such things are not allowed - the files all have to be on the on the server or not - so any incomplete transfers will be deleted server side, and the client machine will attempt again at a different time. The important data is stored locally on the client machine until such time that it has managed to transfer it to the server. If that local storage is full then the client machine cannot be used. To be honest this makes the job a lot easier from both server and client code due to not having to worry about partial transfers.

The main part that was on my mind was whether its 'standard' practice to use a command line exe listening on the server or whether I *should* be using some kind of web-based approach - more modern fads?. I think you've cleared that part for me, so I can now progress full steam ahead knowing that I am heading in the right direction at least. Thankyou!

For a couple of years now this project was being used, as I said, in a very controlled environment, but using just local servers ( totally isolated and physical secured ) so I used standard network paths, but that's progressed on to more and more remote servers and of course the requirement for security during the transfer, even though the network is very secure from the outside in, I want to make sure that inside the network the transfers are also secure too, call it overkill but that's the kind of level I need to look to.

So although the system will seem to be the same from the users point of view, the mechanics that go on in the background have to step up a few gears to remain compliant.

Thanks for your help guys!

ps
no clue what to use of windows binaries to achieve such things

Windows has the CryptoAPI along with its NG version.


Brucey(Posted 2016) [#7]
You may not need "heavy lifting" tech such as apache/PHP. There are many more lightweight modern fads that can do that kind of work.

For example, you can set up a basic https webserver with node.js in just a few lines of code. For example : http://stackoverflow.com/a/14272874

I've recently been using vert.x at work to build REST/file/rendering services - some using basic auth, and another using OpenID Connect.


Derron(Posted 2016) [#8]
@ Package sniffing / emulation / SSL

You know about proxies ? and that you could eg. route all your android-device-traffic (including ssl) through some additional software (used that to check what a popular app of a drugstore here in Germany sends when checking in coupons).

I did not think of a man-in-the-middle-attack or so. Just think of one of your users wants not just to upload a file, but to override some other users content. So he tampers his own data to play with your servers ... he could also modify his client (if there is one).

So what I wanted to express: just do not believe _every_ incoming data. Name clashes are one of the easier things. It is similar to form-validation done with Javascript and not on the server-side.


Nonetheless, I assume you already are paying attention to that.


bye
Ron


col(Posted 2016) [#9]
@Brucey
Thanks, I will take a look.

@Derron
Yes, those kind of client type 'attacks' have been taken care of. On top of which the client device is a kind of 'kiosk' type of device with touchscreen user input, no mouse or keyboard and has very very limited actual client usage with practically zero user rights and privileges - just enough for it to do its job.

Anyway, thanks for the insight.