This feature allows different tikis to communicate with each other. It’s based on the xmlrpc protocol, so it will be extendable to several other applications. It was commited in the CVS 1.9 Branch on 12/23/2005 by mose. Though new features should be in HEAD, this one is really needed in the Tikiwiki community for gathering authentication for subdomains *.tikiwiki.org.
Initially thought for distributed auth system, Intertiki will now extend to other functionalities quite soon.
Mainly for debugging use right now, it will be useful to be able to specify a minimal version for some future enhancements.
This enable using a tiki account on another tiki. One tiki is server, the other is the client. The server has to provide a url where to reach the xmlrpc server, the client uses that url to reach server and send xmlrpc requests.
The idea is to avoid creating a local account for such remote login. I used the @ as a delimiter for specifying the ‘realm’ the login belongs to.
The @ login will then become logged into the local tiki, and will be attributed membership to groups that are defined by the configuration. Some changes are made here and there to avoid login containing a @ access certain features (like preferences and such).
So, in the login-box, a new menu is proposed with that feature when enabled, with a list of possible authentication locations, either local or remote. You also can type login@remote directly and it will be processed correctly.
Each validation request also sends a hash key that sort of identifies the client server. The use of that key will ultimately be optional, but for the tests it’s a good protection.
String: contains the interTiki key configured on the master server ?String: contains the username ?String:contains the password ?Boolean: if true will return a hashtable containing user data, if false would return Boolean true for success login ?String: the hashkey string with an <MD5 value>.<cookie expire time in miliseconds> ex. 30a725c63295a74093a4e79483cda7b6.1295521979
- add a way to replicate full account information to transform a remote login in a local account
- add a timer for selective requests to prevent flooding
- add more exceptions on features that shouldn’t be displayed to a logged user without account
- check all cases where tiki operations could be impacted by the use of ghost users
- hard-encrypt communication
- bug or feature?: If a module is shown to Anonymous, normally, it is shown to Registered as well. In InterTiki, it is not. Each module needs to be assigned to Anonymous and to Registered.
- enhance the logging system on server
- made it fully optional with admin panels and stuff
- http://phpxmlrpc.sourceforge.net/ (on which is based the xmlrpc pear lib used in tiki)
- ask mose