Difference between revisions of "Wordpress"

From Organic Design wiki
(Using MediaWiki accounts on Wordpress: same domain needed)
(Using MediaWiki accounts on Wordpress: how it works)
Line 12: Line 12:
  
 
== Using MediaWiki accounts on Wordpress ==
 
== Using MediaWiki accounts on Wordpress ==
We need to have a wordpress site which is seamlessly connected to a MediaWiki so that users can register and login using the MediaWiki login and registration process only. The Wordpress login/logout/registration links should direct users to the equivalent MediaWiki pages for those operations. If the user is already logged in, then they should already be logged in as the same user on Wordpress, and conversely, if the user is not logged in to MediaWiki then they should also not be logged in to the Wordpress.
+
We needed to have a Wordpress site which is seamlessly connected to a MediaWiki so that users can register and login using the MediaWiki login and registration process only. The Wordpress login/logout/registration links needed to direct users to the equivalent MediaWiki pages for those operations. If the user was already logged in, then they need to also be automatically logged in as the same user on Wordpress, and conversely, if the user is not logged in to MediaWiki then they should also not be logged in to the Wordpress.
  
From the Wordpress perspective this means an auto-login function needs to be created which takes over the login process. It first needs to check if the user is already logged in and if not, redirect the page to the MediaWiki login with the return-to set to the current Wordpress URL. If there is already a MediaWiki user logged in, then the Wordpress needs to automatically log the user in as this user, creating a new user first if necessary.
+
This consists of two small scripts, [http://svn.organicdesign.co.nz/filedetails.php?repname=extensions&path=%2FWordpress%2FWordpress.php Wordpress.php] which is a small MediaWiki extension that provides an Ajax callback for getting user info for a passed user ID and token, and [http://svn.organicdesign.co.nz/filedetails.php?repname=extensions&path=%2FWordpress%2FWordpress-wp.php Wordpress-wp.php] which goes at the end of the Wordpress ''wp-config.php'' file and checks the MediaWiki cookies to see if a user is logged in and if so checks via the MediaWiki Ajax callback if the cookie info is valid and if so creates and/or logs in the equivalent Wordpress user.
  
The MediaWiki check can be done using a local Ajax request which returns all the current user info (for local requests only).
+
=== How it works ===
 +
The idea is that the Wordpress checks on initialisation if there are any cookies present that represent a logged in user for the associated wiki - specifically a ''UserID'' and a ''Token'' cookie. The ''Token'' cookie is a unique character sequence which only exists if the user is currently logged in, and only lasts as long as the session after which time it's replaced by a new one.
  
This is done now, it consists of two scripts, [http://svn.organicdesign.co.nz/filedetails.php?repname=extensions&path=%2FWordpress%2FWordpress.php Wordpress.php] which is a small MediaWiki extension that provides an Ajax callback for getting user info for a passed user ID and token, and [http://svn.organicdesign.co.nz/filedetails.php?repname=extensions&path=%2FWordpress%2FWordpress-wp.php Wordpress-wp.php] which goes in the Wordpress ''wp-config.php'' file and checks if any MediaWiki cookies exists and are valid and creates and/or logs in the equivalent Wordpress user if so.
+
If the Wordpress does not find any such cookies, it logs any currently logged in Wordpress user out and returns to allow normal anonymous browsing of the site.
  
One issue with this method is that it requires that both the wiki and the Wordpress are running under the same domain so that the Wordpress is able to access the wikis cookies. If they were under different domains, then a client-side Ajax request to the wiki domain would need to be added to obtain the cookies.
+
If however a MediaWiki user ID and Token are found, then the code calls the MediaWiki Ajax handler (''Wordpress::user'') with these values (note that this request is not an Ajax request as it's being made by the Wordpress server-side PHP, not the client-side JavaScript like usual). The Ajax handler will check if the passed token matches the token for that user ID in the database, and if it does it returns the details for the user; their username, email address and a password to be used internally by the Wordpress (not the users MediaWiki password - the password is not really needed since normal Wordpress logins are disabled).
 +
 
 +
If the Ajax handler does not return any valid user then the cookie values were invalid and the result is the same as if there were no cookie values at all; i.e. any currently logged in Wordpress user is logged out, and the function returns allowing normal anonymous browsing of the Wordpress site.
 +
 
 +
If valid user information is returned, then first the Wordpress checks if it has an existing user of that name and if not it creates one using the information returned by the Ajax handler. It then makes either the existing user of that name or the newly created one the current user, logging out any currently logged in user if it was a different one first. And that's it for the Wordpress side.
 +
 
 +
The MediaWiki side consists only of the Ajax handler. An Ajax handler was used even though its not a true Ajax request because it's much lighter than processing a full MediaWiki page request. The handler simply receives a UserID and Token, creates a ''User'' object from the ID and checks if the User token matches the passed token to ensure there's no forgery going on. If there's a match it returns the information for the user in JSON format, or an empty JSON object if either there's not a match or the request did not derive from the local host.
 +
 
 +
=== Issues ===
 +
This method requires that both the wiki and the Wordpress are running under the same domain so that the Wordpress is able to access the wikis cookies. If they were under different domains, then a client-side Ajax request to the wiki domain would need to be added to obtain the cookies.
 +
 
 +
Another minor issue is that for the ''returnto'' feature to work (allowing the browser to redirect back to the Wordpress after login, logout or registration) the following conditions must be met:
 +
*The Wordpress must reside in subdirectory under the MediaWiki installation
 +
*The wiki must be using short urls, e.g. http://domain/ArticleTitle
 +
*The Wordpress subdirectory must start with an uppercase letter (since the MediaWiki returnto value is treated as an article title)
 +
If any of these are not the case, then the default code will not allow the ''returnto'' feature to work properly, but a simple redirect feature can easily be added into the wiki's ''LocalSettings.php'' to get around this.
  
 
== See also ==
 
== See also ==

Revision as of 21:53, 1 June 2013

Skinning

Resources

Using MediaWiki accounts on Wordpress

We needed to have a Wordpress site which is seamlessly connected to a MediaWiki so that users can register and login using the MediaWiki login and registration process only. The Wordpress login/logout/registration links needed to direct users to the equivalent MediaWiki pages for those operations. If the user was already logged in, then they need to also be automatically logged in as the same user on Wordpress, and conversely, if the user is not logged in to MediaWiki then they should also not be logged in to the Wordpress.

This consists of two small scripts, Wordpress.php which is a small MediaWiki extension that provides an Ajax callback for getting user info for a passed user ID and token, and Wordpress-wp.php which goes at the end of the Wordpress wp-config.php file and checks the MediaWiki cookies to see if a user is logged in and if so checks via the MediaWiki Ajax callback if the cookie info is valid and if so creates and/or logs in the equivalent Wordpress user.

How it works

The idea is that the Wordpress checks on initialisation if there are any cookies present that represent a logged in user for the associated wiki - specifically a UserID and a Token cookie. The Token cookie is a unique character sequence which only exists if the user is currently logged in, and only lasts as long as the session after which time it's replaced by a new one.

If the Wordpress does not find any such cookies, it logs any currently logged in Wordpress user out and returns to allow normal anonymous browsing of the site.

If however a MediaWiki user ID and Token are found, then the code calls the MediaWiki Ajax handler (Wordpress::user) with these values (note that this request is not an Ajax request as it's being made by the Wordpress server-side PHP, not the client-side JavaScript like usual). The Ajax handler will check if the passed token matches the token for that user ID in the database, and if it does it returns the details for the user; their username, email address and a password to be used internally by the Wordpress (not the users MediaWiki password - the password is not really needed since normal Wordpress logins are disabled).

If the Ajax handler does not return any valid user then the cookie values were invalid and the result is the same as if there were no cookie values at all; i.e. any currently logged in Wordpress user is logged out, and the function returns allowing normal anonymous browsing of the Wordpress site.

If valid user information is returned, then first the Wordpress checks if it has an existing user of that name and if not it creates one using the information returned by the Ajax handler. It then makes either the existing user of that name or the newly created one the current user, logging out any currently logged in user if it was a different one first. And that's it for the Wordpress side.

The MediaWiki side consists only of the Ajax handler. An Ajax handler was used even though its not a true Ajax request because it's much lighter than processing a full MediaWiki page request. The handler simply receives a UserID and Token, creates a User object from the ID and checks if the User token matches the passed token to ensure there's no forgery going on. If there's a match it returns the information for the user in JSON format, or an empty JSON object if either there's not a match or the request did not derive from the local host.

Issues

This method requires that both the wiki and the Wordpress are running under the same domain so that the Wordpress is able to access the wikis cookies. If they were under different domains, then a client-side Ajax request to the wiki domain would need to be added to obtain the cookies.

Another minor issue is that for the returnto feature to work (allowing the browser to redirect back to the Wordpress after login, logout or registration) the following conditions must be met:

  • The Wordpress must reside in subdirectory under the MediaWiki installation
  • The wiki must be using short urls, e.g. http://domain/ArticleTitle
  • The Wordpress subdirectory must start with an uppercase letter (since the MediaWiki returnto value is treated as an article title)

If any of these are not the case, then the default code will not allow the returnto feature to work properly, but a simple redirect feature can easily be added into the wiki's LocalSettings.php to get around this.

See also