Unique DB access

aaron_watters at my-deja.com aaron_watters at my-deja.com
Sat Aug 28 15:11:10 EDT 1999


In article <7q0mdk$hovd at eGroups.com>,
  cgr at formulae.co.uk wrote:
> Dear all,  (newbie)
> Can some help me?
> I have a (gadfly) database with many users data.
> The database tables continue info about confidential training details
> of all the users....

How to implement privacy, basically, via cgi...

I'd recommend this:  Use gadfly client/server mode and gadfly
server policies to prevent general purpose access to the database
(and also to simplify and speed up the cgi code).

Distinguish users via a username and password from a login screen.
If you want to be paranoid you can encrypt/timestamp the uid/pwd
and time it out and allow the user to log back in after the login
screen.  Basically the uid and password would be passed around on
the GET line as long as the user is active in the system, and if they
are inactive they must login again.

As far as the database is concerned the uid/password is just more data
in the database (not a real sql/uid) and design the policies so that
the defined accesses don't work unless the uid/passwords check out.

On the other hand you can reverse-engineer how hotmail
or egroups or similar sites do it.  They
aren't quite this paranoid, and it works pretty well I think.
The only caveat is that the user must understand that they shouldn't
leave the computer with a hotmail login active if they want privacy.

   -- Aaron Watters http://www.chordate.com

===
If god meant us to be vegetarians
why'd he make cows out of meat?
   -- seen on a bumper sticker


Sent via Deja.com http://www.deja.com/
Share what you know. Learn what you don't.




More information about the Python-list mailing list