getting data to the internet

[Fairlight]

With neither thought nor caution, Scott Ullmann blurted:
> I have a client that is looking to be able to supply his clients with
> real time (or close to) access to their data.  There are a couple
> different filepro data files involved - client master file, each clients
> data and a few others.
>
> My concern is mainly from a security standpoint.  He is in the middle
> of having a web site designed that he would like his clients to be
> able to log in to in order to access this data -- so he wants to setup
> individual usernames/passwords for clients to be able to get a 'snapshot'
> of activity and a few reports.
>
> With all the 'new' products available for filePro - what is the easiest
> way to get this accomplished?
>
> My thought was orginally to do a 'data dump' each night to his web host
> provider and upload this data into a MySQL table or something -- but
> I'm pretty sure there is an easier way to do this - without endangering
> security on his filePro server.
>
> Currently he is running filePro 64-user license on a SCO OpenServer
> 5.0.5system.
>
> Does anyone have a 'blueprint' for accomplishing this?  Thanks
>
> Scott Ullmann Newtown, PA

I can do way better than data dumps.  I can do integration in realtime in a
tunnelled fashion.

OneGate, by itself, is a CGI gateway.  If that were put on a SCO 5.0.5
system with perl 5.6 from SkunkWare, along with Apache from SkunkWare as
well, you get your realtime data directly from fP.  But...that's on a
totally different system than their main web host, so it's not locally
hosted fP.  

So...what you use is OneBridge, RawQuery, and OneGate all on the web host
itself as well.  In essence, the combined configuration of all three means
that you direct a request at OneGate on the web provider's host, it accepts
it, reformats it, and queries the fP box through a firewall rule that
-only- allows the IP#(s) of the web provider's machine(s) on the requisite
http(s) port.  The response is done in realtime, and is fed all the way
back to the client-end browser.  All the ISP end needs is perl with a few
modules, all of which are very common.

Nothing ever needs to be updated/synced/dumped, because it all happens in
realtime.  It's always live.  In beta testing a few years back, my machine
in the living room in Louisville, KY was effectively acting as a system up
in New York.  It was actually -so- transparent that when I was doing beta
testing I had to flag the version numbers of the two copies of OneGate so
that I could tell -which- end had the error.

Think of it like this:

fP_box <-> firewall <-> ISP web server(s) <-> user browser

What's really cool is that you can use the virtual firewall at the
application level independantly on both ends.  On the fP box, you can have
accounting tasks that are available only to the local intranet, but other
tasks meant to be public are allowed to be used by other sources.  That's
how it normally works in any event with just one copy.  But when you add in
the second copy, you can use it to pre-screen abusive hosts, etc., so if
you firewall something at the ISP host copy of OneGate, the request is
never actually forwarded on to the fP server, thus protecting its resources
as well as its bandwidth.  And...if you need a universal CGI gateway, the
ISP level OneGate can be used with other software, so you can also mix and
match locally derived data and remotely queried data.

Actually, -all- security functions are available at both ends, with the
exception of HTTP Basic Authentication, which is only available at the
server end.  The reason that wasn't supported at the far end of the tunnel
is because there's actually no way to reverse-engineer the auth info from
what httpd (any make/model) provides programs at the CGI level.  The
information necessary to recreate the appropriate header is not made
available in any form, and only REMOTE_USER is filled in once you've
actually logged in.  There's no actual way to get the password to broker
that particular level of security.  It can be used on the exterior, but you
can't pass that particular scheme onwards.  That limitation is definitely
not within anyone's capability to fix unless one hacks apache to pass on
the requisite information.  Then I could support it. :) But it'd be a bad
idea to do so from a security standpoint.  But everything else works the
whole way on both ends--even file uploads work fine.

At any rate, that's the route I'd go.  It was originally designed
specifically to protect a Windows-based fP host because of security
concerns in having both a Windows box and the fP data directly available
to anyone.  However, it's entirely OS agnostic.  You can talk unix<->unix,
windows<->unix, unix<->windows, or windows<->windows.  Doesn't matter.
I was actually testing using a "public" Windows box used to broker
information provided from a SCO fP box.  As long as all the systems meet
the requirements for the software and are properly configured, it's fine.

mark->
-- 
The latest synth mixdown...
http://media.fairlite.com/Isolation_Voiceless_Cry_Mix.mp3