3rd party integration
I’ve done a bit of 3rd party integration work for ZenMagick, mostly on the WordPress and phpBB plugins. The following is a summary of my experiences and thoughts about that (based on a discussion I’ve recently had with a client).
3rd party integration examples in ZenMagick
The ZenMagick WordPress and phpBB plugins implement user syncing from Zen Cart/ZenMagick to the respective 3rd party application. That means any user/account change relevant in the other application is forwarded (or, more precisely, applied to the other application’s database).
What is full integration?
There is, of course, more to be had. Full integration would be to do exactly the same (ie. updating the Zen Cart database) from within other application (where appropriate).
Why ZenMagick plugins only implement one side of side of user syncing
Syncing from ZenMagick to another app. is obviously not that hard. In fact, I’ve spend quite a bit of time tweaking the ZenMagick plugin architecture to allow doing that in a way that does not require any patching on Zen Cart or ZenMagick core files [excluded patches on Zen Cart to make ZenMagick work at all].
Things are looking quite differently doing the other side. The main blocker in implementing that is simply time! I just don’t have time to get involved in every 3rd party at the low level required in order to handle registration, login, logout and other events. I am sure other apps have code to allow to capture and process those events one way or another. However, learning that just for the sake of a plugin is just not possible.
I suppose for someone who maintains just a single plugin it’s fun to dive into both apps involved, but for me it’s just not practical.
Events that need handling for full user syncing
There are a number of events in each application that result in user data being changed. For ZenMagick, events exist to allow easy processing of the following events:
- registration
Registration of a new user. Once a user account is created, an event is fired that includes the new account. Also included is the password in clear text to allow plugins to store it (as-is, or as some sort of hash) in the other applications database - account update
Fired each time account information are updated. - password change
Since Zen Cart/ZenMagick have a separate dialog for updating a password, this is a separate event from account update. As with the registration, the clear text password is passed in the event. - request new password
Similar to a password change, however in this case the password is generated rather than changed.
Since it is usually not practical (the only exception so far is WordPress) to use code from both applications at the same time, the typical solution to add data to the other application is to generate low level SQL. (For exampe, phpBB uses a global $db to access the database, same as Zen Cart!).
Single Sign On (SSI)
If SSI is required, the list of events to handle needs to be expanded by the following two:
- login
An event to notify interested code/plugins that a user has successfully logged on. The account is part of the event parameters. - logoff
Indicates that the current user has logged off.
Capturing these events is as simple as all the others above in ZenMagick. The tricky bit is to actually make the other application believe that the same has happened over there!
There are a number of ways to archive this:
- Fake login/logogg requests
The code that handles the login/logoff events generates a GET/POST to the other applications login form / logoff URL with appropriate parameters.
This does work, however for my taste this is a bit too fragile. - Simulate login/logoff
What I mean with this is that all activities required to register/invalidate a session are replicated. This includes:- Set session cookie
- Create session record in database (or other session store)
- Add user id or other session data required to make a session valid
Obviously, this is the more elaborate alternative and also not without downsides. It requires intimate knowledge of the other app and is prone to break when the 3rd party application is upgraded.
- Linked user accounts
This approach is based on some sort of repository (usually a database table) that is used to map or link corresponding user between Zen Cart and the 3rd app.
Then both applications need to be extended to allow to recognize each others session. This doesn’t have to be complete, though. It is sufficient if ZenMagick can identify the 3rd party’s user id and vice versa. The mapping table can then be used to lookup the corresponding own user details and the user gets logged in automatically.
Personally I really like option #3. I haven’t tried implementing it yet, however it seems to involve the least overhead on both sides. Also, it minimizes the amount of knowledge that each application needs to have of the other one and leaves each application to manage it’s own sessions, not the other ones!
In the most generic version there could be a login service on ZenMagick side that manages a number of 3rd party specific sniffer modules that try to detect 3rd party sessions for each request. In that scenario only the really application specific code would need to be written from scratch for each new external application.
The good news is that with zm_auto_login a plugin already exists that can login a Zen Cart user based on an customer id taken from a separate database table (and identified by a separate cookie [that could be shared by both apps]).
