Re: PostgreSQL/PHP Application Server

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.

On Jan 24, 2008 12:15 PM, Brian A. Seklecki <lavalamp(at)spiritual-machines(dot)org>
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
>