Geeklog 2 Update

Geeklog 2 this, Geeklog 2 that. By now many of you are wondering what the hell *is* this vaporware. Well, I'm happy to announce that Geeklog 2 now has a pulse. This evening I managed to get a small set of the new authentication and authorization code working along with a new custom PHP4 session handler that will simplify how Geeklog 2 handles sessions and it will allow us to serialize PHP objects to the session. For many of you this update is enough but if you are a real geek and want the gory details along with other current efforts click 'read more'

Here is what I posted to the geeklog-devel mailing list (FYI, you can get development updates on GL2 by joining the geeklog-devtalk list.

Ok, granted it isn't rocket science but it is, in fact, a start. Please bare with me and read this it it's entirety.

Go here:

http://project.geeklog.net/~tony/

There you will see a very simple login box with account information below it on how to get in. Once you log in you are presented with a link that will take you to a page that will dump out a bunch of session data.

Here is what is happening:

1) When you hit submit, a request for authentication is built in the form of an XML string. This XML string contains:
- Application ID
- Username
- Password
- Command Name (in this case authenticate)

2) Server receives the request and sends it to the command factory which recognizes the XML request as an authentication request. It then instantiates (on the fly) an instance of the authenticate command and tells it to execute.

3) Authenticate command then passes the application ID to the provider factory to determine which data provider to authenticate against. In this case it builds an instance of the SQLProvider class and executes the authenticate method.

4) SQLProvider authenticates user, gets any group and permissions tied to the user and returns the results back to the authenticate command.

5) Authenticate command then builds an XML response and sends it back to calling application.

6) The client receives the response, parses it into a User object and saves it to the session (which is stored in the database). It then shows you the link to a new page.

7) new page pulls the user object from the session with a single DB call and outputs a few attributes on the user.

To be clear this establishes a few things:

a) we now have an A&A service which can service many applications to implement a single credential set. This makes the prospect of tying other applications in easy encouraging 3rd party apps to work with GL2

b) service can run on a separate box from GL or (as in this case) on same box.

c) user data is persisted to a database using PHP4 sessions effectively rendering all the code that use to be in lib-sessions.php useless (saving, restoring and garbage collection is done for us by PHP)

d) succesfully pulled a PHP OO user object from the session with a single database hit. If you recall in GL 1.3.x you have to sometime hit 2 or 3 tables often with independent queries against user, user_index, user_prefs, etc in order to re-establish session. Now you do it with one DB call that you don't even make (PHP4 session handler pulls it for us when you call session_start).

There is still a lot of work to do. I'd like to convert one of the service methods to use SOAP just to see how much easier that will simply the code (with SOAP I don't have to build and parse XML which also removes the requirement having xml support compiled into PHP). If that tests out Ok and if timing benchmarks both on the same server and on separate servers is acceptable I will convert it over.

However, in the meantime, we need to start concentrating on localization. Handling language effectively as well as time/currency stuff will be key and, frankly, we can't go anywhere else without getting that done. Marc, if I get you a template for a detailed requirements document do you think you could get it started for us? By them time you get a draft of that I should have this code stable enough to start divying up work immediately.

--Tony