Previously I had sought help in the best method to determine if the application was being run in the same subnet/local lan where the ElevateDB server was running.  My client wanted to ensure that the application wasn't being used external to the "office" unless it was authorized.

My first solution was to write a simple TCP/IP service which ran on the same server as the EDBServer and which responded to a simple "ping" from the client application.  If the client application was running on the same local area network, the service would respond to the ping.  Obviously, if the client application was run outside the local area network, the client application would not get a response ping as the TCP/IP service would never receive the requesting ping.  This approach worked but it appeared to me to be "overkill" for a simple problem and required me to install/maintain another service on the server.

Recently, when adding new functions to my existing custom external module, I thought of an alternate approach to the local/remote issue.  I added a simple function to my module that returns the external IP.  I use TMS Software's Webdata component to retrieve the external IP from dyndns.  As in:

http://checkip.dyndns.org:8245/
    - returns:
     Current IP Address: AAA.BBB.CCC.DDD

Specifically my code is:
         if AppSettings.IsConnectedToInternet then
           begin
             WebData1.Data.Clear;
             With WebData1.Data.Add do
               begin
                 url := 'http://checkip.dyndns.org:8245/';
                 scanfirst := 'Current IP Address';
                 scanfrom := ': ';
                 scanto := '</body>';
               end;
             If WebData1.Execute then
               begin
                 // That should cause the Webdata to get the information
                 // the WebData1.data.items[x].data string values should contain the IP Address
                 AppSettings.ExternalIP := WebData1.Data.Items[0].Data;
               end;
           end;


With the ReturnIP() function created in the External module and registered in the configuration file, I can then check to see if the application is running locally or remote using something like:

 ShowMessage('External IP='+DMCTI.AppSettings.ExternalIP);
 // I have first determined the External IP address using the TMS WebData approach above and saved it in the
 // AppSettings class which I use for settings related to the application.

 DMEDB.PrepareQuery(DMEDB.EDBQueryX); {initializes the queries}
 with DMEDB.EDBQueryX do
 begin
   SQL.Text := 'SELECT UserID FROM Users WHERE '+
   DMEDB.EDBEngine.QuotedSQLStr(DMCTI.AppSettings.ExternalIP) +
    '= ExternalIP()' {using CTIModule Function ExternalIP};
   Open;
   if RecordCount > 0 then ShowMessage('Application running in the Local Lan')
   else ShowMessage('Application running external to the Local Lan');
   Close;
 end;

Obviously, you can use any table in your Database and any other valid technique for obtaining the external IP address but the concept appears to be valid.

Norman,

>Previously I had sought help in the best method to determine if the application was being run in the same subnet/local lan where the ElevateDB server was running.  My client wanted to ensure that the application wasn't being used external to the "office" unless it was authorized.<

I like your idea because it is dynamic, and the IP Addresses can be changed without restarting the EDB server.
I missed the start of this thread, so is there a reason why you can't use the "Server Authorized Addresses" (requires you to modify the EDBSrvr.ini file once)?

TIA
Barry

"Server Authorized Addresses"

"Specifies which IP addresses are authorized to access the
ElevateDB Server. This is commonly referred to as a "white
list". There is no limit to the number of addresses that can be
specified, and the IP address entries may contain the asterisk
(*) wildcard character to represent any portion of an
address."

Barry wrote:

Norman,

>snip
like your idea because it is dynamic, and the IP Addresses can be changed without restarting the EDB server.
I missed the start of this thread, so is there a reason why you can't use the "Server Authorized Addresses" (requires you to modify the EDBSrvr.ini file once)?
>

Barry:
The "Server Authorized Address" approach is an option however, maintenance becomes a major issue if you have numerous users "on the road" logging in from various wireless hot spots.  My approach permits the "authorized" users to access the application from any remote location with no special maintenance requirement.  The security object is the user not the IP address from which they access the application.