In regards to the project I was asking question about, the night
before last I had a chance to sit down and spend some more time with my
client, and we worked out what I think is the best solution all around. But
first I wanted to give you a little background on this contract and the much
larger application mine has to work with. As I work on my own and don't
have contacts locally with whom I can discuss things such as this, I welcome
all comments, ideas, or even war stories this may bring to mind.
This guy runs a business which catalogs and makes available for use
under a variety of contracts, images and video clips. A few years back I
wrote a catalog application for his local network that allows them to scan
in display copies with proof-marks so they couldn't be used directly, but
provided him with a way of quickly putting together presentation mock-ups of
the photo work done by himself as well as sub-contractors all over the
state. These "presentations" or sub-catalogs that he uses to sell
imagery are geared to the specific needs of his buyers, based both on his
experience with them and/or special requests for whatever they're looking
for at the moment. The catalogs can be sent as hard copy or as digital
media, and for certain clients he even makes then available via a secure
site on the net.
He now has a much more sophisticated catalog system which was put
together for him by a large firm in the Erie area, but he gave me the
contract to again write an app for his employees that allows them to access
the catalog images and use them in a variety of projects they put together
for him like magazine mock-ups, and other pre-sale presentations of all
kinds.
Security IS indeed a problem that must be considered, but luckily
the imagery can only be viewed thru my application, and it will only reside
on 6 machines, none of which are accessible from his main local network or
on-line sources. His main concern is that up to 6 different users can logon
to EACH of these machines, one at any time at each machine of course, and
when they are working with the main catalog or even a subset of it, they
often times must copy content into their own work directories where no other
user that has access to the same machine should also ever be allowed to
access. Each of them have the rights to access the catalog(s), but in order
to copy any content out and into their own directories, they must go thru a
check-out system that will be part of my application and which logs for who,
when, what, how long, and for what project the content was taken for. The
app logs all this information and will auto-delete any copies still left on
these user machines after the amount of time they were checked out for is
up. Naturally this will have to give the user warning and the ability to
update the checkout for a longer time, but it is needed to ensure the blobs
don't get filled up with data left over or forgotten about.
Now I don't know who sold him on the idea, but when he upgraded to
Vista, he did so with the impression its UAC made it impossible for any user
to access another's directories. Unfortunately they forgot to tell him that
this only works for users with restricted access rights in the first place,
and all of his users have full control privileges because it's required by
the Catalog software originally written for Win2000. This is just one of
the reasons I'm using an embedded dB to handle things at my end. All
abilities of my app are controlled by and run from the application that
calls scripts encrypted and stored in the dB. And even when images are
copied over from the main catalog, they cannot be copied to disk, but only
into each user's own set of dB files. And each file is encrypted using a
different password made up and given to each user by the boss. This way if
a user on a particular machine takes out an image to crop for a magazine ad,
the copy and all the work done is saved into the user's own dB file, and
even if another user finds a way to access the file itself, there's no way
for him or her to open the file up! Also, the scripts that are used have
all be written by one person and control the type of access required by the
operation being done. For example, if a page mock-up is being put together,
and the user needs the image only to act as a placeholder so that
typesetting can be done around it, a full copy will not be pulled out of the
catalog. Instead a shadow copy will be made and it used! The scripts each
user employs has to be run directly from a control table in their own dB
File as well. This way no one else can make changes to the scripts that
another uses. And all 3rd party graphics apps that they use for
manipulation and page setup are crippled so that files cannot even be saved
to disk unless they already reside on the disk.
If you wonder why so much attention would be given to creating this
kind of security for employees, I can tell you that some of the images they
lease for their catalog, made by guys like Duane Michaels and Helmut Newton,
cost this guy almost $5,000 a month! And my client's insurance and bonding
companies had to okay the specs as well as the finished apps involved! They
don't require high levels of encryption, but they do demand certain levels
of logging and in-house protection.
In any case I solved the problem that initiated this thread I
believe. It's handled on three separate levels. The first is in the blob
encryption that is applied to individual record items, the next is in the
encryption of the entire dB File on a page by page basis, and the last is
provided by each user having to have given them their own encrypted access
to their account, the application and the main catalog. The way around the
speed compromise that I didn't want to make will now be handled by using
in-memory tables that are loaded as the original file is decrypted. I had
to split things up a bit differently however because initial tests showed
that under average conditions, a user will have up to 400 mb loaded for one
original image, and again half that amount for B/W low-res copies that might
be used as placemats in presentation mockups. Add to that the script tables
which hold almost 600 mb of data, and color swatches and typesetting data
and it could add up to over 1500 mb! I've set the in-memory tables to only
be used for the actual images, because they take the longest to decrypt and
load, but I'm looking for a good, inexpensive tool that I can use to log
every command/action and the time they take made by a user from within my
application. I think by having such information on hand, I can better
"tune" things, especially the way I set my individual tables up. If anyone
knows a good product for doing this kind of thing, please let me know about
it.
Right now, all of this is still only on paper, except for a few
small pieces I've put together over the last 4 years that led to this
contract. And I know I'm only getting it because the guy is a good friend
of mine and I'm working for starvation wages plus expenses! <g> But I don't
mind because it's one of the most interesting projects I've yet to work on,
allowing me to learn a lot of new areas that I might otherwise never get the
opportunity to try my hand at. Also there's really nothing beyond my
technical understanding involved in this project. It's all really basic
stuff, being for the most part a logistics control exercise!
Anyway, I hope I didn't bore anyone. And I also hope others will
take the time to write about some of the more interesting things they get
involved with themselves as programmers.
from Robert Meek dba "Tangentals Design"
e-mail: [EMAIL PROTECTED]
Freelance Windows Programming for XP and Vista
Also proud to be a Moderator of the "Delphi-List" at elists.org
"Reality cannot be explained...only enjoyed or endured as your current
perspective allows!"
__________________________________________________
Delphi-Talk mailing list -> Delphi-Talk@elists.org
http://www.elists.org/mailman/listinfo/delphi-talk
