note 109558 added to security.database
| From: | ChrisTravers | Date: | Sat, 28 Jul 2012 11:45:44 +0000 |
| Subject: | note 109558 added to security.database | ||
| Groups: | php.notes | ||
| Request: | Send a blank email to php-notes+get-189438@lists.php.net to get a copy of this message | ||
Regarding where to put logic, it's really best not to be dogmatic about this. Putting logic in
the db can have some security advantages but it has other security gotchas (for example, SQL
injection inside a stored procedure may be possible in some environments). Similarly it can have
some portability advantages and disadvantages.
The real question is that you want to ask what you want to be portable. If you put it in the db, it
becomes easier to integrate programs written in different development environments with a minimum of
security gotchas. If you put it in the application, then you have to create the interfaces on that
level in middleware. Both approaches are doable. On the other hand if you are writing software you
want to be deployable in MS SQL shops and Oracle shops, then you have to write portable SQL
(avoiding gotchas) and put the logic in the application.
When we started rewriting the LedgerSMB codebase, we decided to move logic into the db because this
would make it easier to retrofit security onto a very insecure codebase (by not trusting the
application), and because we wanted to support languages other than Perl. A few years later this is
bearing fruit and indeed I am reading the manual because I am writing integration libraries in PHP.
I am not much of a PHP guy (I haven't programmed PHP since PHP 4.x) but I can write modules
that let folks write code to interface securely with LedgerSMB's database logic. You can think
of the stored procedures as being named queries which are shared between applications, or as
API's to the database. But again, this approach is not universally applicable.
If portability between db's is not a major requirement, then I think the best approach is to do
as much as possible in SQL queries and put those in the database. A couple hundred lines of SQL can
replace a couple thousand lines in Perl or PHP, and is fundamentally easier to debug. Of course
that won't work for everyone.
----
Server IP: 69.147.83.197
Probable Submitter: 111.95.102.137
----
Manual Page -- http://www.php.net/manual/en/security.database.php
Edit -- https://master.php.net/note/edit/109558
Del: integrated -- https://master.php.net/note/delete/109558/integrated
Del: useless -- https://master.php.net/note/delete/109558/useless
Del: bad code -- https://master.php.net/note/delete/109558/bad+code
Del: spam -- https://master.php.net/note/delete/109558/spam
Del: non-english -- https://master.php.net/note/delete/109558/non-english
Del: in docs -- https://master.php.net/note/delete/109558/in+docs
Del: other reasons-- https://master.php.net/note/delete/109558
Reject -- https://master.php.net/note/reject/109558
Search -- https://master.php.net/manage/user-notes.php