miniBB users table information synchronizing with another PHP software users information

General Principles

General principles of authorization: you, as user, could be authorized by software reading cookie data. When you enter your login and password (saved in database's users table), it is saved some way in a cookie, and it is read every time when you enter pages, which determine your login/password identity. In most cases, cookie password is encrypted the same way as in database, so storing it in a cookie is secure. So:

• DATABASE: we store and read login/password here
• USER'S COOKIE: we store and read login/password there
• PHP SOFTWARE SCRIPT: we read the Cookie and compare it by what we have in Database

So, miniBB handles all of it: it allows to change default name of users' table, it allows to write specific procedure for reading and storing custom cookie, without desctructing the main script core, so you don't loose anything related to miniBB upgrades in the future.

General principles of synchronizing miniBB with another outside user's table are very simple:

1. You must have common miniBB table fields in your user's table
2. You must know authorization principles of the software, which is already using your table
3. You must have PHP skills and abilities to think logically
4. You must be able to use Notepad or some simple text editor

In this solution, I will explain, how miniBB could be integrated into WordPress Blog CMS. I would mention, that I am not the user of WordPress, and this was the first time when I have ever installed it.

So, I have downloaded and installed WordPress 1.5.1.2 "Strayhorn" on my test local server, http://localhost/wordpress/ and further, I will demonstrate, how WordPress could be known inside without additional knowledge of this software in general. Don't call it 'hacking' or 'hi-jacking', please. It is usual everyday practice for me.

Users Data Table

Obligate fields (fields keys) in database for miniBB are: "user_id", "username", "user_regdate", "password", "user_email", "activity", "user_viewemail", "user_sorttopics", "language", "num_topics", "num_posts". If they are not in database, you must add them and define in DB scheme. These fields are:

• user_id - integer auto_increment type; stores unique user ID
• username - varchar type, stores user's login (sign in) name
• user_regdate - datetime type, sign up date
• password - varchar type, stores encrypted user's password (in miniBB, it is encrypted via MD5() function)
• user_email - varchar type, stores unique email of the user
• activity - integer type (0 or 1) - identifies user's access to forums. If this values is set to 0, user's membership is disabled for some reason. 1 by default.
• user_viewemail - integer type (0 or 1) - if 1, user has allowed to show his email publically. 0 by default.
• user_sorttopics - integer type (0 or 1) - default sorting by latest replies or latest topics.
• language - char type, 3 letter index of forums interface language
• num_topics - integer type; number of topics user created
• num_posts - integer type; number of posts user created

Another fields just describe user's profile, and it is not obligate to insert them (but you can redefine them in DB scheme, of course, if your table uses another names for ICQ or website fiedds, for example).

I took a look at WP users table, and found the following:

• "username" is listed as "user_login"
• "user_id" is listed as "ID"
• "user_regdate" is listed in the same as miniBB datetime format, and the field named "user_registered"
• password is listed in md5 encoded format, in the field "user_pass"
• "user_email" is "user_email"
• "activity" - they have no such field there, also as "user_viewemail", "user_sorttopics", "language", "num_topics", "num_posts" - also no fields here; so I have added them to the end of table via SQL command:

This is what I have finally in database (click to view full-size MySQLFront screenshot):

Please, notice which indexes database fields have on the left. They begin with 0, and it is needed to calculate manually, which field has which index. "Determining fields" tool could help you in getting index numbers - just download this tool, put it in forums folder, and point to it from your browser. Knowing these indexes is necessary for

miniBB Installation and Configuration

I have created 'wp-forums' folder and prepared for installation miniBB RC3a release there. In general, you might take another later release. So, it looked like this:

Edit miniBB's setup_options.php, this is the main file, where ALL possible BBS options are written in; below, when I mention "you should edit this option" - I always mean, that this options is inside that file.

Set all primary options (database login, password, host, admin information etc.), as described in Manual, set $Tu='wp_users'; plus modify $dbUserSheme to this (as described in Manual, too):

$dbUserSheme and all variables define the most important tie-up with outside users table. It is an associative array of user profile, and variables which define some fields that could not be changed by user himself (f.e., ID). $dbUserSheme format contains non-changeable field index (you should left it as it is - it is built-in miniBB core), numerical index of table field (see database picture above), table field name in database (see database picture above), and also form field name in templates/user_dataform.html - a template, which is used for new signings up and profile editing. Usually, it is not necessary to change form-related data, because all users should be signed up via your own script. I'll explain it below.

I have also fixed indexes in lang/eng.php (language) file:

//$l_usrInfo[5]='ICQ';

(commented it) because it is seemed to me not so important field, for forums, and WP uses 0 if ICQ is not set, which miniBB will report as '0' without additional function, that's not very nice.

Notice the following:

1) We should turn OFF users registrations/profile editing in miniBB (they must do it via WordPress)

$enableNewRegistrations=FALSE;
$enableProfileUpdate=FALSE;

Also, remove links from templates/main_header.html ({ $l_menu[2] } and { $l_menu[5] }), which point to the registration and profile editing.

If you want to enable registrations also on forums themselves, then do the following:

• Set $enableNewRegistrations=TRUE;
• In templates/user_dataform.html force users to enter only necessary data (name, password, email and technical settings, remove another fields)
• After that, editing profile also will be available with primary options - set $enableProfileUpdate=TRUE;

Notice, that your users table structure must be planned, so it can handle all not-miniBB-related data automatically, specially on INSERT command. With WP, when user registers via miniBB, it becomes available also in administration list with no privileges.

2) Forgotten password function must be disabled - remove 'bb_func_sendpwd.php' file

Also, in templates/user_login_form.html, remove link to sending the password:

<a href="http://www.minibb.com/forums/index.php?action=sendpass">...</a>

3) For administrator of the site, we must use some user with ID=1 in users table. Wordpress already has the same principle: general admin is written as #1. But since miniBB authorizes admin in setup_options.php, we also need to write in administrative data here (in $admin_usr and $admin_pwd, also as in $admin_email). You must change administrative data each time you change it in WordPress - that's the only sad side of the story.

4) Do you need forums where only registered users could make posts? Then set the following:

$allForumsReg=TRUE;

Ready to go! I run miniBB installation, and it was successfully installed original forum software tables, except for... 'Creating table wp_users failed... (Table 'wp_users' already exists)' - and it is normal. I went to the admin panel and created a couple of test forums. I have posted a couple of new topics in these forums under admin account, and noticed, that my admin account in miniBB worked fine this time. So, table settings were correct! I did logout then, so my old cookie are not kept.

Going to the next step... the most broad step in this story!

User's Authorization

Most scripts are using the same principle for users authorization: they are setting cookie(s) with username and encoded password, then some way compare them with data in database. So, miniBB should use the same cookies, as your software. It should READ the cookie with the known name, value and host, and it should SET cookie with these known settings - so, they might be available both for miniBB and another software (WordPress, in our case). How to know, what are cookie values, if you do not know them by default? I have installed WordPress for the first time in my life, and had no time to get into code details. But you don't need to be advanced turbo-programmer, to catch this on the fly. Let's start.

First of all, I opened my Mozilla Firefox browser, enabled Cookies so they are asked for confirmation, and logged into Wordpress admin area with these settings. Mozilla has set 2 cookies:

wordpressuser_bbfa5b726c6b7a9cf3cda9370be3ee91 with value 'admin'

and -

wordpresspass_bbfa5b726c6b7a9cf3cda9370be3ee91 with value 'cde7c072d47f762128f0eaa05d2e69b9'

on path '/wordpress/'.

If you are in doubt, how your site sets cookies, Mozilla's feature is the best way to look into it.

It is clear, that one cookie stores username, and second - hashed password, and the script some way handles checking of these cookies. The same miniBB does.

For reading these cookies correctly, we need to imagine, how the WordPress sets them. I have run deep through out the Wordpress scripts, trying to find how the cookie is set.

My favourite Total Commander file manager contains very useful utility for searching the text inside the files:

I will mean it everywhere, where I say "searched for" or "looked for" within the files.

I have searched by PHP function 'setcookie' in WP files, and found the function wp_setcookie, which sets cookie this way:

It was exactly I needed - so, WordPress is using this function for setting cookies. It was clear with $username, so I have searched for $password and found this in the same function at above code:

$password = md5( md5($password) ); // Double hash the password in the cookie.

So, I knew at this point, how WordPress stores VALUES of the cookies.

But what is $cookiehash? It is appended to the each name of the cookie. Searching for it, I have found:

$cookiehash = md5($siteurl);

Searching by $siteurl, I have found nothing. So, probably, it was some automated setting. I haven't noticed on Install, that WordPress asks me to enter it; so it was some way got from another source. I have searched then for 'siteurl' without buck symbol, and found the function 'get_settings'. SQL Request was inside:

So, WordPress is saving its settings in the database, in the table called 'wp_options' or whatever prefix of the tables is set. I thought, that if WP haven't asked for 'siteurl' setting - then it calculated it somehow. And it was via installation! I looked for '$wpdb->options', instantly checking for INSERT statement, and found functions.php with the function 'add_option'. So ONLY it was used for inserting options in database.

I have looked for 'add_option(' and found in upgrade-shema.php, that $guessurl was the correct value for this setting. Searching by it, I have found:

So, in theory,

$guessurl = 'http://' . $_SERVER['HTTP_HOST'] . dirname($_SERVER['PHP_SELF']);

I quickly programmed this:

echo md5('http://' . $_SERVER['HTTP_HOST'] . dirname($_SERVER['PHP_SELF']));

and it gave me exactly what I wanted, the $cookiehash 'bbfa5b726c6b7a9cf3cda9370be3ee91'.

So, by this time, I knew how WP sets its cookies with default settings. Probably, you may also set different prefix instead of 'wordpressuser_' or 'wordpresspass_', but I am not sure that all users are doing it. In general, software must be secured enough to work with the defaults settings.

The same way I have found the path:

define('SITECOOKIEPATH', preg_replace('|https?://[^/]+|i', '', get_settings('siteurl') . '/' ) );

So, this cookie should be available from the all sub-directories of WP - and the cookie reading seemed to me more easier for now!

First of all, miniBB cookie should use the same cookie path; so in setup_options.php, I have added exactly the same path as it was set in Mozilla:

$cookiepath='/wordpress/';

Probably, you will have something another here, but by the same principle.

I checked forums admin login, it worked ok this time.

Further, I needed to identify myself both from the admin's area and wp-forums at the same time.

In miniBB, bb_cookie.php module stores all authorization, so I was free to edit it without loosing upgrade possibilites of further miniBB cores. You may get ready example of this code in the "Synchronizing miniBB and WordPress" solution in our "Downloads" section.

For storing WP's cookie hash, it was not good to use $quessurl defined from http_host and dirname of php_self - because dirname was another for miniBB forums. So, I have created the following at the very top of bb_cookie.php:

just taking this setting from general WP's table settings.

Let's take a look at the getMyCookie() inside this file:

Some way, it is needed to send to miniBB array of cookie's username, password and re-setting time. Re-setting is rare function used in miniBB; WP does not use it. So we just need to give back only username and password:

Further, we need to identify user by these cookies in user_logged_in() function. miniBB does it the following way in two parts:

1. Checking ADMIN by admin's login and password, specified in setup_options.php - and identifying the admin
2. Checking MEMBER by data in users' table.

It is easy with admin - just add double md5 hashing to the admin's authorization. Hopefully, mySQL has built-in md5 function, so it is easy also to compare cookie's value with md5(user_pass) in database. Also, we need to remove expiration time setting - it is at very bottom of the function:

We need also to add some code to deleteMyCookie():

and setMyCookie():

so users also might login and logout on forums themselves, not just from WP. But sometimes, it is not needed at all - it is enough just to identify the users, not giving them rights to log-in or log-out. For this, you need to make a WARNING on your forums, that only registered and logged users could make posts. For example:

1. Empty file located at templates/user_login_form.html (delete all content inside it)
2. Make templates/user_login_only_form.html like this:

   <table class=tbTransparent>
   <tr>
   <td class=tbTransparent>Please, register and/or login to our forums first!
   </td>
   </tr>
   </table>
   

3. Remove {$l_menu[6]} from templates/main_header.html

So, it would be cool to have some kind of link to WP forums now! :-) It depends only on you - where you will put it on the page. Guess, I don't need to explain, how to insert HTML tag.

Finally, in the solution files, you will find all necessary files which you need to replace in miniBB RC3a or later:

• bb_cookie.php
• my default setup_options.php (don't replace it - just study it, if necessary)
• user_dataform.html

If you are the author of another CMS/authentification system, you are welcome to design your own miniBB solution and send it back to us for publishing on our site and promoting your product.

If you have more questions about synchronizing miniBB with outside users table, or if my explanation is not enough, contains errors, mistakes etc. - visit our special related forum thread and post your questions here.

Thank you for choosing miniBB forum software! :-)