Home Features Requirements Demo Downloads Compiler Manual Forums
Showcase Gallery of Arts Paid Extensions Paid Support License
miniBB synchronizing with the existing membership
By Paul Puzyrev, author of miniBB
Notice: description below is prepared only for the coders familiar with PHP. If you are not familiar with PHP and do not know much about web programming and coding, this article IS NOT FOR YOU. If you have read this solution, and tried it, and still something is not working on your side - we can't investigate it for free, because each system has its own specifics which we may not even know about, and this requires a lot of time to work on. miniBB authors are providing only paid support on synchronizing miniBB with a specific software. The same applies to project owners who have not enough time to go deeply into this solution, but need to synchronize your PHP software with miniBB as soon as possible. Contact us privately to get in touch.
This article describes the following:
Not depending on the type of the software, the language its written on or other terms, the basic principle of the web authorization is similar in almost all cases:
Let's take a look at the following schema:
As you see, we can call Cookie "part of the browser", "Comparison script" is part of the server, and since the Browser and a Server interact, that way we can save user's input and either enable or disable members-only functions for him.
Since the cookie is stored in the "clear" format on your computer and may be theoretically stolen, it is recommended to keep the Value of the Cookie in encoded format. This means even if you steal the cookie and know its Value, it doesn't mean you can log-in with this data, since it doesn't contain username and password in unencoded strings. That way the "good" authorization process works.
There were many questions on our forums regarding how difficult is to use sessions instead of cookies and how this affects security. Basically, PHP session means a cookie itself. Named usually 'PHPSESSID', this cookie contains a randomly generated session ID which is kept on the Server. This ID is associated on the Server with the special array of session data which may contain almost anything, incl. username, password, member ID and other information. For keeping user's authorization, it is usually needed only to open a PHP session and put authorized data under it with the built-in PHP session functions. This session always expires when you close the browser, that is the main difference between it and a "classic" cookie which may be kept for the specified amount of time. It is impossible to steal user's information from a PHP session (it is stored on the Server), but still, it's possible to recognize a user by session ID which is stored both on the Server and in the Browser.
If we take the above graph, "Comparison script" will stand for miniBB itself, specially, the files named bb_cookie.php and bb_func_login.php.
bb_func_login.php works only with the initial user's input, i.e. when the username and password are entered on the login form and passed for validation. This file is core-destructive, it means modifying this file you destroy possibility of the easy miniBB upgrade in the future, because if this file will be included in updates list, you will need to re-apply your changes again. In miniBB project, we always follow the non-core-destructive solutions, that means applying a solution, you still keep the possibility of the easy core files upgrade, but keeping all of your custom changes, incl. custom authorization mechanism.
Here we have a non-core file named bb_cookie.php, which means you are allowed to edit it without limitations and difficult upgrades fear. It contains cookie-processing functions as one for setting the cookie (setMyCookie), for deleting the cookie (deleteMyCookie), for getting the Value of the cookie (getMyCookie), encoding the password for storing in database (writeUserPwd), and the main function which compares user's cookie/input with database information (user_logged_in).
Taking into attention written above, let's explore some details:
The most important thing to know here is that user is authorized in miniBB if his ID is not equal to 0. In the scripts user ID is always associated with the $user_id variable. It is set under bb_func_login.php (for example when you post and login simultaneously) or user_logged_in function.
It is not even safe to drive by a car, what can we say about MD5? In theory, it can be hacked and broken, but only for really weak passwords, which consist of a sensful word or very simple phrase. As more your password is difficult-to-guess as less it's possible to decrypt it from MD5. In hacking practice, it is only possible using "brute force attack" which may take few lifes. Keeping miniBB forums for years, we still have our passwords safe, because they are strong. That's why the forums were still not broken. We still have read that somebody broke the forums, where the admin's password was... 'admin'. It's sad and funny at once. Of course there is no responsibility for such cases.
On another hand, forums are not the payment gateway and they do not contain any kind of serious private information. Even if somebody gets your password, he can't do anything except posting under your nickname or optionally delete few of your own messages. Even if somebody steals your admin password, it is always possible to restore forums from a backup. Another words, when working on miniBB authorization, we didn't invent anything difficult, like it is done recently for other similar software. This keeps the things transparent and still strong, if you know how to make them strong.
You can rewrite miniBB's writeUserPwd using another encoding algorithm here, let's say SH1 (thus changing password's length in database). That will keep the things more secured and still simple. This function is described below.
Few programmers are going wrong way trying to store user's information in TWO database tables, one of them belongs to the website authorization, and the other belongs to forums. For example, when user registers on the main page, his data is duplicated to the forums table as well; however it's definitely a wrong approach, 'cause in that case it won't be possible to achieve the user is logged on forums automatically when he's logged on the site. Users will just enter the same data for the main website and forums, but it won't make their live easier at all.
Synchronizing miniBB means there will be only ONE membership records table, and this table will belong exclusively to the main software. I.e. users are allowed to register and modify the profile only from the main software; forums will just READ this information, but not to create or update it. It means you can log-in from the main site, and you will appear logged in on forums; moreso - in some cases it's even possible to achieve that if you are logged-in from forums, you will be logged in from the main website automatically. That's the main sense of the best synchronization.
When it comes to synchronizing miniBB and other software, the most important question is: how to let your own script think that user is logged in from miniBB, and how to let miniBB think that user was logged in from your main website? Take a look at the picture above again: important are just Cookie and Comparison script.
If you know what kind of format your cookie has, and how to "emulate" it with miniBB, you've got the half-work done. Further, you need to build a Comparison script, i.e. rewrite miniBB's bb_cookie.php functions, so they are connecting to the existing users table, not default miniBB's table, and comparing user's input based on this table.
As about the Cookie information, Mozilla Firefox browser provides some excellent tools. Go to "Tools" - "Options" - "Privacy" - "Show cookies". It will list all cookies available for the Browser. Locate your domain, and under it you may see a specific Cookie by name. Cookie explores with the all necessary information mentioned above: Name, Value (Content), Expiration date, Path and Host (Domain). Analyzing this information, you may understand how the 3rd party program sets the login Cookie, and repeat it similarly in miniBB, rewriting some functions.
But first of all, you should know in advance, is miniBB compatible with the software you are going to synchronize it with? miniBB will be compatible only if:
Besides of that, miniBB requires the following fields in users table:
Fields marked with asterisk above most probably will exist in almost every members table. Other fields must be added to the end of the table manually. Fields may have different names, which can be re-defined under miniBB's setup_options.php - $dbUserShema setting. I'll explain it more carefully below.
Below we will take a very simple example of user's authorization on the site which you can repeat on your own side and see how it works, creating files and pasting codes. I hope this example will be pretty straightforward to understand how to implement all this for your own script ;-)
Let's say we have an existing users table which can be created with the following SQL statement:
And here, we will insert few test records to this table:
Under main website, we have 3 scripts: first is an index file which contains a login form, second is the Comparison script which parses user login data and sets the Cookie (PHP session), and the third is kind of members-only area. Below are the codes for these scripts:
Try to re-create all written above on your main website, then try to login as 'Paul' with the easy-to-guess password 'xyz123' (easy-to-guess is still good for testing purposes only). I hope you can analyze these scripts as well and conclude that the authorization script compares user's input by what is stored in database. If such username/password combination is not found, it just redirects to the login form; if it's found, it starts a session and stores $_SESSION's array variables like 'auth' and 'ID', meaning this uses is successfully logged in. Later this is also compared when you enter 'members-only' area.
Now besides our 'main' script, let's install miniBB, for example, under subfolder 'forums' comparing to the root folder. Check miniBB manual for installation if you are not sure how to proceed. After installation, log-in to admin panel, create a test forum, and under this forum create some test topic to see everything works. Then under forums folder, put the script my_session.php with the following content:
After you "were logged" from the main my_index.php page in the root folder, point your browser to my_session.php. You should see that a PHP session is available, and it displays the values of 'auth' and 'ID' meaning username of the logged user, and his ID. It means we can read Cookie from forums folder, and you must be sure on it in all other cases. Usually, PHP session is stored for the whole domain with the path '/', that's why we don't have problems referrencing to a session from the sub-folder. In your own script, you always must keep in mind that it must set the domain-wide Cookie.
Now we actually go to the synchronization process itself.
You may download all above mentioned code examples in one package, clicking here. Use in your scripts at your own risk! I've programmed them in 10 minutes without taking security question in mind. They are just examples.
Ending the lecture...
Each software has its own principles of authorization, and here only your professional/educational level matters of how to achieve a good synchronization. It may take hour of work, and it may take days or even a week. In my experience I still didn't meet the software which is technically compatible with miniBB, but still can't be emulated because it has a terrific authorization algorithm which can't be decoded by a human mind. Everything can be integrated if it's compatible. Even if it's not possible to rewrite miniBB functions because 3rd party authorization is TOO strong (for example, it was the case when I synchronized miniBB and the recent version of WordPress), it's still possible to include 3rd party functions and use them in miniBB (you may check my outdated article on synchronizing miniBB and the older version of WordPress).
But complexity is just a private case, because mainly the integrations I did in the past are simple, as the web should be. Entertaining Internet is not a serious thing to worry about complex algorithms, the same miniBB is. Good luck in coding :-) and under our related topic on forums you may post additional questions to this article.
|What forum owners say about miniBB: There is a ton of forums I have tried that store their templates in the database. There is also a lot of forums that can't do any form of templates at all, horrible things. I like miniBB's use of templates, it is very easy as you can edit it the same way you would usually make a webpage, and you aren't forced to edit it through a browser which I find to be really really annoying. Jeremy, Australia|
|Copyright © miniBB.com 2001-2014. All rights reserved.|
miniBB® is a registered trademark. U.S.P.T.O. Reg.No. 3,297,743.
Unique Hits: / / 0
|Contact Us @|