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.
On Jan 24, 2008 12:15 PM, Brian A. Seklecki <lavalamp@xxxxxxxxxxxxxxxxxxxxxx> wrote:
All:
Are there any frameworks / toolkits available, possibly as established
F/OSS projects, for web applications using PHP+PostgreSQL?
sf.net/google comes up short -- a few XML services and Perl+PgSQL hits.
By 'application server', as a marketing wank-word gleaned from
Oracle/IBM/BEA, essentially constituted by:
*) Templates for common data structures
*) Centralized deployment of applications as 'modules' using
a shared foundation
*) A row-level / user-level ('view based') object security model
*) Corporate Directory / Backend Integration (LDAP, Kerberos, PAM, NSS)
If such a project doesn't exist, I propose instantiating one.
#1 and #2 are easy. #3 and #4 are showstoppers.
== Monolith Security Model ==
WRT security, the "monolithic security model", whereby:
- The application on your web systems connects as a proxy/meta
'application user' role to PostgreSQL
- Who has unlimited authorization privileges
- Data access security is enforced entirely in-code
There is no shortage of discussion on the topic in the list archives,
but no conclusive answer documented anywhere on a commonly accepted
mode.
This is the kind of security model still recommended by 99% of the
PHP/PostgreSQL books on the market, and it keeps the "IT auditor"
industry alive.
== Directory / Corporate Integration ==
WRT to LDAP/Kerberos, but mostly LDAP these days, the current PostgreSQL
authentication framework allows one to proxy _authentication_ requests
to a corporate LDAP system (we'll call this the 'pam_ldap' aspect) --
However, no equivalent of the 'nss_ldap' functionality exists -- e.g.,
automatic population of group/role membership from LDAP groups and/or
CN= attribute/value pair mapping into pg_catalog.pg_roles rows.
That would be a big boost...
---------------------------(end of broadcast)---------------------------
TIP 2: Don't 'kill -9' the postmaster
