By Henk Wevers (www.breincoach.com)

At this time the following plugins use the cURL mechanism for Dual Login;

1. Magento
2. Moodle
3. Joomla_ext
4. SMF
5. DokuWiki
6. osCommerse (2.x and 3.x)
7. xtCommerce (3.x)
8. Kayako

When a user logs in on the Joomla login screen, the user is first validated using the masters user data. If the user is a valid user, this user is logged in to Joomla and then to all other activated plugins using the smart cURL Jfusion library. Parameter settings for the plugin will control how the plugin uses this cURL library to log in to the integrations.

Appendix 1 lists all available cURL parameters with their defaults. There is room to fill in your specific parameters if your setup or templates differ from the default installation of the integration. Note that in the majority of the cases the default values will work.

Below I will point out how you can find out which parameters have to be adapted while describing the methods the smart cURL routines use to log in and out.

Firstly the routines try to find a valid login form. The URL where the routines search is made from the “full URL to the integrated software” set by the wizard and the cURL parameterlogin_url. So if your integrated website has a base URL www.yourdomain.com/moodle and the login form is on www.yourdomain.com/moodle/login then the parameter login_urlshould be set to login. Mostly the loginform is on the front-page, in this case the parameter is left empty.

Secondly the routines try to find the login form by means of the name or ID of the form. If you have modified your login form and given it a different name and ID then you surely know the data to overwrite the default value of the parameter loginform_id.

Once the login form is found, the routines try to find the names of the username and password fields. As most login forms use ‘name’ as part of the identification of the username field and ‘pass’ as the part of the password field the routines will find the needed data in 90% of all cases, so you can leave the parameters input_username_id and input_password_id empty as a start. If the routines cannot find valid IDs, you will get an error message stating the fields found in the login form so you can adapt above parameters.

Now the login form will search for essential data needed to login. These are hidden fields and button information.

Finally the form is searched for the URL to post the login data. This URL can be a full URL (http://.……) or an URL relative to the base URL. This can be specified with the relpath parameter.

As said, in most installations the default parameters will work, But if you have a heavily modified login form you probably need to adjust these parameters. An easy way to find out what you need to fill in is to point your browser to the login screen, display the page source and search for the login form using the string “<form”.

<form action="http://www.jfusion.org/index.php"method="post"name="login">
<input type="text"name="username"size="18"alt="Username"value=""/>
<input type="password"name="passwd"size="10"alt="Password"value=""/>
<input type="hidden"name="remember"value="yes"/>
<button value="Login"name="Submit"type="submit"title="Log">Loginbutton>
<input type="hidden"name="option"value="com_user"/>
<input type="hidden"name="task"value="login"/>
<input type="hidden"name="return"value="aHR0cDovL3d3dy5qZnVzaW9uLm9yZy8="/>
<input type="hidden"name="b90bc837e46d358fa4701cfdd3c82e3a"value="1"/>
form>

As you can see the name of this form is login, so you have to set the loginform_id to “login”.

The id’s for the username and password fields are username and passwd. Because these contain name and pass the cURL routines will find them without problems. You need to set the input_username_id and input_password_id parameters if you have something totally different. Integrations that use the emailaddress as identification often have email in the id’s. In this case you will see that the defaults are already changed to adopt to this setup.

The action parameter is a full URL so the relpath parameter should be set to no.

The cURL routines will find the button and hidden fields, analyse them and use them to login in exactly the same way a human user would do. For special cases like backward dual login (there are plugins and core hacks to make it possible to also login from Moodle and Magento to all integrations automatically) we can override the value of a hidden field by using the parameter override. For reverse duallogin we use the value login[indirect]=no. So if the login form has a hidden field with the name login[indirect] the value will be set to no independent of the real value put in the form. You can have multiple overrides by separating them with a comma.

If hidden and button information should be used to login we can set the hidden and buttons parameter. This really depends on the way login is processed by the integration. Leave it to yes for a start. If anything else fails and you still cannot login, try setting these values to no.

The routines now submit the loginform. The integration software will now, if the login is successful try to set cookies on the clients system to start a fresh session. The Curl routines will intercept these cookies, analyze them, modify them if needed and then set those cookies by themselves.

You can make them change the cookie domain, cookie path, expiration time, secure flag and http flag by setting the parameters Cookie Domain, Cookie path, cookie_expires, secure and httponly. If your integrated software has the cookie domain and cookie path set (use .mydomain.com and note the dot in front) then there is no need to set those parameters. The routines will figure this out themselves. However, if you cannot set the domain and path in the integrated software the software or your browser will come up with something. Sometimes weird domains like .www.mydomain.com (note the dot!). You now have to set the cookie_domain parameter to exactly the same as the cookie properties. You can find this out as follows:

1. Install the Firefox browser

2. Install the Firebug plugin in this browser

3. Install the Firecookie plugin for Firebug

You can now see what cookies are set. So

1. Clear all cookies

2. Go to the integrated software and login

3. Note what cookies are set

Now logout the integrated software, enable your JFusion plugin and

1. Clear all cookies

2. Log in from Joomla.

You will now be able to see what cookies are set by Joomla and the plugin. Change the plugin cookie parameters to match exactly the original properties. Note that the expiration time will be set for the session cookie, so it will no longer be listed as “session” but will show an expiration time.

So far so good. We are now logged in. That leaves us with the logout procedure.

Actually we logout by starting another session and deleting all cookies that the integration tries to set. This is not very elegant but it is very effective. The procedure taken by the curl toutines is simple, start another session and intercept the cookies that the integration tries to set. Then just delete them, except for cookies specified with the parameter leavealone. These are special cookies for the integration and cookies used for a “remember me” option. An example is the MOODLEID_ cookie that contains the session status (the encrypted username; nobody when a session is finished). To retain this cookie you set this parameter to MOODLE_ID⇒. The greater than character tells the cURL routines to leave this cookie alone only when the expiration time is greater than the current (server!) time. You can separate different cookies with a comma. There are more options available:

Specify the cookies with name=value, name2=value2 etc.

If ‘name’ is an existing cookie name then that cookie will be effected depending on the value: If value = '>' then the 'name' cookies with an expiration date/time > now() will not be deleted If value = '0' then the 'name' cookies will never be deleted at all

If ‘name’ = '0' then all cookies will be affected according to the value thus

0 = > will keep all cookies that are not session cookies 0 = 0 will keep all cookies We leave the parameter logout_url empty.

1. In system/configuration/web/session cookie management set the cookie properties exactly as those in your Magento Jfusion plugin parameters

2. In system/configuration/web/session validation settings set validate REMOTE_ADDR to no

1. In sitemaintenance session handlingset the cookie properties exactly as those in your Moodle Jfusion plugin parameters

1. Joomla has no way of setting cookie properties so you have to install a second Joomla in a subdirectory and observe the domain and path properties set by your webbrowser. See above.