Found this neat little feature in Pligg that allows you to easily add a link to Pligg. The simple code can be expanded so you can add a button to your webpage that allows it to be easily submitted to Pligg. It’s not world-shattering, nor is it an unusual feature to find.

However, if your a Redbrick Member you could add this piece of code to any of your webpages that would all you or another Redbrick user to submit it to Pligg.

Submit this to Redbrick Pligg!

If you want, you can replace “document.location.href” with an explicit URL. I guess what we really need is a icon for Redbrick Pligg!

I’m considering adding it to Planet Redbrick and Redbrick Wiki. Is it a good idea? I could package it up in a WordPress plugin but I don’t know how many Redbrick Bloggers use WordPress.

The same also applies for Game Crafter’s Guild’s Pligg, however this Pligg is specifically for Gaming and Roleplaying related content, and we don’t have an icon either!

Submit to Game Crafter’s Guild’s Pligg!

Related Posts:

• A thought-exercise: Redbrick “Web 2.0″
• Frustrating!
• Integrating Pligg beta 8.1.0 with WordPress 2.0.4 (v1.1)
• Integrating Pligg beta 8.1.0 with PubCookie
• A new look for thedeadone.net

I originally posted this on the Redbrick babble newsgroup. If you don’t know what Redbrick is, this entry will have little interest to you. However, I’m posting it here because I think it’s interesting and also I’m hoping that it might filter out to some of the other Redbrick users who don’t use the newsgroups.

I’ve recently setup Pligg for Redbrick. It’s only available to Redbrick users and you can only login with your Redbrick user name and password, thanks to the power of PubCookie. I only did this as a demo. I wanted Pligg for something else, but a few people have started using it.

Anyway, because of that some users had suggested Redbrick’s services are not very well integrated. There all little distinct bits and bobs, not really connected or talking to each other. i.e. There not “Web 2.0″. Now I think “Web 2.0″ is one of those bullshit phrases, however, the idea of integrated services much like MySpace is an interesting idea and I started thinking, a thought-exercise if you will. Here is how I would see Redbrick becoming “Web 2.0″…

BTW Any software I suggest is only because I’m familiar and have in some capacity setup, hacked or modified. I’m not saying they are the best in class, only that I know what can and can’t be done with them.

Backwards Compatibility

Forget it. The first thing to do is, get rid of the newsgroups. Why? Well any new service setup has to integrate with the newsgroups or worse… synchronise in some fashion. This is never well done and discourages use of the new service as people revert back to what works. Also, because it’s a set of newsgroups, readable via only an archaic text browser, it’s impossible to take advantage of the many new web-based applications (like Pligg) and integrate them to give a complete feel. You can’t extend newsgroups with new features!

Also our newsgroups do not archive and do allow us to reference a post in other software. A big pain if you want to integrate with something like Pligg and allow people to submit their “posts” for voting, for example. (On the flip-side it means there is nothing to save making it easier to ditch).

Then there are the inevitable comparisons. “This software sucks because it doesn’t do XYZ feature in SLRN”. I’ve heard arguments in the past in a different community on a mailing list from people who stubbornly didn’t want to have a web forum, cries of “splitting the community!” and that email is so much better than using a web interface. Do you see me shedding any tears? And there is also the social aspect to consider, people use it because they know it and everyone else is using it. Until the majority stop using it, the majority won’t move.

I’ll come to “hey” in a minute…

I’d like to point out that I’m not advocating that Redbrick does this, only that this is probably what is needed to “move forward” into Web2.0. I don’t think Redbrick would need to get rid of all its technical
services like shell access, user webspace, vhosting, etc. to do this either. Both can easily live side by side.

Now that we can start with a clean slate, what should Redbrick 2.0 do?

Now What?

The boards formed the social centre point for the users of Redbrick software. So to replace the newsgroups, we need a web forum. One that’s extendable, hackable and just plain cool. My personal preference is for Vanilla (http://getvanilla.com) which is a very nice looking piece of software and is certainly not like phpBB. We need to be able to easily extend the software and I’ve played with Vanilla and it’s quite easy to extend. It’s built on adding “extensions” and has extensions for RSS feeds, permalinks, signatures, bookmarked discussions, blocking categories, threads and users, etc. I haven’t tried integrating it with Vanilla but I’m pretty confident it can be done.

BTW It does have a spell checker plugin. This uses GoogleSpell, however it won’t work on Redbrick because it won’t work through the proxy with https. We’ll need to get curl installed on PHP to do it.

Now we can start integrating the other services. Let’s start with Pligg. To integrate with the Vanilla forum, we need to make a “virtual” category that actually submits a story to Pligg. A simple approach would be to create a theme for Pligg that matches the forum and then create an extension for Vanilla that shows Pligg has a category. Submission and voting would be still via Pligg.

With the Wiki, it depends on the level of integration we want. MediaWiki is a monster of a piece of software. Modifying the look and feel is a headache. The most basic integration would be that the “Talk Pages” actually go to discussions on the forum. This could be just redirection or something more integrated. I don’t particularly like the idea of importing Wiki entries from discussions posts or threads (or vice versa) but you could easily write an extension to autolink to Redbrick Wiki entries and there is a Wiki markup plugin available for Vanilla.

As for Planet… well Planet is good for the combined Redbrick Blogs feed. The best thing to do is have entries in Planet submitted as new stories to Pligg. The interesting ones get voted up and become “published”. It is questionable though if you want to provide users with web services like blogs, if they should be automatically submitted to Planet and Pligg or should it be an opt-in/out like service.

Chatting

“Hey”: the other corner stone of Redbrick. It’s great now that Redbrick has a Jabber server. Why do we need Hey? For the same reasons as the newsgroups, why do we need to have a Jabber to Hey service?

I think people would need to start using Jabber more, in fact exclusively. Jabber and some magic web coding could be the greatest replacement for Hey. Like Gmail, when you’re browsing the new Web2.0 Redbrick forum, signed in to Pligg or the Wiki, you could have a “chat” window popup when someone tries to talk to you. It would be nice that you can also use Jabber to “hey” someone who happens to be logged in using a shell.

As for IRC and chat services… well, em, I don’t really use them too much. I leave that up to someone else.

Tagging

“Tagging” stuff on Redbrick would be the big thing or the most challenging. Tags can be just superficial and give a nice visualisation/”tag cloud” of Redbrick or they can be useful like in Flickr where people use tags to group stuff.

You need some sort of API or service that would allow Redbrick users to freely add and remove tags from any forum thread, wiki page, pligg entry and possible from user’s webpages and blogs. I’m sure it can be done but it’d need some thought.

Making it look the same

I think this is a pretty major and important thing. If the services are integrated, they need to look the same. However this isn’t challenging. It’s just a lump of work that someone would have to do.

Frontpage or rather, bringing it all together

Yea. Redbrick Frontpage. If we’re going to have all these services really tightly integrated, the frontpage is the place to bring it together. This isn’t just “links” but rather a summary of the latest Wiki pages, new forum threads, published pliggs, etc. But that’s not all though, I mean if you’re like me, you’ll pick and choose the RSS feeds you want and never have to visit the Redbrick frontpage.

The frontpage has to encourage discussion, commentary, etc. In a sense, it should be more “blog” like. News should have comments and trackbacks so we know Redbrick bloggers are interested. It should have an RSS feed as basic! Podcasts and guest blog entries from Redbrick users. Rants from Associates, etc. Moderated by the current committee/admins. A sort of “best of Redbrick”, kind of place.

Conclusion

Why bother? Everything works well enough for us now.

Related Posts:

• Who reads this blog anyway?
• Add a “pligg it” button to your webpage!
• Frustrating!
• Integrating Pligg beta 8.1.0 with PubCookie
• Dubliners and “Blow-ins”

I’ve managed to get Pliggto use WordPress authentication and user database. You can see it running on the Game Crafter’s Guild website.

I recently got Pligg using Pubcookie and that formed the basis of this work, however they are very different.

I’ve only tested this with Pligg Beta 8.1.0. I believe future versions may have a better approach for external authentication so I can’t guarantee this will work with future versions.

This approach is very “hacky”. I’ve also been slightly lazy. It assumes that you will use WordPress’ login, logout and register pages. This will break the existing login, logout and register forms in Pligg. The ultimate solution would allow the Pligg forms to login and logout also on WordPress and the register form to create new users in WordPress.

It also does not attempt to merge the user databases from WordPress and Pligg together. Instead they are left seperate. This means that administrators have two places to manage users. If you want to delete a user, you’ve got to delete them from WordPress and Pligg seperately.

I’ve done previous external application integrations with WordPress, most notable with DokuWiki. In these previous case, I was able to allow the use of WordPress template tags in DokuWiki. However, in the case of Pligg, it is not possible as there are several function name clashes. Pligg and WordPress are considered CMSs (Content Management Systems) and it is inevitable that function names and variables clash.

Version History

1.1 (19/10/2006)

Stray header redirection in login.php removed.

1.0 (17/09/2006)

First Release

Installation locations

The first thing to do is decide on where you will install Pligg and WordPress. Pligg must be installed in either a directory on the same level as WordPress or a subdirectory of WordPress. In my code examples, I’ve installed WordPress and Pligg on the same level. I will refer to the WordPress directory as “wp” and Pligg as “p”. So, for reference, I have Pligg and WordPress installed like this:

/public_html/wp
/public_html/p

Equally valid would be:

/public_html/wp
/public_html/wp/p

Pligg and WordPress should be part of the same domain. Otherwise the WordPress cookies won’t be picked up by Pligg.

Installing the software

Install WordPress normally and configured it how you will. Make sure it’s all working. Make a not eof your database prefix and site url. You can get your database prefix from ‘wp-config.php’. It is the ‘$table_prefix’ variable. Your site url (or URI if you want to be pedantic), is where you access WordPress from. You can get the exact value from your “Options”, “General” panel when you log in to WordPress as admin. Your site url should have no trailing slash. It is important you get this right as you won’t be able to log in to Pligg later otherwise. For example, if you install into a different directory, then your webpage’s url will be different from your WordPress url.

Now install Pligg, but use the same database. Make sure everything is working, in particular that you can log in using the “god” account.

Modifying Pligg

All the work to modify Pligg takes place in ‘libs/login.php’. What we want to do is get Pligg to login using WordPress cookies/authentication. If the user doesn’t yet exist in Pligg, create it. Also, copy over all the existing user data to the Pligg database. We won’t be using Pligg’s login, authentication or logout any more.

However, we can’t just include wordpress and call wordpress functions. Instead, we’re going to have to do it manually. What I’ve done is added a function called is_user_logged_onto_wp(), which does all the extra work.

Here is the modified ‘libs/login.php’. Make sure to correctly set the $wp_db_prefix to your database prefix (including the underscore) and $wp_siteurl to your WordPress url.

< ?php
// The source code packaged with this file is Free Software, Copyright (C) 2005 by
// Ricardo Galli .
// It’s licensed under the AFFERO GENERAL PUBLIC LICENSE unless stated otherwise.
// You can get copies of the licenses here:
// http://www.affero.org/oagpl.html
// AFFERO GENERAL PUBLIC LICENSE is also included in the file called “COPYING”.
// Modified by Mark Cunningham
// (http://thedeadone.net). Log in using WordPress
// WordPress path (you don’t really need this)
//if(!defined(‘WP_ROOT’)) define(‘WP_ROOT’, mnmpath.’/../wp/’);
//
// Can’t do this, sadly as “get_permalink” collides in both code bases.
// Must do everything manually!
//require_once WP_ROOT.’wp-config.php’;
$wp_db_prefix = “wp_”;
$wp_siteurl = “http://www.myblog.com/wp”;
// Generate cookie keys!
if( !defined(‘WP_COOKIEHASH’) ) {
// this value should be the same as siteurl
$cookiehash = md5($wp_siteurl);
define(‘WP_COOKIEHASH’, $cookiehash);
}
if ( !defined(‘WP_USER_COOKIE’) )
define(‘WP_USER_COOKIE’, ‘wordpressuser_’. WP_COOKIEHASH);
if ( !defined(‘WP_PASS_COOKIE’) )
define(‘WP_PASS_COOKIE’, ‘wordpresspass_’. WP_COOKIEHASH);
// TODO: storing copy of password in pligg?
class UserAuth {
var $user_id = 0;
var $user_login = “”;
var $md5_pass = “”;
var $authenticated = FALSE;
function is_user_logged_onto_wp(){
global $db, $wp_db_prefix;
// Most of this stuff I’ve taken (and modified) from WordPress codebase
// Do we have a username and password?
if ( !empty($_COOKIE[WP_USER_COOKIE]) && !empty($_COOKIE[WP_PASS_COOKIE]) ){
$wp_username = $_COOKIE[WP_USER_COOKIE];
$wp_password = $_COOKIE[WP_PASS_COOKIE];
// Does the user exist in wordpress?
if(!$wp_user = $db->get_row(“SELECT * FROM “.$wp_db_prefix.”users WHERE user_login = ‘$wp_username’”)){
// User doesn’t exist in wordpress… so…
// … should I delete this user in Pligg?
echo “This user $wp_username does not exist in WordPress!
“;
return false;
}
// Grab data for user
$wp_userdata = $db->get_results(“SELECT meta_key, meta_value FROM “.$wp_db_prefix.”usermeta WHERE user_id = ‘$wp_user->ID’”);
if ($wp_userdata) {
foreach ( $wp_userdata as $meta ) {
@ $value = unserialize($meta->meta_value);
if ($value === FALSE)
$value = $meta->meta_value;
$wp_user->{$meta->meta_key} = $value;
// We need to set user_level from meta, not row
if ( $wp_db_prefix.”user_level” == $meta->meta_key )
$wp_user->user_level = $meta->meta_value;
}
}
// Check if username and password are valid!
if ( md5($wp_user->user_pass) != $wp_password) {
// bad password!
echo “Bad password in cookie for $wp_username!
“;
return false;
}
// Okay, user exists and _is_ logged into wordpress!
// check if user exists in pligg!
$ok = 1;
// if a user doesn’t exit… create the user
if(!user_exists($wp_username)){
$userip = $_SERVER['REMOTE_ADDR'];
$ok = $db->query(“INSERT INTO users (user_login, user_email, user_pass, user_date, user_ip) VALUES (‘$wp_username’, ‘$wp_user->user_email’, ‘password’, now(), ‘$userip’)”);
}
// if user creation was okay or user was already created, sync and log in
if($ok) {
// grab pligg user data
$user=$db->get_row(“SELECT user_id, user_pass, user_login FROM users WHERE user_login = ‘$wp_username’”);
// Copy user data from wordpress!
$sql = “UPDATE users set “;
// admins should be set as “god” in pligg. What other levels should be mapped?
if($wp_user->user_level >= ’10′){
$sql .= “user_level=’god’, “;
} else {
$sql .= “user_level=’normal’, “;
}
$sql .= “user_date=’$wp_user->user_registered’, “;
$sql .= “user_url=’$wp_user->user_url’, “;
$sql .= “user_aim=’$wp_user->user_aim’, “;
$sql .= “user_yahoo=’$wp_user->user_yim’, “;
$sql .= “user_gtalk=’$wp_user->jabber’, “;
$sql .= “user_email=’$wp_user->user_email’ “;
$sql .= “WHERE user_id=$user->user_id”;
// there are other fields in pligg that don’t exist in wordpress.
// Just ignoring them for the time being.
$db->query($sql);
// These are required for login to Pligg
$this->user_login = $user->user_login;
$this->user_id = $user->user_id;
$this->authenticated = TRUE;
$this->md5_pass = md5($user->user_pass);
$this->SetIDCookie(1, false);
// Oh, don’t forget to log the ip!
$lastip=$_SERVER['REMOTE_ADDR'];
mysql_query(“UPDATE users SET user_lastip = ‘$lastip’ WHERE user_id = {$user->user_id} LIMIT 1″);
mysql_query(“UPDATE users SET user_lastlogin = now() WHERE user_id = {$user->user_id} LIMIT 1″);
// All good!
return true;
}
else
{
echo “Problem creating user in Pligg!
“;
}
}
else
{
//debug
//echo “No wordpress user found!
“;
}
return false;
}
function UserAuth() {
global $db;
// Are we logged into wordpress?
// Don’t do anything unless we are!
if($this->is_user_logged_onto_wp()){
if(isset($_COOKIE['mnm_user']) && isset($_COOKIE['mnm_key']) && $_COOKIE['mnm_user'] !== ”) {
// Si ya está autentificado de antes, rellenamos la estructura.
$userInfo=explode(“:”, base64_decode($_REQUEST['mnm_key']));
if(crypt($userInfo[0], 22)===$userInfo[1]
&& $_COOKIE['mnm_user'] === $userInfo[0]) {
$dbusername = $db->escape($_COOKIE['mnm_user']);
$dbuser=$db->get_row(“SELECT user_id, user_pass, user_level FROM users WHERE user_login = ‘$dbusername’”);
if($dbuser->user_id > 0 && md5($dbuser->user_pass)==$userInfo[2]) {
$this->user_id = $dbuser->user_id;
$this->user_level = $dbuser->user_level;
$this->user_login = $userInfo[0];
$this->md5_pass = $userInfo[2];
$this->authenticated = TRUE;
}
}
}
// Logout of Pligg if not logged in to wordpress
} else {
$this->user_login = “”;
$this->authenticated = FALSE;
$this->SetIDCookie (0,false);
header(“Cache-Control: no-cache, must-revalidate”);
header(“Expires: ” . gmdate(“r”, time()-3600));
}
}
function SetIDCookie($what, $remember) {
switch ($what) {
case 0: // Borra cookie, logout
setcookie (“mnm_user”, “”, time()-3600, “/”); // Expiramos el cookie
setcookie (“mnm_key”, “”, time()-3600, “/”); // Expiramos el cookie
break;
case 1: //Usuario logeado, actualiza el cookie
// Atencion, cambiar aqu?cuando se cambie el password de base de datos a MD5
$strCookie=base64_encode(join(‘:’,
array(
$this->user_login,
crypt($this->user_login, 22),
$this->md5_pass)
)
);
if($remember) $time = time() + 3600000; // Lo dejamos v?idos por 1000 horas
else $time = 0;
setcookie(“mnm_user”, $this->user_login, $time, “/”);
setcookie(“mnm_key”, $strCookie, $time, “/”);
break;
}
}
function Authenticate($username, $pass, $remember=false) {
global $db;
$dbusername=$db->escape($username);
$user=$db->get_row(“SELECT user_id, user_pass, user_login FROM users WHERE user_login = ‘$dbusername’”);
$saltedpass=generateHash($pass, substr($user->user_pass, 0, SALT_LENGTH));
if ($user->user_id > 0 && $user->user_pass === $saltedpass) {
$this->user_login = $user->user_login;
$this->user_id = $user->user_id;
$this->authenticated = TRUE;
$this->md5_pass = md5($user->user_pass);
$this->SetIDCookie(1, $remember);
$lastip=$_SERVER['REMOTE_ADDR'];
mysql_query(“UPDATE users SET user_lastip = ‘$lastip’ WHERE user_id = {$user->user_id} LIMIT 1″);
mysql_query(“UPDATE users SET user_lastlogin = now() WHERE user_id = {$user->user_id} LIMIT 1″);
return true;
}
return false;
}
function Logout($url=’./’) {
$this->user_login = “”;
$this->authenticated = FALSE;
$this->SetIDCookie (0);
//header(“Pragma: no-cache”);
header(“Cache-Control: no-cache, must-revalidate”);
header(“Location: $url”);
header(“Expires: ” . gmdate(“r”, time()-3600));
header(“ETag: \”logingout” . time(). “\”");
die;
}
}
$current_user = new UserAuth();
?>
[/soure]

Now login to wordpress and go to your Pligg frontpage. You may have to reload, but you should be automatically logged into Pligg! Remember, don’t use Pligg’s login or logout any more. I’ll deal with what you need to change in the templates to handle that soon. If you use your wordpress admin account, you’ll have full ‘god’ mode in Pligg.

Final modifications

Your site isn’t fully secure yet. Delete ‘register.php’ so that no-one can create accounts using Pligg. We can also simply remove ‘login.php’ but lets not be so drastic. Lets modify ‘login.php. Look for these lines:

1
if($_POST["processlogin"] == 1) {
$username = trim($_POST['username']);
$password = trim($_POST['password']);
$persistent = $_POST['persistent'];
if($current_user->Authenticate($username, $password, $persisten$
$errorMsg=PLIGG_Visual_Login_Error;} else {
if(strlen($_REQUEST['return']) > 1) {
header(‘Location: ‘.$_REQUEST['return']);
} else {
header(‘Location: ‘.my_pligg_base.’/');
}
die;
}
}

We want to prevent hackers from using direct URLs to log in. So comment out the normal authentication test, as below.

if($_POST["processlogin"] == 1) {
$username = trim($_POST['username']);
$password = trim($_POST['password']);
$persistent = $_POST['persistent'];
if($current_user->Authenticate($username, $password, $persisten$
$errorMsg=PLIGG_Visual_Login_Error;} else {
if(strlen($_REQUEST['return']) > 1) {
header(‘Location: ‘.$_REQUEST['return']);
} else {
header(‘Location: ‘.my_pligg_base.’/');
}
die;
}
}

Pligg also comes preconfigured with one special user account, the “god” account. You can’t delete this account via the admin interface. You can create the “god” account in WordPress to prevent some user creating it and gaining “god” rights on Pligg. Or if you know sql or have access some sort of web access to your database, you can rename the “god” account to match the username of an existing admin user or delete the user outright.

Required Template Changes

So, now your WordPress users can log in on WordPress and then be automatically logged in to Pligg. But you’ve got to point the login, logout and register links to your WordPress equivelents. If your happy enough modifying the template then your ready to go. However, heres a run down of the minimal changes required to make sure it’s okay.

Lets create a copy of the existing template, mollio-beat. To do this, just make a copy of ‘templates/mollio-beat’ in ‘templates/’ (including all subdirectories). Make sure the permissions are correct, etc. I renamed this copy “gcg1″ (for Game Crafters Guild version1), so I now had a ‘template/gcg1′. I went into the admin interface in Pligg and under the Template configuration, changed ‘mollio-beat’ to ‘gcg1′ and disabled the option that lets users change the template. We don’t want users being able to go back to the old way of authentication.

We can’t use WordPress template tags. You can always write PHP and SQL code that access the data manually in your database if your that way inclined. This means we have to use direct links.

template/gcg1/header.tpl

Open up ‘template/gcg1/header.tpl’. Look for these lines:

{else}

Change them to:

Note: In my installation of Pligg, I’ve updated “my_base_url” (via the admin interface) correctly. I also have WordPress as a subdirectory of that same base url, so it became a handy shortcut to use ‘{$my_base_url}/wp’ to reference any WordPress links directly.

header.tpl controls the header of all the Pligg pages so these changes will make sure those login, logout and register links are fixed across the entire Pligg site.

template/gcg1/profile_center.tpl

‘template/gcg1/profile_center.tpl’ controls what users can modify in their profile. We’ll want to disable as much as possible of this as their profiles are overwritten from WordPress everytime they login.

Some where in the file, add this so users know where to modify their profile:

Please use this form to modify your profile.

Delete these lines. Users won’t be able to modify their passwords here, so remove the option:

{#PLIGG_Visual_Profile_ChangePass#}

Now we need to disable the fields that are copied over by wordpress. These are aim, email, yahoo, url and gtalk.

template/gcg1/story_center.tpl

‘template/gcg1/story_center.tpl’ controls the display of individual stories. If a non-logged in user, views a story, they will see a login and logout link!

Replace:

{#PLIGG_Visual_Story_LoginToComment#} {#PLIGG_Visual_Story_Register#} {#PLIGG_Visual_Story_RegisterHere#}.

With:

Login
Register

template/gcg1/sidebar/login.tpl

‘template/gcg1/sidebar/login.tpl’ is the sidebar login form you see. Replace it with this:

{#PLIGG_Visual_Login_Title#}

Register

Login

template/gcg1/sidebar/logged_in.tpl

‘template/gcg1/sidebar/logged_in.tpl’ is the sidebar panel you see when logged in. Replace the logout link:

{#PLIGG_Visual_Logout#}

With something like this:

{#PLIGG_Visual_Logout#}

I also add a link to the WordPress Admin panel for convience here.

Ready to go!

After all these changes, you should be able to login using WordPress only and be logged in on your Pligg page too! If you have any comments, feedback or find any bugs, just leave a comment here. Thanks.

Related Posts:

• Add a “pligg it” button to your webpage!
• Frustrating!
• Getting DokuWiki to use WordPress Authentication (v1.2)
• GCG… it’s alive!
• Where has TDO Mini Forms plugin gone?

I’ve managed to get Pligg to use Redbrick’s PubCookie to authenticate logins. For the moment, you can see it in action here. However, this was done for demo purposes so I don’t know if it’ll stay there forever.

I reused the approach that worked for integrating MediaWiki with PubCookie for our Redbrick Wiki. This was based on the work originally described here.

I’ve only tested this with Pligg Beta 8.1.0. I believe future versions may have a better approach for external authentication so I can’t guarantee this will work with future versions.

I’m assuming that you already have an existing and working pubcookie installation. The first thing to do is install Pligg. Get it up and running with it’s own authentication. Make sure you can login with the pre-created “god” account.

We’re going to need to modify the template quite a bit, so create a copy of the existing template, mollio-beat. To do this, just make a copy of ‘templates/mollio-beat’ in ‘templates/’ (including all subdirectories). Make sure the permissions are correct, etc. I renamed this copy “rb” (for Redbrick), so I now had a ‘template/rb’. I went into the admin interface in Pligg and under the Template configuration, changed ‘mollio-beat’ to ‘rb’ and disabled the option that lets users change the template. We don’t want users being able to go back to the old way of authentication.

Next, create a ‘custom_auth’ directory in your pligg directory.

Create a ‘login1.php’ with these contents in ‘custom_auth’. Make sure to replace ‘[url to your pligg install]‘ with the correct URL to your pligg directory. This file simply redirects the user to a pubcookie protected page.

< ?php

session_start();

//we don't want people accessing this page directly!
if (isset($_SERVER['HTTP_REFERER'])) {
//save the referrer so we can redirect back to the page they came from
$_SESSION['http_referrer'] = $_SERVER['HTTP_REFERER'];

//now send them off to the PubCookie protected login page
header('Location: https://[url to your pligg install]/custom_auth/login2.php');
}
else {
header('HTTP/1.1 403 Forbidden');
echo "This page cannot be accessed directly";
}

?>

Create a ‘login2.php’ with these contents in ‘custom_auth’. This page will be protected by pubcookie. The user will then login via pubcookie, be redirected back here and be logged into pligg. You can replace the “@redbrick.dcu.ie” in the email field to something that makes more sense for your setup.

< ?php

// Needed by Pligg

include_once('../Smarty.class.php');
$main_smarty = new Smarty;
include('../config.php');
//include(mnminclude.'html1.php');
//include(mnminclude.'link.php');
//include(mnminclude.'smartyvariables.php');

require_once "HTTP/Request.php";

//this script must be run behind some type of Apache user authorization
//fail immediately if it isn't
if (!isset($_SERVER['REMOTE_USER'])) {
die("The remote user variable is not set");
}

//get the login username
$username = strtolower($_SERVER['REMOTE_USER']);

session_start();

$redirect = $_SESSION['http_referrer'];
unset($_SESSION['http_referrer']);

global $db;

$ok = 1;
// if a user doesn't exit... create the user
if(!user_exists($username)){
// come up with some default email
$email = $username."@redbrick.dcu.ie";
$userip = $_SERVER['REMOTE_ADDR'];
$ok = $db->query(“INSERT INTO users (user_login, user_email, user_pass, user_date, user_ip) VALUES (‘$username’, ‘$email’, ‘password’, now(), ‘$userip’)”);
}

// if everything is okay…
if($ok) {
// log in!
$user=$db->get_row(“SELECT user_id, user_pass, user_login FROM users WHERE user_login = ‘$username’”);
$current_user->user_login = $user->user_login;
$current_user->user_id = $user->user_id;
$current_user->authenticated = TRUE;
$current_user->md5_pass = md5($user->user_pass);
$current_user->SetIDCookie(1, false);
$lastip=$_SERVER['REMOTE_ADDR'];
mysql_query(“UPDATE users SET user_lastip = ‘$lastip’ WHERE user_id = {$user->user_id} LIMIT 1″);
mysql_query(“UPDATE users SET user_lastlogin = now() WHERE user_id = {$user->user_id} LIMIT 1″);
}

//finally redirect the user back to his original page
header(“Location: $redirect”);
?>

Now create a ‘.htaccess’ file. This will make ‘login2.php’ protected by pubcookie. On my setup, to do this, I use this:

PubcookieAppID cpig1
AuthType pubcookie


       require valid-user

Now you need to modify your template to use this new login approach. Go into your template directory (in my case thats ‘template/rb’) and modify “login_center.tpl”. Add these lines near the top of tile and replace [url to your pligg install] with the correct URL to your pligg directory. This will cause all logins to redirect to the new login scripts.

< ?php
/* these lines added to enable pub cookie login! */
header("Location: http://[url to your pligg install]/custom_auth/login1.php");
exit;
?>

Now, open up your Pligg in a browser of choice. Assuming your not currently logged in, follow the login link at the top. You should now have to login using pubcookie. If login is sucessful, you should now be logged into Pligg.

However, you’ll want to give yourself admin powers. So login using your own pubcookie account so that the user account is created in Pligg. Now change the template from ‘rb’ back to ‘mollio-beat’. Hopefully now you should be able to login using the original ‘god’ account. Once logged in, change your pubcookie account to ‘god’ level. Nowe change the the template back to ‘rb’ (or whatever you called it).

People can now log into your Pligg using pubcookie. However, your site isn’t fully secure. Delete ‘register.php’ so that no-one can create accounts. We do not want to delete ‘login.php’ however as this does our ‘logout’. Instead we will modify ‘login.php. Look for these lines:

if($_POST["processlogin"] == 1) {
$username = trim($_POST['username']);
$password = trim($_POST['password']);
$persistent = $_POST['persistent'];
if($current_user->Authenticate($username, $password, $persisten$
$errorMsg=PLIGG_Visual_Login_Error;} else {
if(strlen($_REQUEST['return']) > 1) {
header(‘Location: ‘.$_REQUEST['return']);
} else {
header(‘Location: ‘.my_pligg_base.’/');
}
die;
}
}

We want to prevent hackers from using URLs to log in. So comment out the normal authentication test, as below.

if($_POST["processlogin"] == 1) {
/*$username = trim($_POST['username']);
$password = trim($_POST['password']);
$persistent = $_POST['persistent'];
if($current_user->Authenticate($username, $password, $persisten$
$errorMsg=PLIGG_Visual_Login_Error;} else {
if(strlen($_REQUEST['return']) > 1) {
header(‘Location: ‘.$_REQUEST['return']);
} else {
header(‘Location: ‘.my_pligg_base.’/');
}
die;
}*/
}

Your site is now ready to be used. However I would suggest some further template changes. These are not required to make your site work, but they do improve usablity for your members.

In the template file ‘header.tpl’, remove the line:

This will remove the “register option” from the top of the page.

In the template file ‘profile_center.tpl’, remove these lines:

{#PLIGG_Visual_Profile_ChangePass#}

This will remove the change password option from users profiles. It’s harmless, as the password is not used, but it could convince your users.

In the template file ‘sidebar_modules/login.tpl’, you may want to replace, pretty much everything in this file so that users don’t see a login form in the sidebar. This is what I put in it.

{#PLIGG_Visual_Login_Title#}

You can log in using your Redbrick
username and password due to the magic of pubcookie. Just follow the link
below.

{#PLIGG_Visual_Login#}

A final suggestion, in the admin panel in langauge configuration, I’d recommend changing all instances of “login” to “sign in” and “logout” to “sign out”.

Related Posts:

• Add a “pligg it” button to your webpage!
• A thought-exercise: Redbrick “Web 2.0″
• A new look for thedeadone.net
• Phew! Made it!
• thedeadone.net is back!