Leveraging Dot Net Remoting To Keep Your “Secret Code” Safe

Leveraging Dot Net Remoting To Keep Your "Secret Code" Safe

One of the reasons to use Dot Net Remoting is for security reasons.

A way to implement this is to give your clients the assemblies which contain
~Interfaces, but the Concrete classes actually run on the Remoting Server.
You will supply the Interfaces for the clients to use and invoke, but you actually have the Concrete classes running on the Remoting Server.

Here is a quote from another web site:  (Thanks Leon for that post)
From:
http://secretgeek.net/QAD_Remoting.asp

You want your clients to be able to call some of your secret proprietary functionality but you don’t want to give them the modules that perform this functionality.

On the surface, it may appear I haven’t done anything outside of his example.
However, if you dig deep into the code, there is a subtle difference.
It involves how the object populates itself.  While its sounds trivial to create a "READONLY" object, any READONLY object must have
an entry point.  I’ve created the Solution(s) so that you can create a truly READONLY object, with only 1 entry point.  In my sample, it is
the startZip , endZip and weight values.  The example could easily be changed to 1 entry point containing userName and password, and you can develop an object with contains all the UserRoles, etc, which are available only as READONLY.  Like I said, you have to really dig into the code to see what I am talking about.

There are 2 methods of using Remoting.  You can post the Remoting Service on a tcp port, or you can piggyback off the IIS.
Each has its own advantages and disadvantages.  There are other methods, these are the 2 with which I have experience.

With IIS Hosting, you get all the built in features of IIS.  But you sacrafice some performance.  TCP is a little more manual,
in that you will probably have it running as a Windows Service, and you have to take into consideration the pitfalls of running a Windows Service.

The sample code works on this premise.  You want to ship an item.  The parameters are startZip, endZip, weightOfPackage.  You want to get the shipping costs for this package.
The formula for calculating the shipping costs is the "secret code".  You (as the parcel company) want to allow clients to determine shipping costs, but you do not want them (an honest client or a malicious competitor) to know or be able to disassemble your code to figure out what formula you use to calculate the shipping costs.  Thus you need a way for the client to invoke code on a Remoting Server.
An additional need is that you are superparanoid, and you don’t want anyone to be able to {set} the .TotalShippingCost property of your object manually (for whatever reason?).  Thus you need a way to expose the .TotalShippingCost property (with a {get}), but need a way to set the property (internally in the code) using the data collected from the Remoting Server.

Yes, I know what Web Services are, and perhaps that’s the best way to address ~this~ specific business problem.  The code is given as an example for Remoting, and the Shipping Costs Calculator was the generic example which came to mind.

There is an README_OVERALL.txt, and a README.txt for each project.  I’d check those out first, then step thru the code.
To get the real feel for Remoting, I’d suggest posting the Remoting Service on another machine, and then calling from you client application.
The setup in IIS for remoting is ~very simple, once you figure out the steps.  But you can deploy and IIS Remoting Service with as little as 2 files.  (Web.Config and \bin\MyAssembly.dll).  See the README.txt in IISRemotingSampleDeploy for more info.

Here is glimpse of the code used (on the client):

Key namespaces (for those who google)

using System;
using System.Collections;
using System.IO;
using System.Runtime.Remoting;
using System.Runtime.Remoting.Channels;
using System.Runtime.Remoting.Channels.Tcp;  // From System.Runtime.Remoting

 

 public  static IShippingCostsCalculatorLoader loaderILoaderRetrieve()
  {
   
   //Use this syntax for a TCP deployed Remoting Service
   //string sourceURL = "tcp://localhost:9932/ShippingCostsCalculatorTCPListener";

   //Use this syntax for a IIS deployed Remoting Service
   string sourceURL = "http://localhost/DotNetAssemblies/GranadaCoder/Applications/RemotingExample/IISRemotingSampleDeploy/MyFirstRem.rem";

   //notice that the Interface is used here, thus the code is running on the server
   IShippingCostsCalculatorLoader loader = (IShippingCostsCalculatorLoader)Activator.GetObject(
    typeof(IShippingCostsCalculatorLoader), sourceURL);

   return loader;

  }

 

Happy Trails.  I think the example code will at least get you started on the right path to better understanding of the Dot Net Remoting Framework.

 

(Right Click , and ‘Save Target As’ is probably the best approach)
Download the code HERE