Re: Where to get this kindof advice.

[pboin]

My authority suggests forcing ssl on these implementations should be optional, and we should let a client sign a waiver to use the system without ssl. This is a hole like Satan's *blank*hole. Am I being a reputable professional if I give in to these demands?

You are a reputable professional if you educate your employer (adjust definition appropriately) of the risks. *Always* tell people how it is, even if it causes moaning, bitching and ego bruises. Be tactful, but get the truth out there -- that's what makes a professional.

Now, the ball's in their court. He who pays the bills calls the shots. If you feel strongly enough, it's time to work for someone else.

I want to make the filesystem be the authority on a lot of things, like tracking users - for example, if a flat file called "joe" exists in a project directory, then user joe can enter it- (other people will be maintaining the system later, i need to ease it for them) So.. this info will be fed into a db for quick querying.

So therefore.. what should be my main authority on users, the db or the filesystem?

Personally, I like all my eggs in one basket -- stick it in the DB. Besides relational databases have a lot more functionality than filesystem metadata. You might have to front-end it for your admins, but if this is a banking application, that should be expected. Also, having all info in the DB makes distater recovery / backup a bit simpler I would think. Your DBA does his job, backs up the dump and you're good.

Good luck. Sounds like you're in a unique environment...

[BerntB]

I want to second that about storing the authentication data in the DB.

(-: If you have to, alias the "ls" command for the admins.

Write a command that looks into the db, writes out what users have access -- and then exec's "ls" with the in-parameters... :-)