Users inside Firewall vs. Users Outside Firewall

Users inside Firewall vs. Users Outside Firewall

Old forum URL: forums.lhotka.net/forums/t/2434.aspx


DeanB posted on Monday, February 26, 2007

I have a situation where the business application I am writing is going to be used by people inside the network and by people outside the network.  How can I change modes on the dataportal for people inside so it doesn't use the remoting site or at least uses the inside IP address?  I am new to the forum so forgive me if this is "old hat". 

Thanks.

Dean

ajj3085 replied on Tuesday, February 27, 2007

You'll need to know if the user is currently inside or out of the firewall... I'm not sure what the best way to do that is, especially if some users have laptops and will be moving in and out of the domain..

You probably would also have to modify Csla a bit so that you can switch the dataportal to use on the fly.  I think right now its only read out of a configuration file.

JoeFallon1 replied on Tuesday, February 27, 2007

My guess is that the client will demand 2 applications. Not one.

One will be configured in the DMZ so outside users can hit and use the remoting DP.

The other will be on a different internal server for employee use. No remoting required.

(This is how I configured my app to run.)

Joe

 

RockfordLhotka replied on Tuesday, February 27, 2007

ajj3085:

You probably would also have to modify Csla a bit so that you can switch the dataportal to use on the fly.  I think right now its only read out of a configuration file.

You won't have to actually modify CSLA itself, just create a custom data portal proxy.

If you look at Chapter 4 you can see how the four existing proxy classes are created - and none of them are terribly hard. They implement an interface, create the connection to the server (or not) and delegate the call.

You aren't talking about changing the way the network transport works or anything like that, so you should be able to create a switchable proxy - probably that just delegates to LocalProxy or RemotingProxy (or whatever protocol you are using).

Remember, this is all interface based, so chaining these things is pretty easy.

So what you might do is create your SwitchableProxy like this:

public class SwitchableProxy : DataPortalClient.IDataPortalProxy
{
  private static bool _thruFirewall;

  private static void SetThruFirewall(bool thruFirewall)
  {
    _thurFirewall = thruFirewall;
  }

  public bool IsServerRemote
  {
    get { return _thurFirewall; }
  }

  public DataPortalResult Create(
    Type objectType, object criteria, DataPortalContext context)
  {
    if (_thurFirewall)
    {
      Csla.DataPortalClient.LocalProxy portal = new Csla.DataPortalClient.LocalProxy();
      return portal.Create(objectType, criteria, context);
    }
    else
    {
      Csla.DataPortalClient.RemotingProxy portal = new Csla.DataPortalClient.RemotingProxy();
      return portal.Create(objectType, criteria, context);
    }

    // implement Fetch/Update/Delete
  }

I'm sure you can optimize this and make it cleaner - but I'm trying to just illustrate the point. Your app code would need to detect whether you are inside or outside the firewall and call the SetThruFirewall() method so this object could route the call appropriately.

This class would be in your code - or it its own DLL. Again, no need to alter CSLA at all - I specifically designed the data portal to use a provider pattern for this sort of extensibility.

ajj3085 replied on Tuesday, February 27, 2007

Ya, that's a better solution... that's one thing I keep forgetting, that you can build your own DataPortalProxy..

DeanB replied on Tuesday, February 27, 2007

Thanks.  I will look at that and come back

AzStan replied on Tuesday, February 27, 2007

On method that Sort-of worked for us is to use DNS.  A public DNS entry points to your application server via your public IP address on your gateway.  Meanwhile your private network also has a DNS server that points that same name directly to the application server's private IP address.

I say 'Sort-of' worked, because when laptop computers move from public network to private network (or vise-versa), they don't immediatly function due to DNS caching. 

Copyright (c) Marimer LLC