General integration suggestions for app developers
|
Coyoteold1
Joined: 2005-06-03
Posts: 2 |
Posted: Fri, 2005-06-03 02:32
|
|
I'm probably making myself hated around the world, because I've been posting this suggestion all over. It seems that, for some time, every php web application developer has created their app with it's own hardwired user/auth/settings system. And usually, there's a single table that has username, password, settings, profile information, and other assorted stuff all stuffed into it. Each web app (forum, gallery, or whatever) has it's own method of user registration and login. It's almost as if every web application developer thinks that their application will be the only one on the user's site. Sometimes it is... sometimes it's not. If app developers would do a couple of simple things, it would make it much easier for other application, portal, or CMS developers to integrate their app. 1: Have a user/auth table that is _seperate_ from settings, profile info, statistics gathering, etc. Ideally, a user login/auth table would have _nothing_ in it except for login name and password, and possibly a unique id seperate from login name. 2: Have the ability to choose, in a setting of some type, whether or not to use the application's user registration process, or share the process of another application. 3: Allow the specific cookie or session name that their app uses be settable by the person installing the software, so that whichever cookie (or whatever) is being used by their app for login can also be used by another app or portal. Currently, it seems that most developers are treating login, authorization, account creation, settings, and profile information as if they were all the same thing. These are actually seperate tasks. If php web app developers would do these things, especially if they coordinate with each other to develop predictable standards for them, then integrating or porting applications would be a snap for everyone. App developers could spend more time focusing on what their apps do best, instead of recreating the wheel for things (like auth) that every app needs, and portal/cms/integration developers could focus on what _their_ products do best. How about it? : ) So far, it appears that Gallery2 is a lot better about some of this stuff than most other apps I've seen. It's user table is very light, and there's an option to disable registration without mucking up anything else. Partly, what got me motivated to post about this _elsewhere_ was seeing the Drupal integration module for Gallery2 - the key to it's functionality seems to be to make sure to pass the logged-in user to Gallery2 and make sure that an entry for that user exists within Gallery2's database. Coyote |
|
Posts: 32509
Coyoteold1, we're quite fond of our integration architecture. G2 is built for integration and we spent considerable resources to evaluate different integration approaches and to find a good solution such that when the final release of G2 will be out this year, we already support several integrations with other applications.
First off, yes, this is a viable approach. But there are a number of obstacles:
- this integration approach doesn't work at the moment, you're depending on a non-trivial change in most projects.
- as long as there is user data other than the user name in the table, you'll have the problem of the data format (incompatibilities between projects) and how to add further user data
- all applications need to be in the same database for rapid sql queries
- some projects won't like it and it will be hard to motivate them for such a change
- and if you don't share user data between the applications with a single user table, how do you synchronize it then? (solved in G2 integrations)
- you require that both applications use the same IDs. of course most applications allow you to change the hardcoded ID of special users (anonymous, sometimes admin) in the code. but that's not a user friendly approach
- and the user id must have the same format. and we had a big problem with G2: all entities (albums, photos, users, ....) in G2 are derived from the same class and share the same set of unique ids. if the other application wants to create a user with id 17, this id could already be taken by another entity (photo, album, ...) in G2.
- i agree, that's important
- in G2, you can disable the user registration and you can use our G2 embed API (GalleryEmbed.class) to create/update/delete users from an external application
- sounds good, but as with most dependencies on other applications, it isn't available at the moment
- we went with a different approach: both applications keep their session cookies / handling. But G2's session handling is in a slave relation to the session handling of the other application. The other application tells G2 who the user is (trusted partner, authentication) and G2 checks if this user already has a G2 session or not and then loads G2 session data.
What you propose for the user synchronization is what we call "tight integration", because applications then are so tight integrated, such that one of the applications uses the user table of the other.
If you wanted to synchronize also the user groups, then it gets even more complicated. That's what we tried and successfully tested with G2 / xaraya. The fundamental problem was different group architectures. Xaraya with an unlimited number of nested groups and a tree like structure, user and groups stored in a single table, G2 with its ordinary user <-> group management. We had to translate SQL queries on-the-fly to make that possible and it worked.
Another stumbling block were user data fields like language, password and date. Some of them did not have the same format in xaraya. So you don't only have to translate queries on-the-fly, you have also to translate the results of the query on-the-fly. And it gets even more complicated with SQL table joins in a query where such format specific data is involved.
From a practical point of view you'll get even more problems, as what if applications use different / forked versions of the same database abstraction layer (constants, classes, ...).
And what about URL generation? You didn't cover this in your post. This is also solved in our approach (still, URLs are independent of user synchronization).
Mambo came to the same conclusion this spring an have now implemented the required API to fully support our approach. Without the required API, we can still fall-back on low tech user synchronization (on-the-fly user creation, periodic check if user data is still valid).
In practice, there are so many involved issues. I think we have found a great solution with our loose integration.
I really should write some pages about our development and why we came to the conclusion that the loose integration is superior. And we also need some docs about our final solution. For the time being, you can read the existing forum topics or dive into our code (modules/core/classes/GalleryEmbed.class, docs/EMBEDDING).
Embedding & Integration
http://gallery.menalto.com/index.php?name=PNphpBB2&file=viewtopic&t=23957
From tight integration (sharing users table, rewriting database queries on-the-fly) to loose integration (map userIds without any overhead):
http://gallery.menalto.com/index.php?name=PNphpBB2&file=viewtopic&t=20560
The interesting part of the discussion is in the last pages of the thread that is linked in the first post of CMS integration topic and also in the first pages of the CMS integration thread.
Posts: 2
I would applaud if you wrote some docs about what you did and why it's a good idea.
: )
Apps should be able to be integrated with one another without taking them apart. The way _most_ apps are structured, this is not possible. As far as I can tell, Gallery is one of the few that makes the effort.
And yes, I understand that what I suggest would be a non-trivial change. That doesn't mean that something shouldn't be changed. If the apps in question had been planned from the get-go with the ability to be integrated in mind, there wouldn't be a problem now.
The worst part is, that it seems like a lot of people look at how existing apps handle their user tables, and copy it. Every time I look at some new app, pretty much, it seems to do the same thing... big honking user table loaded with junk.
I'm not really interested in having anyone adopt any particular implementation that I suggest. What I'm interested in is seeing if I can convince any developers to make their apps easier to integrate with not only known, but as-yet-unwritten projects.
Apologies if I was unclear on this, but I _like_ a lot of what is done with Gallery, and think it's really several steps in the right direction.
Coyote