[154] in iswork
Databases Status
daemon@ATHENA.MIT.EDU (Kevin M. Cunningham)
Thu Nov 9 17:46:13 2000
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Message-Id: <v04020a00b630d14350a3@[18.152.1.50]>
Date: Thu, 9 Nov 2000 17:45:55 -0500
To: istrain-reg@mit.edu, fsstrain-reg@mit.edu, pctrain-reg@mit.edu,
pptrain-reg@mit.edu, plant-lp@mit.edu, ocstrain-reg@mit.edu,
is-stock@mit.edu, is-home@mit.edu, swrt@mit.edu, iswork@mit.edu,
support-tp@mit.edu
From: "Kevin M. Cunningham" <kcunning@MIT.EDU>
Cc: "Kevin M. Cunningham" <kcunning@mit.edu>, pconant@mit.edu, knyzio@mit.edu,
cavan@mit.edu, miki@mit.edu
Howdy,
Just some updates related to the Training/Pubs/Products/Stock Answer/ISWork
FileMaker databases:
1. The databases are now backed up in ADSM every work night (they used to
be backed up intermittently, about once every 4-5 days on average). They've
been backed up to ADSM for a while now; it was only this week that I
established a *nightly automatic* backup.
2. I have been investigating how to have a *secure, authenticated* web
front end to the databases. FileMaker's Web Companion (the built-in FMPro
cgi) doesn't provide either of these, but we really need to have such
capability if we're ever to move on to real data entry via the web (we need
to be sure a user is who s/he says s/he is, and that sensitive data is not
passed in the clear).
The short report is that certain trails I was looking into won't really
work as hoped, so I'm continuing down other trails.
That's it for now.
--Kevin
--------------
For the hardy, here are some technical details about item 2 above:
FileMaker 5 Unlimited comes with a java applet thingie called Web Server
Connector (WSC). Theoretically, a "real" web server (e.g., Apache) that can
do SSL and Certificates can run this WSC and handle the connections to
FileMaker. In other words, users would send requests to secure machine A,
which would handle the call to machine B which is running FileMaker -- the
user wouldn't interact with machine B directly.
There were several issues with this solution in our environment: FileMaker
doesn't say WSC can run on Suns; and, while a secure connection could be
established to machine A, the connection between machine A and machine B
would still be in the clear unless it was behind a firewall (which is
against our culture) or somehow else protected.
It looked for a while that WSC source code for Mac OS X (which *is*
available from FileMaker) could be compiled for the Sun and fitted into our
MIT Sun/Apache/SSL model. Alas, the code is written for Rhapsody (OS X's
UNIX), not easily converted to Sun UNIX. (Thanks Miki Lusztig for detailed
work on the code!)
As for the insecure connection between machine A and B, I naively thought
perhaps some kind of SSH tunnel (a secure connection) could be set up
between the machines, but this too was assessed to be too unreliable, if
even possible between a Sun machine and a Macintosh. (Thanks Jeff Schiller
for pointing this out.)
Two new trails I'm now exploring:
- It's possible that Mac OS X would allow us to run the Apache server with
WSC on the same machine (a Mac) running FileMaker. This would allow secure,
authenticated connections (I think IS intends to port our Apache to Macs;
if not, I'm not sure about the MIT Certificate part, but the SSL part would
be there regardless). It's not clear that Apache and FMPro Web Companion
can be running on the same machine and, if so, whether the performance
would be awful, but if they could it is probably possible to have Apache
talk to FMPro without having to send data onto the net. It's not even clear
whether this configuration would be a good idea in any case. Anyway, an
avenue of research.
- There is another scheme for authentication using time-stamped web cookies
with encrypted user information that may still give us a lot of what we
need to make our transactions properly authenticated. The actual data would
still be sent in the clear, but not the usernames and passwords. (This
would all take place behind the scenes, of course.)
I'll keep you informed as I explore these routes and if I implement any
changes to the databases to build on these possibilities.
Apart from authentication/security issues, I should say that I am also very
sensitive to the issue of Macs not being "enterprise-worthy servers" nor
FileMaker being "robust enough" for the work we do (etc. etc.) I don't
necessarily believe this is completely true, but as we continue to use our
databases and provide our services to the community, I will also be
exploring more supportable models for getting our work done (e.g., moving
to Oracle or MySQL, etc.) -- AS LONG AS WE CAN CONTINUE TO PROVIDE THE RICH
SERVICES WE PROVIDE NOW AND HOPE TO PROVIDE IN THE FUTURE. If switching to
Oracle involves programming resources we just don't have, or involves long
delays, or requires a diminution of real service, we'll stick with
FileMaker.
Any feedback on these issues is welcome.
