On 11/10/05, Chris Muller chris@funkyobjects.org wrote:
Magma must have security or it will never work directly on the Net.
Well, you are free to do as you like with Magma, but I could not care less. I'm not even sure it'd be nice to have security in Magma, and if so - please make it optional.
"I would suggest going with a system that always encrypts automatically to see how you like it..."
Now, that's the sort of stuff that makes me cringe. Crippling local network speed by encrypting everything. It's still hard for a CPU to saturate network bandwidth on an ecrypted link, and for high-performance applications can well do without that burden.
If you really insist on adding it, I would strongly suggest that you create latent security in the server (iow - the server can accept by default both clear and encrypted links and a policy setting could always disable the cleartext bit) and a secure client as an alternative to the default.
But what's the idea of exposing a database to the internet anyway? I really can't think of a reason. I'd never in my life do it.
Case in point - the last project I setup where security was anywhere on the requirements list we didn't even expose the database to the webserver. Instead, we allowed access to the database only from localhost, and on that host we ran a basic apache server and every query that the webserver wanted to do got wrapped in an xml-rpc service in that apache server.
So for security analysis on that site, we don't need to go through lengthy evaluations of database-level security (or even table-level or row-level, both absent in Mysql anyway ;)), we simple do 'more *' in the XML-RPC service directory and get a list of queries that are allowed.
This sort of stuff does not, IMNSHO, belong in a persistence engine. Not even an object persistence engine. Persistent objects don't usually form the application layer.
But then, prove me wrong. I liked to be proven wrong if it makes life simpler for me ;)