Thread: PostgreSQL/PHP Application Server
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...
On Jan 24, 2008, at 12:15 PM, Brian A. Seklecki wrote:
> 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.
Drupal - http://drupal.org
I don't know if there is a module for #4; check http://drupal.org/project/Modules
. The user/login system is extensible, so you could write your own.
John DeSoi, Ph.D.
On Thu, 2008-01-24 at 13:10 -0500, John DeSoi wrote: > . The user/login system is extensible, so you could write your own. I'm not sure if I follow: Are you suggestion that the CMS system, Drupal, is an example of an application server model because of its framework extension? ~BAS IMPORTANT: This message contains confidential information and is intended only for the individual named. If the reader ofthis message is not an intended recipient (or the individual responsible for the delivery of this message to an intendedrecipient), please be advised that any re-use, dissemination, distribution or copying of this message is prohibited. Please notify the sender immediately by e-mail if you have received this e-mail by mistake and delete this e-mailfrom your system.
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.
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@spiritual-machines.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
On Feb 2, 2008, at 9:40 PM, Brian A. Seklecki (Mobile) wrote: > On Thu, 2008-01-24 at 13:10 -0500, John DeSoi wrote: >> . The user/login system is extensible, so you could write your own. > > I'm not sure if I follow: > > Are you suggestion that the CMS system, Drupal, is an example of an > application server model because of its framework extension? No, I was suggesting an approach that might address your requirement for integration with other authentication systems. John DeSoi, Ph.D.
> No, I was suggesting an approach that might address your requirement > for integration with other authentication systems. > Actually what I really need is the Oracle 9i + Oracle Directory Service functionality (e.g. nss_ldap for PostgreSQL). That combined with Oracle Label Security (OLS) -- from what I can tell, is just a extra glorified bitmap / security descriptor column hidden from the user. I think that I can accomplish the same functionality, possibly, using views and meta-data. As for synchronizing users with OpenLDAP, that's going to be ugly no matter how we do it. > > John DeSoi, Ph.D. > IMPORTANT: This message contains confidential information and is intended only for the individual named. If the reader ofthis message is not an intended recipient (or the individual responsible for the delivery of this message to an intendedrecipient), please be advised that any re-use, dissemination, distribution or copying of this message is prohibited. Please notify the sender immediately by e-mail if you have received this e-mail by mistake and delete this e-mailfrom your system.