August 30, 2015 at 6:09 am
Would this go a long way towards securing the data?
Database.Store(this)
Database.Delete(this)
Database.Load(this)
Where "this" is a single object mapped to a single stored procedure.
Two parameters are recommended: one to identify user, and one to specify an "action" or different SP.
August 30, 2015 at 10:42 am
Maybe, but it depends on a whole pile of things.
How the server is physically secured
How the server is configured
How SQL is configured
Server permissions
SQL permissions (server and database)
Custom permissions in the procedure (how would you prevent an intern from calling Database.Load(HRDataWithSalary)?)
That said, it'll do horrible things for performance, maintainability and extensibility. It's also a violation of several software engineering principles, especially single responsibility.
There's far easier ways to secure a database that don't have all the side effects.
Gail Shaw
Microsoft Certified Master: SQL Server, MVP, M.Sc (Comp Sci)
SQL In The Wild: Discussions on DB performance with occasional diversions into recoverability
August 30, 2015 at 11:35 am
I think it's a first step. It makes it idiot-proof.
While not applicable every situation, it does handle 90+% of all applications. Since the userID would be the first parameter, that does cover database security, in addition to the application role-based security.
The performance would not be an issue in nearly all applications. Optimization is something to discuss afterwards. It makes application development very rapid and very simple too.
Viewing 3 posts - 1 through 2 (of 2 total)
You must be logged in to reply to this topic. Login to reply