a2e php_users

generalised user managment for diverse websites and databases

We need to allow users of diverse sites to register, authenticate and establish a cookie-based session, as minimal web functionality, combinable with a heterogenous landscape of database schemes and web applications. We’re getting there by generalising and simplifying existing free software.

1 Situation

  • before installation set/decrypt some cookies and keys:
    • for D in prod test do (cd $D/include && for F in *.asc;do gpg $F;done);done;make install

2 Tasks

The most likely next step is building of a RPM package.

The following task list has not been reviewed for a while.

Roadmap toward a2e php_users v 1.0

  1. get php_users to work with the latest php5 under secure configuration settings in the local web production system – largely DONE
  2. separate database calls from the source code, rewrite them as PHP functions – DONE
  3. produce customised versions for http://a2e.de and http://eupat.ffii.org and development versions thereof, as well as a customisation scheme that allows maintenance of multiple different sites – largely DONE
  4. use PEAR::DB and PostgreSQL with an initial similar schema –– DONE
  5. introduce a transitory schema –– DONE
  6. create a system for mapping between the data schemes of the application frontend and database backend, use it to simplify the application frontends (one simple put-get procedure, independent of how many tables are used in the backend and how the columns are named) – DONE
  7. produce a version that uses self-chosen login name and crypted passwords – DONE
  8. make sure that users can change their authentication data and e-mail address securely without manual intervention by an administrator; extend php_users where necessary and cut out anything that is not needed for this minimal purpose of the system – DONE
  9. work out a more powerful mapping system (using functions to map many fields to many columns, rather than plain 1:1 mapping), run different mappings for several database schemas – DONE
  10. adapt to the FFII database schema – DONE
  11. configure more sites, clearly separate core from site-specific extensions – in progress
  12. work on the session/cookie data storage/serialisation to ensure maximum interoperability with applications written in other languages; in particular, write some frontends for simple adminstration tasks in languages other than PHP and make sure they have access to the full user/session info of a2e php_users – under study (looking e.g. at http://www.openwddx.org/)
  13. produce german version and general localisation framework (possibly based on gettext)
  14. publish a nicely packaged and documented and well-tested version of a2e php_users, contribute it to PEAR if possible

Find a more detailed sequence of missing steps on the development version page.

Further desirable functionality beyond 1.0

  1. write more complementary web software (e.g. member and finance administration) in non-native (non php) languages
  2. further enhance interoperation with non-native applications
  3. support standards such as
    • LDAP (possibly as a secondary data format, generated from the rdb backend)
    • OpenID
    • SOAP
    • XML-RPC
    • e-mail-based interaction (knecht and better)
  4. further enhance the database ↔ webform converter syntax
    • use a more generic configuration syntax, such as YAML or SpOn
  5. fine-tune the appearance and user interface
    • enhance separation of form and content
    • introduce some style-related option sets (skins)
    • introduce some AJAX elements where useful
    • make it possible to install and configure the system by simple editing of a web form

Why PHP?

Some knowledgable people have been pointing out scary flaws in PHP, and indeed we agree that PHP is a somewhat less powerful and less elegant language than, let’s say, Perl, Python or Ruby, not to mention Scheme and Common Lisp. So why are we using PHP?

  1. Our starting point, Majordojo’s php_users, is written in PHP.
  2. PHP has a strong professional community backing it and tons of great software (e.g. Mediawiki, Typo3, Moodle) running on it. No matter how deficient it may be, it’ got to be good enough for the simple minimalistic system that we envisage.
  3. PHP is optimised for web programming and comes with a wealth of libraries that allow the system to interoperate with any standards on whose basis then non-php applications can be written.
  4. Because of its wealth of applications and support for standards, PHP is an attractive base framework for nearly-static websites such as http://eupat.ffii.org/ that try to be open for future enrichment with various dynamic elements, based on specific needs of the one or other section of the site.
  5. Using a less elegant language for the base framework increases the pressure on us to make this framework really minimalistic and interoperable.

2.4 Resources

deplate
http://a2e.de/adv/php/users
© 2007-02-25 Hartmut PILCH