History: InterTiki
Source of version: 42 (current)
Copy to clipboard
! InterTiki
{DIV(float=right,width="200px")}^::Related Topics::
* ((External Authentication))
* ((MultiTiki))
*((dev:Administration|Bugs and Wishes))^{DIV}
;__Overview__: The InterTiki feature allows different Tikis to communicate user data with each other.
;__To access__: Click the __InterTiki__ icon {img src=img/icons/large/intertiki.png alt="InterTiki"} on the ((Admin Panels|Admin Panel)) %%% or %%% Access __http://example.org/tiki-admin.php?page=intertiki__
;__Tabs__: This page contains the following tabs:((Intertiki Client)) & ((Intertiki Server|Intertiki Master Server))
;__Note__: ''The information below pertains to using and administering the InterTiki feature. Eventually it will be moved to the new User and Administrator Guides''
^((needs review)) made major changes to descriptive text, added section for explaining InterTiki fields in detail and mentioned dependency on Log-In authentication type on clients^
! Introduction
The __InterTiki__ feature allows Tikis to communicate user data with each other. It's based on xmlrpc protocol. It can be extended to several applications if those applications can communicate via XMLRPC. It was introduced to allow cross site authentication in all the tiki.org subdomains.
^In Tiki 15 there is a simpler feature called ((Remote Tiki Autologin)) that might provide a less powerful but perhaps easier way from users from one Tiki to login to another^
!! Assumptions:
* The client IP must be fixed to have this feature working
* The InterTiki master must not exist behind an Apache authorization barrier. ([http://httpd.apache.org/docs/2.2/programs/htpasswd.html|htpasswd])
* The InterTiki Master must not use the Web authorization method.
!! Key Function and sub-features
InterTiki's primary design is meant to achieve master-slave authentication relationships between multiple Tiki sites. It's designed to allow several satellite sites authenticate against one central source for user data.
Additionally InterTiki can be used to transfer user profiles from the primary user source and their corresponding groups. Both of these choices are configurable and allow for a wide range of authentication and user data share paradigms.
InterTiki can be extended for several other purposes with additional custom development utilizing XMLRPC's ability to query just about any asset of user data in a tiki.
!! Configuration example
In order to enable InterTiki for proper configuration, four key steps are required:
#Enable "InterTiki" in the Tiki feature controls on __both__ the master and slave(s)
#On the "client" Tiki (the Tiki that will be requesting to authenticate against a master) change the "Authentication Method" to "Web Server" in the Log-in feature page.
#Configure the server and client(s) based on the example information below making changes for your deployment where necessary.
!!! Explanation of fields
!!!! Server Setup
On the machine you will configure to be the primary authentication server (a Master that other Tiki's will request user data from) these are the fields that matter on the InterTiki feature page:
*__InterTiki Server Enabled__: Check this to make this machine an InterTiki Server
* __InterTiki shared cookie for sliding auth under same domain__: When enabled a user who logs into or out of any site(slaves or master) is automatically logged into or out of all other sites. (feature rememberme must be on)
*__Access Log File__: location, from your tiki root dir, where you want the access log file stored.
**''a few examples here would be nice. Does this path start with "/" or not. Is it a URL or a direct path to a file from the root of the server?''
*__Error Log File__: location, from your tiki root dir, where you want the error log file stored
The table after allows you to define multiple clients. Only clients on this list will be allowed to make requests against the server. This is useful, and necessary, security feature:
*__Name__: Arbitrary name used to uniquely identify this configuration (does not effect operation). Recommend use of a name that indicates the client server (ex: doc.tw.o)
*__Key__: This is the shared key you define. It has to match the client configuration for your server. It can be as short or as long as you like. It is recommended you follow the same kind of password policies your organization would have for something like a wireless WEP key.
*__IP__: The physical IP address the client machine will be making requests to the server from. ''If the client is on the same machine, you should be able to use 127.0.0.1''
*__Contact__: username of primary contact on client machine. Useful for adminstration
!!!! Client Setup
__IMPORTANT:__ On your client machine (machine that will request auth from the master server) you MUST have set the Authentication Type to "Web Server" on the Log In admin control page or InterTiki will not work.
''It is useful to start by first entering the InterTiki Server fields first''.
The InterTiki Server fields are for defining for every master server you want to have access to from this client
*__Name__: Set the name of your target server as defined in the server name field of the master. Use a distinct, but easily understood value.
*__host__: The full URL of the master servers primary Tiki (ex: https://tiki.org).
** Note, even if your Tiki is not at the top level of your web directory, you will still use the site's URL per the ex. above.
*__port__: The port number the master tiki responds to HTTP on (usually 80).
** Note: HTTP is the assumed method for XML_RPC interchange.
*__path__: the full path (from the URL root) to the PHP file containing the XMLRPC handler on the server
** EX 1: If the master tiki resides at the root of the site, you would enter "/remote.php"
** EX 2: Say the master tiki is found at http://www.mydomain.com/tiki/mytiki, you would enter "/tiki/mytiki/remote.php" in this field.
*__Groups__: Groups on the master to authenticate to (only auth users in the groups defined, case-sensitive).
** ''is this required, or can it be blank?''
''Click SAVE and then proceed to the upper-half of the InterTiki Client setup screen''
*__Tiki Unique Key__: This must match the shared key entered in the Master's key field.
*__xxxxx As Master__: Use the drop down list to select the master server you just setup.
*__Import User Preferences__: Check this box if you want your client Tiki to copy the user preferences from the master server (NOTE: This will overwrite local user preferences every time the user logs in)
*__Import User Groups__: Check this box if you want the groups the user belongs to on the master server to be imported (along with their security defintions). NOTE: This will overwrite local groups every time a user logs in.
*__Limit Group Import__: A comma separated list of case-sensitive group names. This list will limit the group import feature to only those groups listed here.
*__InterTiki shared cookie for sliding auth under same domain__: When enabled a user who logs into or out of any site(slaves or master) is automatically logged into or out of all other sites. (feature rememberme must be on).
!!! Pictoral Examples
You can see below an example of two Tiki clients (__doc.tiki.org__, __edu.tiki.org__]) configuration using InterTiki against __tiki.org__ as a master server.
!!! InterTiki client 1: doc.tiki.org
^::{img src="img/wiki_up/intertiki_admin_01.png" }::^
!!! InterTiki client 2: edu.tiki.org
^::{img src="img/wiki_up/intertiki_two_02.png" }::^
!!! InterTiki Server: tiki.org
^::{img src="img/wiki_up/intertiki_two.png" }::^
!! Hosting example
Please find below an example of successful setup at a hosting environment (siteground)
{SUB()}
__gezzaz notes__:
* the setup below is not so much different than above but I was struggling a while to get it right, so I decided to share it. I was stuck with error message saying that the key is not valid but it was entered correctly >> __I think I got this error because changing the key on the master side is not performed correctly. You will get the above error if you decide to change your key on the master and make a save. So you have to delete the whole config row on the master and enter the values again if you wish to make changes. On the client side you can change the key without removing the old entry, it got updated for me__
* Please interpret ''mydomain.com'' to your domain name
{SUB}
{SPLIT()}
Starting ground:
* main domain called __"mydomain.com"__ - this is the master
* a subdomain called __"sub.mydomain.com"__ (defined using Cpanel's Subdomain maintenance feature) - this will be the client
* tiki for mydomain.com is installed in the www root folder (public_html/)
* tiki for sub.mydomain.com is installed in the "subdomain" subfolder of the www root (public_html/subdomain/)
* at master tiki, the ''InterTiki'' features is enabled
* at client tiki ''InterTiki'' feature is enabled, at ''Login'' feature ''Authentication method'' option is set to ''Web Server''
@@@
||::__MASTER settings__::
__Name__| mydomain.com
__Key__| you choose, for example: 123456789abcdefghijklm
__IP__| the IP address of the server where mydomain.com resides (just ping mydomain.com and you will know)
__Contact__| enter your name or whatever you like, not important
||
---
||::__CLIENT settings__::
::''__InterTiki Server section__''::
::''(define this first)''::
__Name__| mydomain.com
__Host__| http://www.mydomain.com
__Port__| 80
__Path__| /remote.php
__Groups__| empty
::''__InterTiki Client section__''::
::''(select this after server is defined)''::
__Tiki Unique key__| as defined at the master, in this example 123456789abcdefghijklm
__InterTiki Slave mode__| mydomain.com as master
__Import user preferences__| checked
__Import user groups__| checked
__Limit group import__| empty
||
{SPLIT}
!! InterTiki internal details
!!! Get version : intertiki:get_version
Used for debugging at this time. Future plans include the ability to limit requests based on a minimally defined Tiki version.
!!! Remote login : intertiki.validate
This enables the ability to use a tiki account created on one tiki, at another tiki. One tiki is server, the other is client (client will authenticate against the server). The server has to identify a url where the xmlrpc requests can be reached. The client uses that url to reach server and send xmlrpc requests. (Typically this is: http://yourtiki/remote.php, as the XMLRPC server handler code is located in the remote.php file in your tiki root directory).
The idea is to avoid creating a local account such remote logins. At this time, a local account is automatically created on the client Tiki when a client succesfully authenticates against an InterTiki master server if that account does not already exist. InterTiki clients support the use of the @ as a delimiter for specifying the 'realm' the login belongs to when a user is logging in. This feature is primarily useful if a client Tiki can authenticate against more than one master tiki allowing for complex InterTiki relationships between Tiki sites. Some changes are made here and there to avoid a new client login containing a @ access certain features (like preferences and such).
Upon successful login from a remote intertiki server, the client will log the user into the local client Tiki. If the options are chosen it will also transfer the users preferences and group security settings from the master Interiki server.
Each validation request also sends a hash key that sort of identifies the client server. Eventually the use of that key will be optional. However a good security practice will be to keep it in place, especially if your Tiki is publicly available on the web.
!!!Future enhancements
In the login box a new menu is proposed with that when enabled via login features will list the possible master auth locations, either local or remote. The user could also type login@remote directly it will be processed correctly.
!!Trouble shooting
*check the IP is the right one by checking the tiki Logs
*check that the error log and the access log are writeable by the server
*if your client does not have a static IP and you need to specify an IP range in the server settings check out a temp fix here: [http://dev.tiki.org/tiki-view_tracker_item.php?itemId=1878|http://dev.tiki.org/tiki-view_tracker_item.php?itemId=1878]
!!! Changed client host
When moving a client instance to another host, the client login will not work properly and the access to admin will be not possible. In this situation, just update the new client IP on Tiki master (The address should be something like this: https://example.com/tiki-admin.php?page=intertiki#contentadmin_interwiki-2).
!!! Changed client key and host
When hosting several Tiki instances on one host is common to use a single client key for all instances (not recommended). So, when you need to move a single Tiki instance to another host, it is not possible just update IP for that instance, because it will break all other instances using the same key and old IP.
In this situation, admin is unaccessible and is not possible login on client to fix it. A new key is needed for this Tiki instance and the follow step may solve this situation:
__1.__ Open a MySQL client
__2.__ Select the Tiki database
{CODE(colors="sql",wrap=0,ln=1)}
USE tiki_example;
{CODE}
__3.__ Create another key for your client
{CODE(colors="sql",wrap=0,ln=1)}
UPDATE tiki_preferences SET value=MD5(CONCAT(RAND(), 'example.com')) WHERE name='tiki_key';
{CODE}
__4.__ Check and copy your new key
{CODE(colors="sql",wrap=0,ln=1)}
SELECT * FROM tiki_preferences WHERE name='tiki_key';
{CODE}
A box like below will appear as result of previous command. Copy the -+value+- field from it.
{CODE()}
+----------+----------------------------------+
| name | value |
+----------+----------------------------------+
| tiki_key | 61d96346b08f9f6633618b8fb678f0c4 |
+----------+----------------------------------+
{CODE}
__5.__ Open browser at keys config page on your Tiki master (Something like https://example.com/tiki-admin.php?page=intertiki#contentadmin_interwiki-2)
__6.__ Scroll down until you see field to a new entry
{img type="fileId" fileId="1408"}
__7.__ Fulfill it with a meaningful name, paste new key and the new host IP and click on __Apply__
{img type="fileId" fileId="1409"}
__8.__ Delete Tiki client cache on new host (-+/var/www/html/+- is the Tiki root folder, change it to reflect you installation)
{CODE(colors="sql",wrap=0,ln=1)}
find /var/www/html/temp/cache -type f -type f -not -name "*.php" -not -name ".htaccess" -delete
{CODE}
__9.__ Now you should be able to login in Tiki client
-=Related Links=-
* http://www.xmlrpc.com/
* http://phpxmlrpc.sourceforge.net/ (on which is based the xmlrpc pear lib used in tiki)
* http://tiki.org/InterTiki
* ((TRIM)) to manage many Tikis!
-=alias=-
* (alias(InterTiki Config))