in reply to Which way to go?

Frankly, I think I would go with the second option. I don't have any technical justification, though, but a legal one.

A long time ago, I worked for a company that had the firewall access logs available on our intranet. Probably the most popular one was who was trying to visit the porn sites. To this day, I have trouble keeping a straight face when I meet some of the people in that company because I know which particular leather/animal/gay/[insert fetish here] site they were trying to get to.

I asked one of the people responsible for that what they heck they thought they were doing. Were we begging to be sued? He replied "they signed an employment contract which forbade those activities. If they sue us, we'll win."

Anyone care to venture a definition for Pyrrhic victory?

I said "that's fine. But tell me, have we worked out how much it will cost us to win?"

The logs were taken down the next day.

Personally, I would not risk a programmatic approach with something this sensitive. What do you do if someone finds a hole in your code? What if someone comes behind to maintain the code and they open up a hole? All in all, I think a physical separation is the way to go. From an ethical standpoint, don't risk it.

Cheers,
Ovid

Join the Perlmonks Setiathome Group or just click on the the link and check out our stats.

Replies are listed 'Best First'.
I'd go with one table..
by flocto (Pilgrim) on Jan 19, 2001 at 05:16 UTC
    I can't help you with any legal aspects, since I used my business-classes to refresh my mind and sort my thoughts (some people refere to that activity as "sleep"..). And I won't help you with the ethical decission, cause I am not sure/don't have one either.. But here's the technical part and what I think about it:

    I'd prefer to have only one table, but using MySQL itself to manage what user may access what data. It has excellent user managament (e.g. access-controll for each column in a table) and I think it's quite secure as long as you're aware of what's goin on. You can still code an user-interface, e.g. CGI based to make it OS-independent. My idea is to ask the user for his/her username, password at the beginning of each session and try to connect to the database with these settings. All you have to code is the error-handling if someone tries to access some forbidden areas. All the access-managing stuff would be done by the database which is secure enough for my very own needs (it might be not for huge companies and/or very sensitiv data).

    However, you will need a write/update access for your programm to insert data into the database. Just make sure that noone can get that password. Then the only passwort that is _in_ the code is the master-password. And if possible I'd remove that, too.

    One more reason that I can think of is, that you should always avoid dublicated data (code and database). And if you use two tables with basically the exact same data that's about the best/worst example that you could give.

    Happy coding ;)
    octopus
    --
    GED/CC d-- s:- a--- C++(+++) UL+++ P++++$ L++>++++ E--- W+++@ N o? K? w-- O- M-(+) V? !PS !PE !Y PGP+(++) t-- 5 X+ R+(+++) tv+(++) b++@ DI+() D+ G++ e->+++ h!++ r+(++) y+
[reply]

In Section Seekers of Perl Wisdom