Re: PostgreSQL/PHP Application Server - Mailing list pgsql-general

Frameworks are over-rated.  PHP makes most common tasks simple (not that I'm really a big PHP fan, but it works pretty well most of the time).  Just follow a few basic XSS protection rules, and you will have few problems.  Filter input elements for HTML,  don't put stupid things in cookies that can be sniffed or forged, same for URL parameters, don't make database queries by concatenating strings made up from $_GET or $_POST values, use prepared statements instead, write a basic authentication framework that is mostly just calling auth($expected_role), and going to a auth failed page if it returns false (if thats appropriate, or just set a flag so the rest of the page knows this is not a logged in user).  I've found that I seem to spend as much time programming for the exceptions to the frameworks inbuilt mechanisms as I would have if I just built it myself as a basic page in raw PHP/SQL, not only that, but abstraction layers just add overhead which makes you scale less, and cost more $$s.  I've seen a J2EE app that fell over with just 32 users (and it wasn't anything to do with data mining) because the entity bean layer was thrashing the crap out of the database server.  Do yourself a favour - put sessions in the DB not on the file system, and let the DB do what it's good at - being fast at data access (now if I could just figure out how to make certain table stay in RAM...) (for goodness sake, database professionals have spent 30 years making sure that databases are fast, can any framework programmer claim the same thing?)

As for security - Monolithic security is obvious because you can't forge a new database connection for every user that connects to your system - it doesn't scale, you have to use connection pooling, which means one master-user profile, and web users get authenticated at the application level, not the DB level.  PHP supports LDAP just fine, you can auth against LDAP no problem (even Windows AD though the schema is scary), but ultimately roles for your application will be in the DB with all your other data.  You can lazy initialize users in the DB when you auth them for the first time from the LDAP server.

I really don't know what row-level security even means, but most security has to function not just on what data a user has access to, but rather what function a user has access to combined with the ownership of the data, which is mostly application level.  Many functions access the same data, but in different ways, trying to enforce authorization by data is wrong-headed in my mind.

PHP/Apache is your shared foundation, that IS the app server.  Your 'modules' are just directories with files (not that different from tomcat or JBoss really).  Use version control (preferably one that has good branching support like git), and a makefile to copy/FTP your files to your 'live' directory from your source directory so that multiple people can do deployments, and you can deploy to one of multiple environments easily (think personal development server, nightly build environment, staging environment and live environment) by simply changing an environment variable.

The only thing I've seen that's worth adding to this mix is content management, and I've yet to see someone do that well in the FOSS community.  Drupal is a mess (and is basically MySQL), Joomla isn't that great and is also MySQL, and Plone is over complicated with lousy documentation, and is sadly based on Zope, which uses ZopeDB, which is also really poorly documented (as I write this, looking for an example I had in mind,  http://wiki.zope.org/zope3/ is actually down right now).

If you want to do the world a favour, write a CMS that doesn't suck, preferably in Java, but PHP would do in a pinch.

If you keep it simple, you will be amazed at how many requests a single web-server can sustain if you just configure it with the right hardware (and no I don't mean 128CPUs and 1TB of RAM and 40HDs) and sit back and watch it fly.  If you need it, make a hot spare.  If your app can do 50 requests/second (which isn't that unreasonable with simple PHP/PostgreSQL), that's 4.3 million requests per day, which is a shit ton of traffic.  Chances are your network will max out before you hit the server's CPU/IO throughput ceiling.

Alex

P.S. Don't even think about working with PHP and not running into a serious bug somewhere along the way that's been ignored by the devs, and lets not even start about interface inconsistencies that make remembering the APIs a nightmare.  At least the website has good docs, which is a big plus for PHP against other 'frameworks'

P.P.S. Do the world another favour and run away from mod_perl screaming in terror if you ever want to debug your application or hire someone else who can understand it.