Navigation

Search

SMF MediaWiki integration released

Posted by SleePy on December 05, 2011, 11:40:48 PM

Simple Machines is proud to announce that we are releasing the integration used for the Simple Machines Wiki.  This integration has been adapted from the original by Ryan Wagoner.  Ryan's original work specified no license;  however he has been kind enough to give us permission to redistribute his work.  We have released this work under the BSD 3 clause license in hopes others may continue to improve this integration.

Our reasons for modification were quite simple.  First and most importantly, we wanted to reduce the required resources to make the integration compatible with a large, active forum. Secondly we attempted to improve the user integration to ensure protection of the accounts.

By protecting the account, we hope to avoid duplicate names by ensuring that they are not possible. As well we hope to be able to match wiki names to SMF user accounts using their account id from our SMF community forum.

The most important part was ensuring that the authentication would not demand too many resources.  We have improved the authentication to cache queries that the auth uses to communicate with SMF.  So far this has proved successful and kept our servers happy.

In addition, we have have improved the ability of the integration to add users to groups based on their access on SMF.  This has allowed users such as our translators to be automatically added to the appropriate translators group,  which greatly reduces work loads and reduces human error.

By releasing this authentication file, we hope to encourage others to use and improve our work and give back to the community.  We have chosen github because it makes it simple to allow anyone to fork the work, develop their own improvements and features, and submit pull requests for their changes.


You can find the SMF MediaWiki authentication at https://github.com/SimpleMachines/smf-mw-auth

Comments

wilowterra on December 06, 2011, 12:11:17 AM said
Great!!!
Kryzen on December 06, 2011, 04:48:56 AM said
Good news :) Still need to find out how it works though :P
Angelina Belle on December 06, 2011, 12:17:03 PM said
The README file tells you where to put the files, and which settings to use.
Just follow the instructions, and you'll be bridging your SMF and wikimedia immediately.
Paracelsus on December 07, 2011, 05:10:07 AM said
Nice!

Questions and Issues:

1. Does it work with SMF 1.1.x? I couldn't find any indication on this.

2. I doubt this bridge will be able to work with MW 1.18, since they've changed the hook $user->setupSession(); to wfSetupSession();. Maybe you'll want tho change this piece of code:
Code: [Select]
// Go ahead and log 'em in
$user->setupSession();
$user->setCookies();

3. Does this bridge accepts "strange characters" like á à § ç ã on the username? (the last bridge didn't accept them)
Joshua Dickerson on December 08, 2011, 09:01:51 AM said
It doesn't work with 1.1 AFAIK and we won't be making it work with it.

Thanks for the advice.

Nope.
SleePy on December 08, 2011, 12:27:50 PM said
1. Does it work with SMF 1.1.x? I couldn't find any indication on this.
It does not, I removed all support for SMF 1.1 in the code.  You are welcome to fork it and provide backwards capabilities though.  SMF 2.0 is the stable line while 1.1 is the obsolete.  We are still patching SMF 1.1 for security issues, but otherwise 2.0 is the main stable branch.

2. I doubt this bridge will be able to work with MW 1.18, since they've changed the hook $user->setupSession(); to wfSetupSession();. Maybe you'll want tho change this piece of code:
Code: [Select]
// Go ahead and log 'em in
$user->setupSession();
$user->setCookies();
Ok, I opened up an issue report on it.  When I get time, I will look into this: https://github.com/SimpleMachines/smf-mw-auth/issues/1
I think thats one of my notes I had wrote down though for upgrading our wiki to the new release.

3. Does this bridge accepts "strange characters" like á à § ç ã on the username? (the last bridge didn't accept them)
If MW supports it, the bridge should.  My memory from the time of setting up the wiki here, says that by default MediaWiki is using latin1 tables and not utf8.  So to support them you should just have to convert the wiki to utf8.
taniss on December 08, 2011, 01:00:04 PM said
Excellent news! Thanks for this  ;D
Paracelsus on December 08, 2011, 01:11:13 PM said
I don't think it's as simple as "just converting the wiki to utf8", since my wiki is 100% utf8 and it sitll doesn't accept those characters in the username (though I'm using the "old" bridge, so I don't know if it's a bridge or MW thing).

It's a pity that the bridge doesn't work for 1.1.x but I understand your point.
SleePy on December 08, 2011, 04:21:41 PM said
There shouldn't be to much work in getting to work on the older version.  Mostly if not all should be just changing the database fields to match SMF 1.1 fields.  I think all the other code should support 1.1 just fine.

I haven't heard any complaints from our international users about this.  However SMF I know makes sure to set the character settings when it first starts up.  So if it isn't working, its most likely because the connection to the SMF database is using latin and needs the query to tell it to read as utf8.  Something such as:
Code: [Select]
SET NAMES utf8

Would need to be ran after the connection to the SMF database is made.  I am not 100% sure though, my expertise in character sets is not the best :D
GravuTrad on December 08, 2011, 05:32:44 PM said
Supercool! Thanks!
Paracelsus on December 09, 2011, 03:30:30 AM said
There shouldn't be to much work in getting to work on the older version.  Mostly if not all should be just changing the database fields to match SMF 1.1 fields.  I think all the other code should support 1.1 just fine.

I haven't heard any complaints from our international users about this.  However SMF I know makes sure to set the character settings when it first starts up.  So if it isn't working, its most likely because the connection to the SMF database is using latin and needs the query to tell it to read as utf8.  Something such as:
Code: [Select]
SET NAMES utf8

Would need to be ran after the connection to the SMF database is made.  I am not 100% sure though, my expertise in character sets is not the best :D

This might seem a stupid question to you but... how do you change the database fields to match SMF 1.1? I mean, in a pratical way, since I don't know which ones were changed from 1.1 to 2.0 (do you guys happen to have any tool for this?).
Paracelsus on December 09, 2011, 04:00:10 AM said
Nevermind Sleepy, I suceeded with your tip about the "set names" to uft8 in the 1.1 compatible SMF_Auth. ;D

I used an example of a Wordpress + Mediawiki bridge where they used this:
Code: [Select]
mysql_query("SET NAMES utf8");
  mysql_query("SET CHARACTER_SET utf8");

and it worked quite ok when placing it after the query that does the connection to SMF.

Problem solved, many thanks! ;)
Study Force on December 10, 2011, 01:15:00 AM said
Had been waiting for this for ages, but now that I have bridged my own (and am quite satisfied), thanks anyways!

Excellent work.
Kraken on December 27, 2011, 03:49:01 PM said
I tried this bridge, but i am getting "password error" message every time i am trying to login from MW (the password is correct everytime btw, MW: 1.18, SMF:2.0.1)
live627 on December 27, 2011, 11:04:44 PM said
I created a new fork for SMF 1.1 compatibility: https://github.com/live627/smf-mw-auth
Study Force on December 29, 2011, 12:24:11 AM said
I created a new fork for SMF 1.1 compatibility: https://github.com/live627/smf-mw-auth

Very nice!
Eudemon on January 01, 2012, 12:03:32 AM said
amazing!
Paracelsus on January 03, 2012, 10:24:12 AM said
I created a new fork for SMF 1.1 compatibility: https://github.com/live627/smf-mw-auth

Can't make it work... I get a: "Unable to view external table." error.
SebaS on January 08, 2012, 08:25:46 PM said
don't work :(

Deprecated:  Call-time pass-by-reference has been deprecated in C:\Program Files (x86)\EasyPHP-5.3.8.1\www\wiki\extensions\Auth_SMF.php on line 265

i can't login in mediawiki. (the user don't exist)
Anthony` on January 08, 2012, 08:46:36 PM said
don't work :(

Deprecated:  Call-time pass-by-reference has been deprecated in C:\Program Files (x86)\EasyPHP-5.3.8.1\www\wiki\extensions\Auth_SMF.php on line 265

i can't login in mediawiki. (the user don't exist)

Since the function requests a reference as the argument, it shouldnt even be necessary to have the $user object passed by reference right from the function call.
Code: (Replace) [Select]
$wgAuth->isGroupAllowed($user_settings['member_name'], &$user);
Code: (With) [Select]
$wgAuth->isGroupAllowed($user_settings['member_name'], $user);
This is for PHP 5.3.0+ users by the way.
SebaS on January 09, 2012, 07:45:50 PM said
don't work :(

Deprecated:  Call-time pass-by-reference has been deprecated in C:\Program Files (x86)\EasyPHP-5.3.8.1\www\wiki\extensions\Auth_SMF.php on line 265

i can't login in mediawiki. (the user don't exist)

Since the function requests a reference as the argument, it shouldnt even be necessary to have the $user object passed by reference right from the function call.
Code: (Replace) [Select]
$wgAuth->isGroupAllowed($user_settings['member_name'], &$user);
Code: (With) [Select]
$wgAuth->isGroupAllowed($user_settings['member_name'], $user);
This is for PHP 5.3.0+ users by the way.

the same error.
Anthony` on January 09, 2012, 07:48:44 PM said
don't work :(

Deprecated:  Call-time pass-by-reference has been deprecated in C:\Program Files (x86)\EasyPHP-5.3.8.1\www\wiki\extensions\Auth_SMF.php on line 265

i can't login in mediawiki. (the user don't exist)

Since the function requests a reference as the argument, it shouldnt even be necessary to have the $user object passed by reference right from the function call.
Code: (Replace) [Select]
$wgAuth->isGroupAllowed($user_settings['member_name'], &$user);
Code: (With) [Select]
$wgAuth->isGroupAllowed($user_settings['member_name'], $user);
This is for PHP 5.3.0+ users by the way.

the same error.

Are you sure you saved the file and applied the change correctly? Is it giving the same line in the error? You are using PHP 5.3.0 or higher correct?
SebaS on January 10, 2012, 02:45:44 PM said
don't work :(

Deprecated:  Call-time pass-by-reference has been deprecated in C:\Program Files (x86)\EasyPHP-5.3.8.1\www\wiki\extensions\Auth_SMF.php on line 265

i can't login in mediawiki. (the user don't exist)

Since the function requests a reference as the argument, it shouldnt even be necessary to have the $user object passed by reference right from the function call.
Code: (Replace) [Select]
$wgAuth->isGroupAllowed($user_settings['member_name'], &$user);
Code: (With) [Select]
$wgAuth->isGroupAllowed($user_settings['member_name'], $user);
This is for PHP 5.3.0+ users by the way.

the same error.

Are you sure you saved the file and applied the change correctly? Is it giving the same line in the error? You are using PHP 5.3.0 or higher correct?

yes, the same line.

PHP 5.3.8
Apache 2.2.21
MySQL 5.5.16
Anthony` on January 10, 2012, 03:59:07 PM said
Sorry, I have no idea what the problem is then.
danielwmoore on January 19, 2012, 11:45:03 AM said
I've set up the LocalSettings.php per the instructions, removed the '&' from line 265 which fixed compatibility with my PHP 5.3.8, and the Wiki loads fine, however, I can't log in.  It redirects to an SMF login page, but I never get logged in.  I'm always a guest. 

I'm using MediaWiki 1.18.1 and SMF 2.0.2.
FireDitto on January 30, 2012, 02:36:01 AM said
Okay, I've been staring at this bloody README for hte past hour, and I *STILL* can't figure out how to do this.

Can someone please please help?

What am I adding, to where? How am I configuring things?

I just... Maybe it's simple and easy and I'm an idiot.

But I seriously do not understand.
Illori on January 30, 2012, 06:15:22 AM said
you would be best to start a separate thread in the proper support board, this thread is not for support.
nyall on February 05, 2012, 11:21:42 AM said
I'd like to contribute by expanding the README to include extra information that, for those like me far from being experts, may become useful. I am now figthing to make it work, and I can see I am not the only one, with no specific "central repository" for troubleshooting. Also there are a couple of mispellings. A FAQ section can be added to the bottom, or as a separate file.

I have submitted a pull request, hope you find it useful.
SleePy on February 05, 2012, 01:28:38 PM said
nyall,

I've looked and commented on your pull request.  I am sure most of it is confusion over the setup.  I am not the best one to write instructions on things and most of that was the original authors instructions.  Although the define does cause problems if the instructions where not read.

I am concerned about the first change suggested for problems though, that isn't the point of that code.  Something else is failing along the lines which is causing smf_member_id to not be retained in the wiki user options.  The code doesn't have the ability currently to correct bad smf_member_ids on accounts that exist.  Which may be why that coded failed if the SMF username was also Administrator and this is now conflicting with the wikis one.


It may be better to push off any long information into the readme and leave a big note at the top of the auth file to read the readme.


Thanks for the pull request though, I've been really busy lately with real life and haven't had any time to dig into the problems.
nyall on February 05, 2012, 02:02:26 PM said
Nothing to worry, you're doing great work and we all know how life works  ;)  It's me who should thank you   :laugh:

Saw your replies, many thanks for your comments and corrections. Feel free to modify my suggested "patch", or even completely discard it. It serves for me, and I'd be happy if someone else can benefit from it. I can do the modifications based on your comments by myself and re-submit, if you prefer.

I have a separate issue for support with the workaround that I have implemented for the authentication issue. I have no idea why this may be happening, but again I'd be more than happy to be of any assistance to identify why this happens. My original thread can be found here:  http://www.simplemachines.org/community/index.php?topic=467594.0 

Now the bridge is working, but based on your comments I don't realize the implications of the workaround I have implemented. I'd be much obligued if you can give me a little explanation on that, either via PM, the support thread or here.
SleePy on February 06, 2012, 01:04:40 AM said
I haven't tried it, but I wonder if you can make references to the pull request number to add to the issue.  Otherwise I will look into it later.
nyall on February 06, 2012, 02:43:14 PM said
I haven't tried it, but I wonder if you can make references to the pull request number to add to the issue.  Otherwise I will look into it later.

Sorry, don't know if that's too technical or if it is due to English not being my mother tongue, but I am not sure what do you mean with "make references to the pull request number to add to the issue. "   :-[
SleePy on February 06, 2012, 03:53:00 PM said
https://github.com/blog/831-issues-2-0-the-next-generation
http://stackoverflow.com/questions/1687262/link-to-github-issue-number-with-commit-message

Thats what I am referring to.  When you do that, any future commit notices are attached to that issue.  I don't know if it works on pull requests though.  If not oh well :)
Illori on March 18, 2012, 06:23:59 PM said
you would be best to start a separate thread in the proper support board, this thread is not for support.
Masterd on March 19, 2012, 04:32:20 AM said
Finally! I waited for this since this site's Wiki was released.
planet9 on March 25, 2012, 10:09:30 PM said
Today I've been trying to integrate MediaWiki, going through this thread to understand what is needed to make it work. And here I'm at the end of the thread with the impression that this integration does not yet work.

Does anyone have it working completely?  Is there a workable section for LocalSettings.php and Auth_SMF.php?

Thanks.
SleePy on March 26, 2012, 04:07:27 PM said
There has been discussion at the github issue tracker page about some problems people have been having.
I've heard reports but haven't confirmed that it doesn't work with MW 1.18 (and thus most likely 1.19).
planet9 on April 01, 2012, 02:16:10 PM said
My integration issue was a cookie problem.  The only problem I have now is that doing a wiki->login sends me to the forum after login and not back to the wiki.

As for the cookie issue there was nothing pointing me to this problem.  I didn't uncover it until I started outputting the cookie info.

Below is the cookie I was seeing:
a:3:{i:0;i:0;i:1;s:0:"";i:2;i:0;}

Auth_SMF.php unserializes it and there were no values in the variables id_member and password.

In order get a cookie like this:
a:4:{i:0;s:1:"1";i:1;s:40:"17f9832ca37464dc5ce25cffc408fefa1bfef908";i:2;i:1522519197;i:3;i:2;}

I had to turn off "Enable local storage of cookies".

These are my settings which work and integration works fine now:
SleePy on April 01, 2012, 03:28:55 PM said
As the note below that setting says, it doesn't work well with SSI.  What that setting does is fill out the path (ie /forum/) in the cookie so only that path can access the cookie.  By unchecking it, the cookie sets the path as /, which allows anything in that domain to work.  If you have subdomains you need to check the subdomains one.  That sets the wildcard (*) in the cookie for that domain.

I've updated the Auth file just now.  This one appears to work properly with MediaWiki 1.18


I'v also added your issue to the readmes FAQ section.  Hopefully that helps others in the future :)
planet9 on April 01, 2012, 03:40:43 PM said
I have only 2 remaining issues.  The most important is limiting the MW edit capability to only the SMF Admin group and a new "Wiki Editor" group; the SpecialGroups settings seem to have no effect.

The other issue is that from MW the logout link has no effect; the user stays logged in.

As the note below that setting says, it doesn't work well with SSI. 

That presumes one knows what SSI is and what it does.  Being new to SMF and MW, I wasn't very aware of it.

I've updated the Auth file just now.  This one appears to work properly with MediaWiki 1.18

I'v also added your issue to the readmes FAQ section.  Hopefully that helps others in the future :)
Excellent. Thanks.
SleePy on April 01, 2012, 04:24:38 PM said
The special groups is what you want to assign people to the Wiki Editor group.  In SMF you create that group,  Get that group ID (ie its in the url when you are editing the group).
If you don't want these editors to be apart of a default MediaWiki group, you will need to create that group in MediaWiki.  FYI you are looking to use $wgRestrictionLevels and $wgGroupPermissions.  You can search for more on creating groups In Media Wiki for how to setup that group.

In the Config you use SMFs group ID and The MediaWiki Group Name.

$wgSMFSpecialGroups = array(
   // SMF Group ID => Wiki group name.
   5 => 'autoconfirmed',
);

From this, group ID 5 is the Jr Member group on SMF by default.  Then you have the autoconfirmed group on MediaWiki.  So users in group 5 on SMF automatically would be put into that group.

Denying access like that you would want to use the $wgSMFGroupID array.  Add those SMF group IDs to that array.  IE in the example code it is using SMF group ID 2, which is global moderators.

FYI, note that this Auth module does cache a lot of stuff to keep it from using too many resources every time to auth the user.  So it may require some time for the auth to update with the new group permissions.

For your logout issue, as long as your are logged into SMF, you can't log out of the wiki.  The auth will auto log you in again.  If there is a way to change the logout link or override it I haven't looked.  I don't see session information being passed to the link.  I wouldn't know if it could be trusted to not cause a CSRF problem.  So I wouldn't even want to think of it if its not going to prevent that.


Edit,

Also forgot to say that you need this line as well to deny all users editing by default:
$wgGroupPermissions['*']['edit'] = false; // MediaWiki Setting
planet9 on April 02, 2012, 08:05:42 AM said
Thanks SleePy. 

I'm confused and maybe there are multiple versions of the LocalSettings comments.  Mine say that $wgSMFGroupID   is for granting access and $wgSMFDenyGroupID is for denying.  And $wgSMFAdminGroupID is for admins.

So I'm confused on what $wgSMFGroupID really does.  Thanks.

----
I also have another version which includes the items below and I assume these are deprecated?

Code: [Select]
// This tells the Plugin to require a user to be a member of the above SMF group. (ie. wiki) Setting this to false will let any SMF user edit the wiki.
#$wgSMF_UseWikiGroup = true;

// Name of your SMF group users need to be a member of to use the wiki. (i.e. wiki)
#$wgSMF_WikiGroupName  = 'Wiki Editor';

---
I've had to modify Auth_SMF.php to not check "isLoggedIn()" when using $wgSMFDenyGroupID

Code: [Select]
// Lastly check to see if they are not banned and allowed to login
if (!$wgAuth->isNotBanned($ID_MEMBER) || !$wgAuth->canLogin())
{
#if($user->isLoggedIn()) // COMMENTED OUT THIS LINE
$user->logout();
return true;
}

Otherwise the error I see is:
Code: [Select]
Warning: array_merge() [function.array-merge]: Argument #1 is not an array in /home/public_html/wiki/includes/User.php on line 2295

Warning: array_unique() [function.array-unique]: The argument should be an array in /home/public_html/wiki/includes/User.php on line 2295

Warning: Invalid argument supplied for foreach() in /home/public_html/wiki/includes/User.php on line 3475

Warning: Invalid argument supplied for foreach() in /home/public_html/wiki/includes/User.php on line 3484
MediaWiki internal error.
Study Force on April 12, 2012, 10:34:12 PM said
Here's mine.

Been working extra hard trying to get the theme to match my own:

http://biology-forums.com/definitions/

Let me know your opinions!
Predat0r on April 18, 2012, 07:46:04 AM said
First off: Thank you a lot for this most awesome extension!

I experienced a really nasty bug using it, that I just had to post here.
I had a fresh install of MW and installed the extension + configured it. I enabled the cookie system and made some group assignments, nothing fancy. The first try went good, I was logged into MW.
But from this point, I always got this error and cookie login didn't work anymore:
Code: [Select]
Notice: Array to string conversion in [...]/extensions/Auth_SMF.php on line 162Line 162 is:
Code: (php) [Select]
$user_settings['smf_groups'] = array_merge(array($user_settings['id_group'], $user_settings['id_post_group']), explode(',', $user_settings['additional_groups']));
So I made some debug outputs and finally found out that $user_settings contained a string instead of an array, the same string that was serialized into $_SESSION['user_settings']. After some more debug outputs, I found that $user_settings contained a string after this statement in line 140 was executed:
Code: (php) [Select]
$_SESSION['user_settings'] = serialize($user_settings);After blaming serialize and trying other crazy stuff, I found out that renaming $user_settings to $usr_settings fixed the error and logging in worked perfectly! WTF?
I am not familiar with PHP, so I don't know if this is possible, but could this error originate in the name equality of $user_settings and $_SESSION['user_settings']? Maybe someone of you can tell me why this happened.


Regards

PS: I am using PHP 5.2.17, MySQL 5.5.19 and an Apache 2.2.22 on CentOS release 6.2 (Final).
OvermindDL1 on April 27, 2012, 02:15:24 AM said
---
I've had to modify Auth_SMF.php to not check "isLoggedIn()" when using $wgSMFDenyGroupID

Code: [Select]
// Lastly check to see if they are not banned and allowed to login
if (!$wgAuth->isNotBanned($ID_MEMBER) || !$wgAuth->canLogin())
{
#if($user->isLoggedIn()) // COMMENTED OUT THIS LINE
$user->logout();
return true;
}

Otherwise the error I see is:
Code: [Select]
Warning: array_merge() [function.array-merge]: Argument #1 is not an array in /home/public_html/wiki/includes/User.php on line 2295

Warning: array_unique() [function.array-unique]: The argument should be an array in /home/public_html/wiki/includes/User.php on line 2295

Warning: Invalid argument supplied for foreach() in /home/public_html/wiki/includes/User.php on line 3475

Warning: Invalid argument supplied for foreach() in /home/public_html/wiki/includes/User.php on line 3484
MediaWiki internal error.
Exact same error here on the same lines and all (also had a stack trace that he did not display), but his fix fixed my issue.  What is the problem that this is caused by?

However, I have a few new bugs.

First bug is that when clicking Log In from the wiki takes me to the forum page, as expected, but when logging in I end up at the main page of the forum instead of back at the last page that I was at in the wiki.

Second bug is that when clicking Log out from the wiki logs me out of the wiki, some how, but without logging me out of the forum, and I cannot get the wiki to see me logged in again until I clear my cookies.

My SMF version is 2.0.2 with the latest integration code as of an hour ago.
OvermindDL1 on April 27, 2012, 06:35:29 PM said
New error now, and this was working last night, no changes since then.  Anytime anyone tries to post anything to the wiki, whether Admin or normal editor, when they hit submit in the edit box they get a "Sorry! We could not process your edit due to a loss of session data. Please try again. If it still does not work, try logging out and logging back in. " error, and yet it was just working last night.  Thoughts?  Googled around for the error but they all point to php session errors, which is not an issue, I tested quite a variety of different settings, full rw access is allowed, tried other directories, etc...
Study Force on April 27, 2012, 07:59:14 PM said
New error now, and this was working last night, no changes since then.  Anytime anyone tries to post anything to the wiki, whether Admin or normal editor, when they hit submit in the edit box they get a "Sorry! We could not process your edit due to a loss of session data. Please try again. If it still does not work, try logging out and logging back in. " error, and yet it was just working last night.  Thoughts?  Googled around for the error but they all point to php session errors, which is not an issue, I tested quite a variety of different settings, full rw access is allowed, tried other directories, etc...

That's normal, especially if your wiki has it's own subdomain. If anything, click publish again and it should work.
OvermindDL1 on April 28, 2012, 12:57:38 AM said
New error now, and this was working last night, no changes since then.  Anytime anyone tries to post anything to the wiki, whether Admin or normal editor, when they hit submit in the edit box they get a "Sorry! We could not process your edit due to a loss of session data. Please try again. If it still does not work, try logging out and logging back in. " error, and yet it was just working last night.  Thoughts?  Googled around for the error but they all point to php session errors, which is not an issue, I tested quite a variety of different settings, full rw access is allowed, tried other directories, etc...

That's normal, especially if your wiki has it's own subdomain. If anything, click publish again and it should work.
Same domain,
http://site/forum
http://site/wiki (wiki is the short url, /w/ is the actual storage location).
I got it working somehow by just restarting apache, no clue what was up...

Still have the other errors with logging in misredirection, logging out being ghosted, etc...
rickyherbal on April 28, 2012, 08:37:44 AM said
help me please :(

http://www.simplemachines.org/community/index.php?topic=475177.0
Study Force on April 28, 2012, 11:36:14 AM said
New error now, and this was working last night, no changes since then.  Anytime anyone tries to post anything to the wiki, whether Admin or normal editor, when they hit submit in the edit box they get a "Sorry! We could not process your edit due to a loss of session data. Please try again. If it still does not work, try logging out and logging back in. " error, and yet it was just working last night.  Thoughts?  Googled around for the error but they all point to php session errors, which is not an issue, I tested quite a variety of different settings, full rw access is allowed, tried other directories, etc...

That's normal, especially if your wiki has it's own subdomain. If anything, click publish again and it should work.
Same domain,
http://site/forum
http://site/wiki (wiki is the short url, /w/ is the actual storage location).
I got it working somehow by just restarting apache, no clue what was up...

Still have the other errors with logging in misredirection, logging out being ghosted, etc...

This happened to me when I first started with my wiki a year ago. Try playing around with the localsettings file, and most times it's just a browsing cache issue that wouldn't normally happen if the website was being used by only one person at one computer. You're probably logging in with different users trying to see how it looks and you're running into these caching issues.
Just my 2 cents.
OvermindDL1 on April 29, 2012, 03:10:09 AM said
New error now, and this was working last night, no changes since then.  Anytime anyone tries to post anything to the wiki, whether Admin or normal editor, when they hit submit in the edit box they get a "Sorry! We could not process your edit due to a loss of session data. Please try again. If it still does not work, try logging out and logging back in. " error, and yet it was just working last night.  Thoughts?  Googled around for the error but they all point to php session errors, which is not an issue, I tested quite a variety of different settings, full rw access is allowed, tried other directories, etc...

That's normal, especially if your wiki has it's own subdomain. If anything, click publish again and it should work.
Same domain,
http://site/forum
http://site/wiki (wiki is the short url, /w/ is the actual storage location).
I got it working somehow by just restarting apache, no clue what was up...

Still have the other errors with logging in misredirection, logging out being ghosted, etc...

This happened to me when I first started with my wiki a year ago. Try playing around with the localsettings file, and most times it's just a browsing cache issue that wouldn't normally happen if the website was being used by only one person at one computer. You're probably logging in with different users trying to see how it looks and you're running into these caching issues.
Just my 2 cents.

Nope, this was happening to multiple people in various locations of the world.  It stopped just as suddenly on its own though about 8 hours later, unsure, nothing else on the server went down (of which there is quite a bit).

Still have the login misredirection and logout ghost bugs though.
Nutbolt on February 06, 2013, 07:11:54 PM said
I have got this running and I have it setup so that there's a SMF group named Mentors, and a wiki group named Editor. If they are added to the SMF Mentors group, they are then added to the wiki Editor group. However if I remove them from the SMF group, they are not being removed from the wiki group. I have given it plenty of time (hours) for any kind of caching to go, and no luck.

Any ideas why people aren't being removed from the groups on wiki? Thanks
emanuele on February 09, 2013, 04:54:56 PM said
Are you using the latest version of mediawiki?
Nutbolt on February 11, 2013, 11:14:51 AM said
Yup, using the latest version of MW and SMF.
Attoy on February 11, 2013, 07:24:49 PM said
I just installed SMF 2.0.4 and Mediawiki 1.20.2. I downloaded the bridge extension from github and edited LocalSetting.php as writted in the readme file. If I'm logged in SMF and I follow a link to the Wiki (I added a button between 'Home' and 'Help) it shows I'm not logged in the Wiki and if I click 'Log In' it redirect me on the SMF login page. I log again on the forum, I get the forum homepage and if I go on the wiki I'm still not logged in.

Any suggestion on how to fix it pls?

FYI I've got SMF in forums.domain.com and the Wiki in wiki.domain.com .

Thanks in advance for your help.

Bst rgds,
Attoy
emanuele on February 12, 2013, 05:44:11 AM said
Do you already have any user in the MediaWiki database?
I just tried and I was having problems because a previous user with the same name of my SMF account was already present in the MW database.
I truncated the MW user table, but of course be careful because mine was just a test site and didn't care about what was in the db.
Attoy on February 12, 2013, 06:06:33 AM said
Do you already have any user in the MediaWiki database?
I just tried and I was having problems because a previous user with the same name of my SMF account was already present in the MW database.
I truncated the MW user table, but of course be careful because mine was just a test site and didn't care about what was in the db.

Indeed that's one of a problem :) You're awesome. May I guess you're also italian?

However every time a new user bridge from SMF to MediaWiki I've got a notice:

Code: [Select]
Notice: undefined index: smf_member_id in /my/full/path/to/mediawiki/extensions/Auth_SMF.php on line 1024
that said line is the last one of the following block:

Code: [Select]
// Preserve our member id.
if (empty($saveOptions['smf_member_id']))
$saveOptions['smf_member_id'] = $user->mOptionOverrides['smf_member_id'];
emanuele on February 12, 2013, 07:52:51 AM said
May I guess you're also italian?
Yep, right.

However every time a new user bridge from SMF to MediaWiki I've got a notice:

Code: [Select]
Notice: undefined index: smf_member_id in /my/full/path/to/mediawiki/extensions/Auth_SMF.php on line 1024
that said line is the last one of the following block:

Code: [Select]
// Preserve our member id.
if (empty($saveOptions['smf_member_id']))
$saveOptions['smf_member_id'] = $user->mOptionOverrides['smf_member_id'];
Yups...I forgot about that one while posting (it was almost lunch time O:))...that's funny I can't reproduce it anymore...
Anyway the complain is apparently legit because the column (and so the settings) has been deprecated in MW 1.19, I suppose the bridge *should* use the external_user table, but at the moment I'm not sure how to achieve that...
You can just comment out the following line in Auth_SMF.php:
Code: [Select]
$wgHooks['UserSaveOptions'][] = 'wfProfileSMFID';To be completely honest I have no idea if this has other consequences... :-[
Attoy on February 12, 2013, 07:58:53 AM said

Code: [Select]
// Preserve our member id.
if (empty($saveOptions['smf_member_id']))
$saveOptions['smf_member_id'] = $user->mOptionOverrides['smf_member_id'];

Yups...I forgot about that one while posting (it was almost lunch time O:))...that's funny I can't reproduce it anymore...
Anyway the complain is apparently legit because the column (and so the settings) has been deprecated in MW 1.19, I suppose the bridge *should* use the external_user table, but at the moment I'm not sure how to achieve that...
You can just comment out the following line in Auth_SMF.php:
Code: [Select]
$wgHooks['UserSaveOptions'][] = 'wfProfileSMFID';To be completely honest I have no idea if this has other consequences... :-[

What if I 'comment' the whole block? Is it the same result of your line?
emanuele on February 12, 2013, 09:29:04 AM said
Commeting out that single line the code is not executed.
Account Abandoned on March 12, 2013, 10:25:24 AM said
Has anyone figured out a fix for the error:

Quote
Sorry! We could not process your edit due to a loss of session data. Please try again. If it still does not work, try logging out and logging back in.

It happens every time I attempt to create or edit a page. Latest version of MW + SMF.
emanuele on March 12, 2013, 10:35:09 AM said
What version of mediawiki? (and maybe SMF too)
Arantor on March 12, 2013, 10:35:22 AM said
(Latest isn't a version)
Account Abandoned on March 12, 2013, 10:58:11 AM said
MW 1.20.3

SMF 2.0.4

i.e. the latest version :-\
emanuele on March 13, 2013, 09:50:31 AM said
In your LocalSettings.php (mediawiki), remove:
Code: [Select]
$wgSMFLogin = true;
Account Abandoned on March 14, 2013, 02:07:31 PM said
I removed it, now I am asked to login (mediawiki) and when I do I get:

Quote
Login error
Another Admin Wiki uses cookies to log in users. You have cookies disabled. Please enable them and try again.

Edit: My cookies ARE indeed enabled
emanuele on March 14, 2013, 03:15:48 PM said
mmm...okay, I was probably looking at the wrong file...
Restore $wgSMFLogin and comment out $wgCookieDomain instead.
Account Abandoned on March 14, 2013, 06:22:41 PM said
Alrighty, I will try that and report back :)
Account Abandoned on March 15, 2013, 10:05:10 AM said
This solution worked! Thank you very much!
donkenoji on March 15, 2013, 10:42:20 AM said
I use php debugging so I can keep an eye on scripts that aren't working properly.  Anyone else getting this with the integration?

Code: [Select]
Strict Standards: Declaration of Auth_SMF::modifyUITemplate() should be compatible with AuthPlugin::modifyUITemplate(&$template, &$type) in path_to_wiki/wiki/extensions/Auth_SMF.php on line 410

Strict Standards: Declaration of Auth_SMF::allowPropChange() should be compatible with AuthPlugin::allowPropChange($prop = '') in path_to_wiki/wiki/extensions/Auth_SMF.php on line 410

Strict Standards: Declaration of Auth_SMF::initUser() should be compatible with AuthPlugin::initUser(&$user, $autocreate = false) in path_to_wiki/wiki/extensions/Auth_SMF.php on line 410


SMF 2.0.4
MW: 1.20.3
emanuele on March 15, 2013, 01:34:13 PM said
The first function seems to have an argument missing (even though the "new" argument in MW is not apparently used), the last one seems to have a "pass-by-ref" missing on $user, but no idea about the second one...arg, I have installed the 1.20.2, I have to download the new one to be sure...
donkenoji on March 15, 2013, 01:50:38 PM said
The first function seems to have an argument missing (even though the "new" argument in MW is not apparently used), the last one seems to have a "pass-by-ref" missing on $user, but no idea about the second one...arg, I have installed the 1.20.2, I have to download the new one to be sure...

Alright, in the meantime I'll downgrade MW.  See what happens.
emanuele on March 15, 2013, 01:58:58 PM said
I expect it will be the same, since the issues I reported are from 1.20.2, I can imagine in .3 they changed something else in allowPropChange.
donkenoji on March 15, 2013, 02:11:43 PM said
I expect it will be the same, since the issues I reported are from 1.20.2, I can imagine in .3 they changed something else in allowPropChange.

Ah, that's terrible news.  Is there a version that is properly working with this extension, that doesn't 1) Print markup, or 2) no noticable errors?
emanuele on March 15, 2013, 02:23:32 PM said
I *think* two things are not that difficult to fix:
Code: (find) [Select]
public function modifyUITemplate(&$template)
Code: (replace with) [Select]
public function modifyUITemplate( &$template, &$type )and:
Code: (find) [Select]
public function initUser( $user, $autocreate = false)
Code: (replace with) [Select]
public function initUser( &$user, $autocreate = false)you can start with that and see if it at least remove those two errors.
donkenoji on March 15, 2013, 02:28:17 PM said
I *think* two things are not that difficult to fix:
Code: (find) [Select]
public function modifyUITemplate(&$template)
Code: (replace with) [Select]
public function modifyUITemplate( &$template, &$type )and:
Code: (find) [Select]
public function initUser( $user, $autocreate = false)
Code: (replace with) [Select]
public function initUser( &$user, $autocreate = false)you can start with that and see if it at least remove those two errors.

Wow, your quick response and accuracy on the subject astounds me. 

The final error I'm getting now is:
Code: [Select]
Strict Standards: Declaration of Auth_SMF::allowPropChange() should be compatible with AuthPlugin::allowPropChange($prop = '') in path_to_wiki/wiki/extensions/Auth_SMF.php on line 410
emanuele on March 15, 2013, 07:37:35 PM said
I have to grab the .3 MW version...tomorrow.
Feel free to bump the topic, I could forget about it (don't tell anyone, but my memory is a mess :P).
donkenoji on March 15, 2013, 08:13:49 PM said
NP Man; and just for science, some more errors for interested people =D

Code: [Select]
Strict Standards: Declaration of Auth_SMF::allowPropChange() should be compatible with AuthPlugin::allowPropChange($prop = '') in /path_to_wiki/extensions/Auth_SMF.php on line 410

Warning: in_array() expects parameter 2 to be array, null given in  /path_to_wiki/extensions/Auth_SMF.php on line 879
emanuele on March 15, 2013, 08:37:05 PM said
That is probably something you forgot to setup on your LocalSettings.php, read the instructions at the beginning of the file, $wgSMFAdminGroupID should be an array. ;)
donkenoji on March 15, 2013, 08:40:04 PM said
Code: [Select]
Strict Standards: Declaration of Auth_SMF::allowPropChange() should be compatible with AuthPlugin::allowPropChange($prop = '') in /path_to_wiki/extensions/Auth_SMF.php on line 410

Is the last one, that is printed.
emanuele on March 18, 2013, 05:43:01 PM said
Try changing:
Code: [Select]
public function allowPropChange($prop)with:
Code: [Select]
public function allowPropChange($prop = '')
PhuriousGeorge on March 18, 2013, 08:13:39 PM said
Posted this issue on a separate thread, but thought I'd try my luck here

I setup the Wiki and swear I followed the instructions for the bridge to a "t" and I keep 500'ing. Turned on error debugging on my server and appears this is the issue:

Code: [Select]
PHP Strict Standards:  Declaration of Auth_SMF::modifyUITemplate() should be compatible with AuthPlugin::modifyUITemplate(&$template, &$type) in C:\inetpub\wwwroot\wiki\extensions\Auth_SMF.php on line 410
PHP Strict Standards:  Declaration of Auth_SMF::allowPropChange() should be compatible with AuthPlugin::allowPropChange($prop = '') in C:\inetpub\wwwroot\wiki\extensions\Auth_SMF.php on line 410
PHP Strict Standards:  Declaration of Auth_SMF::initUser() should be compatible with AuthPlugin::initUser(&$user, $autocreate = false) in C:\inetpub\wwwroot\wiki\extensions\Auth_SMF.php on line 410

Any clue where I've gone wrong?

http://www.simplemachines.org/community/index.php?topic=498305.0
emanuele on March 19, 2013, 04:57:45 AM said
http://www.simplemachines.org/community/index.php?topic=461612.msg3508189#msg3508189
http://www.simplemachines.org/community/index.php?topic=461612.msg3508339#msg3508339
http://www.simplemachines.org/community/index.php?topic=461612.msg3509932#msg3509932
PhuriousGeorge on March 19, 2013, 01:02:46 PM said
http://www.simplemachines.org/community/index.php?topic=461612.msg3508189#msg3508189
http://www.simplemachines.org/community/index.php?topic=461612.msg3508339#msg3508339
http://www.simplemachines.org/community/index.php?topic=461612.msg3509932#msg3509932

Doh, I feel like a dummy for not re-reviewing this thread before posting. Thanks emanuele, will give that a go.
emanuele on March 19, 2013, 05:17:42 PM said
No problem, it happens. ;)
PhuriousGeorge on March 19, 2013, 08:35:38 PM said
Try changing:
Code: [Select]
public function allowPropChange($prop)with:
Code: [Select]
public function allowPropChange($prop = '')

That appears to have worked! Page loaded at least. On to testing authentication.

Thanks!
JohnMcCreedy on March 26, 2013, 03:10:48 PM said
Hello, I followed these instructions to the letter after installing the latest MediaWiki (I also have SMF 2.0.4) on the same domain as SMF and it just does not work. When you attempt to log in using your forum credentials it says "username cannot be found".  Now this is the third one I've tried and all of them have the same problem - it just does not recognise your forum username/password.
Kindred on March 26, 2013, 04:10:18 PM said
you can not install in the same DIRECTORY!
JohnMcCreedy on March 26, 2013, 07:17:37 PM said
you can not install in the same DIRECTORY!

Sorry I meant something different (I meant the same domain). It's in its own directory.
JohnMcCreedy on March 28, 2013, 06:53:53 AM said
Can anyone assist me, please?
emanuele on March 28, 2013, 10:42:31 AM said
Well, there is not much I can tell you, which version of the bridge did you download?
I posted few tweaks for MW 1.20.3 in the last couple of pages, did you try any of them?
donkenoji on March 28, 2013, 10:54:45 AM said
Code: [Select]
Notice: Undefined index: smf_member_id in /path_to_wiki/extensions/Auth_SMF.php on line 1024
Comes up when a user first logs in or is created.  Apparently, it's not reading the groups either; as they are not getting the proper permissions.  Any thoughts?

Food for Thought, my settings config:
Code: [Select]
# This requires a user be logged into the wiki to make changes.
$wgGroupPermissions['*']['edit'] = false; // MediaWiki Setting

# If you experience the issue where you appear to be logged in
# eventhough you are logged out then disable the page cache.
#$wgEnableParserCache = false;
#$wgCachePages = false;

# SMF Authentication
# To get started you only need to configure wgSMFPath.
# The rest of the settings are optional for advanced features.
# Relative path to the forum directory from the wiki
# Do not put a trailing /
# Example: /public_html/forum and /public_html/wiki -> ../forum
$wgSMFPath = "../smf";

# Use SMF's login system to automatically log you in/out of the wiki
# This works best if you are using SMF database sessions (default).
# Make sure "Use database driven sessions" is checked in the
# SMF Admin -> Server Settings -> Feature Configuration section
# NOTE: Make sure to configure the $wgCookieDomain below
$wgSMFLogin = true;
$wgCookieDomain = 'mycookiedomain.com';

# Members in these SMF groups will not be allowed to sign into wiki.
# This is useful for denying access to wiki and a easy anti-spam
# method.  The group ID, which can be found in the url (;group=XXX)
# when viewing the group from the administrator control panel.
$wgSMFDenyGroupID = array(80, 22, 67);

# Grant members of this SMF group(s) access to the wiki
# NOTE: The wgSMFDenyGroupID group supersedes this.
$wgSMFGroupID = array(87);

# Grant members of this SMF group(s) wiki sysop privileges
# NOTE: These members must be able to login to the wiki
$wgSMFAdminGroupID = array(1, 85);

# SMF to wiki group translation.  This allows us to assign wiki groups
# to those in certain SMF groups.
$wgSMFSpecialGroups = array(
  // SMF Group ID => Wiki group name,
1 => 'bureaucrat'
);

# THIS MUST BE ADDED.  This prevents direct access to the Auth file.
define('SMF_IN_WIKI', true);

# Load up the extension
require_once "$IP/extensions/Auth_SMF.php";
$wgAuth = new Auth_SMF();
emanuele on March 28, 2013, 11:00:48 AM said
MW version?
Kindred on March 28, 2013, 11:03:02 AM said
and you still have not answered emanuele's other questions...

... which version of the bridge did you download?
I posted few tweaks for MW 1.20.3 in the last couple of pages, did you try any of them?
JohnMcCreedy on March 28, 2013, 11:04:16 AM said
Well, there is not much I can tell you, which version of the bridge did you download?
I posted few tweaks for MW 1.20.3 in the last couple of pages, did you try any of them?

This one: https://github.com/SimpleMachines/smf-mw-auth. I tried another one but it was apparently riddled with bugs. Apparently it's not grabbing the cookies despite cookies being activated. It's been tested in Firefox, IE and Chrome.

Just to be clear as well, I'm the forum/wiki owner but the person who was trying to implement this is a professional web developer.
Kindred on March 28, 2013, 11:12:30 AM said
do you have subdomain independent cookies turned on in SMF? (and local cookies turned off)


and did yoju apply the tweaks that emanuele posted?
donkenoji on March 28, 2013, 11:13:16 AM said
and you still have not answered emanuele's other questions...

... which version of the bridge did you download?
I posted few tweaks for MW 1.20.3 in the last couple of pages, did you try any of them?

Pardon me, emanuele and I did a bit of trouble shooting on the .20 version last week; didn't know I had pending questions to answer from him.


MediaWiki
1.20.3

Regarding:
Code: [Select]
Notice: Undefined index: smf_member_id in /path_to_wiki/extensions/Auth_SMF.php on line 1024
JohnMcCreedy on March 28, 2013, 12:48:53 PM said
do you have subdomain independent cookies turned on in SMF? (and local cookies turned off)


and did yoju apply the tweaks that emanuele posted?

No and yes and not entirely sure, in that order (I'll ask the guy that's helping me, later) :)

Forget the tweaks for the moment, should independent cookies be turned on?
donkenoji on March 28, 2013, 01:22:30 PM said
and you still have not answered emanuele's other questions...

... which version of the bridge did you download?
I posted few tweaks for MW 1.20.3 in the last couple of pages, did you try any of them?

Pardon me, emanuele and I did a bit of trouble shooting on the .20 version last week; didn't know I had pending questions to answer from him.


MediaWiki
1.20.3

Regarding:
Code: [Select]
Notice: Undefined index: smf_member_id in /path_to_wiki/extensions/Auth_SMF.php on line 1024

I commented out the line
Code: [Select]
$wgHooks['UserSaveOptions'][] = 'wfProfileSMFID';... and the error goes away, however; my groups aren't updating.  Users can login and authenticate, but it doesn't properly seem to be grabbing groups.
JohnMcCreedy on March 28, 2013, 01:26:11 PM said
Seems like he hadn't applied the fix. Just did it and it works like a charm. Thanks for the help :)
donkenoji on March 29, 2013, 09:13:31 AM said
Code: [Select]
$wgSMFSpecialGroups = array(
  // SMF Group ID => Wiki group name,
1 => 'bureaucrat';
85 => 'administrator';
84 => 'editor';
);

I'm not a coder; anyone know the proper syntax for this? By default it was one line; what's the proper way to string multiple groups?
donkenoji on March 29, 2013, 09:16:48 AM said
Code: [Select]
$wgSMFSpecialGroups = array(
  // SMF Group ID => Wiki group name,
1 => 'bureaucrat';
85 => 'administrator';
84 => 'editor';
);

I'm not a coder; anyone know the proper syntax for this? By default it was one line; what's the proper way to string multiple groups?

NVM!  Answered my question, it's commas!
Code: [Select]
$wgSMFSpecialGroups = array(
  // SMF Group ID => Wiki group name,
1 => 'bureaucrat',
85 => 'administrator',
84 => 'editor',
);
donkenoji on March 29, 2013, 09:48:20 AM said
NVM!  Answered my question, it's commas!
Code: [Select]
$wgSMFSpecialGroups = array(
  // SMF Group ID => Wiki group name,
1 => 'bureaucrat',
85 => 'administrator',
84 => 'editor',
);

Oddly enough; none of my permissions are transferring over.  They are getting authenticated; but even sysop isn't being given (with the native change in the LocalSettings.php).

Any thoughts?

Code: [Select]
Warning: in_array() expects parameter 2 to be array, null given in /var/zpanel/hostdata/zadmin/public_html/the-bwc_com/wiki/extensions/Auth_SMF.php on line 879
emanuele on March 29, 2013, 11:24:08 AM said
Code: [Select]
# Grant members of this SMF group(s) wiki sysop privileges
# NOTE: These members must be able to login to the wiki
#$wgSMFAdminGroupID = array(1, 3);
So, most likely you didn't initialize $wgSMFAdminGroupID in localSettings.php

ETA: groups are updated every 900 seconds (15 minutes), so if you visited a wiki page and then changed something (e.g. member group of the user), you will not see anything for some time.
donkenoji on March 29, 2013, 01:15:01 PM said
Code: [Select]
# Grant members of this SMF group(s) wiki sysop privileges
# NOTE: These members must be able to login to the wiki
#$wgSMFAdminGroupID = array(1, 3);
So, most likely you didn't initialize $wgSMFAdminGroupID in localSettings.php

ETA: groups are updated every 900 seconds (15 minutes), so if you visited a wiki page and then changed something (e.g. member group of the user), you will not see anything for some time.

You were right, that was the issue.  My final problem then is, I've created a custom group in the wiki called 'Editor'. 
$wgSMFSpecialGroups = array(
  // SMF Group ID => Wiki group name,
   1 => 'bureaucrat',
   85 => 'sysop',
   86 => 'Editor',
);

When users sign in and are in the 'Editor' group on the forums; they show up as 'editor' without a link (aka no group) on the wiki.  Is my syntax proper?
emanuele on March 29, 2013, 01:31:29 PM said
Is "Editor" or "editor" the MW group name? (not sure if it is important)
donkenoji on March 29, 2013, 01:34:35 PM said
Integration:
Code: [Select]
$wgSMFSpecialGroups = array(
  // SMF Group ID => Wiki group name,
1 => 'bureaucrat',
85 => 'sysop',
86 => 'Editor',
);

Perms:
Code: [Select]
# Editors #
$wgGroupPermissions['Editor']['edit'] = true;
$wgGroupPermissions['Editor']['read'] = true;
$wgGroupPermissions['Editor']['import']           = true;
$wgGroupPermissions['Editor']['importupload']     = true;
$wgGroupPermissions['Editor']['move']             = true;
$wgGroupPermissions['Editor']['move-subpages']    = true;
$wgGroupPermissions['Editor']['move-rootuserpages'] = true;
$wgGroupPermissions['Editor']['protect']          = true;
$wgGroupPermissions['Editor']['upload']           = true;
$wgGroupPermissions['Editor']['reupload']         = true;
$wgGroupPermissions['Editor']['reupload-shared']  = true;
$wgGroupPermissions['Editor']['upload_by_url']    = true;
$wgGroupPermissions['Editor']['browsearchive']    = true;
$wgGroupPermissions['Editor']['noratelimit']      = true;
$wgGroupPermissions['Editor']['movefile']         = true;

Case is matching.

Update: now editor isn't showing at all; like that group can't be seen.  sysop and Admin are both porting fine however.
Update 2: Now it is showing, just not as a link.

Image for reference:
emanuele on March 30, 2013, 11:13:49 AM said
Well, that's the same here too:
http://wiki.simplemachines.org/smf/Special:ActiveUsers
it is probably related to how MW handle groups...dunno...
donkenoji on March 30, 2013, 11:18:10 AM said
Well, that's the same here too:
http://wiki.simplemachines.org/smf/Special:ActiveUsers
it is probably related to how MW handle groups...dunno...

Okay, I've realized that I can force the permission update by having the users update their preferences.  Is the update for all users not working automatically?
Code: [Select]
// $wgHooks['UserSaveOptions'][] = 'wfProfileSMFID';

I'm not sure it's related, but for some reason, the only way I can get perms on users is to have them update their preferences on their individual account.
Study Force on March 30, 2013, 01:06:29 PM said
I *think* two things are not that difficult to fix:
Code: (find) [Select]
public function modifyUITemplate(&$template)
Code: (replace with) [Select]
public function modifyUITemplate( &$template, &$type )and:
Code: (find) [Select]
public function initUser( $user, $autocreate = false)
Code: (replace with) [Select]
public function initUser( &$user, $autocreate = false)you can start with that and see if it at least remove those two errors.

This appeared to fix the problem I was having on mediawiki 1.16 and SMF 1.1.18.

Thanks :D
Study Force on March 30, 2013, 01:36:09 PM said
By the way, was the issue with the underscore ever fixed?

I had a member name: member__ (with two underscores)... and when they tried to edit something, mediawiki went crazy lol

In addition, if a member has the name: member_name, their name shows: member name.
Arantor on March 30, 2013, 01:37:33 PM said
The whole underscore-to-space thing is how MediaWiki works with everything since spaces don't work properly in URLs but underscores do - and everything in MediaWiki revolves around that.
donkenoji on April 01, 2013, 11:01:41 AM said
Code: [Select]
Warning: session destroy(): trying to destroy unitialized session in /path_to_wiki/extensions/auth_smf.php on line 311
A few users are reporting this error and are being told they must login.  They have active sessions with the SMF boards; however, still can't login.  The extension is creating accounts and they're being listed on the userlist.  Any thoughts on this one?
emanuele on April 01, 2013, 12:43:02 PM said
Do they have by chance similar *username* (not real names)? (and with similar I mean spaces/underscores, "strange" letters, etc.)
Study Force on April 01, 2013, 01:16:58 PM said
Yes, the same usernames but, where there is an underscore in the SMF registered name, it becomes a space in mediawiki.
donkenoji on April 02, 2013, 01:44:41 PM said
Code: [Select]
Warning: session_destroy(): Trying to destroy uninitialized session in /path_to_wiki/extensions/Auth_SMF.php on line 311
Any thoughts on this one?  Users report that they won't get logged in.

From the auth file:
Code: [Select]
// Destory their session.
$wgCookiePrefix = strtr($wgCookiePrefix, "=,; +.\"'\\[", "__________");
$old_session = session_name(isset($wgSessionName) ? $wgSessionName : $wgCookiePrefix . '_session');
session_destroy();
emanuele on April 02, 2013, 02:23:18 PM said
Do they have by chance similar *username* (not real names)? (and with similar I mean spaces/underscores, "strange" letters, etc.)
donkenoji on April 02, 2013, 04:00:26 PM said
Do they have by chance similar *username* (not real names)? (and with similar I mean spaces/underscores, "strange" letters, etc.)
Negative, I'm one of the individuals effected today and it's a simple name (no non alpha characters and no spaces).  It appears to be limited to those with Admin rights (though don't quote me on that).
donkenoji on April 02, 2013, 06:31:10 PM said
Update; not just administrators; just a coincidence that the two first effected were admins.

Warning: session_destroy(): Trying to destroy uninitialized session in /path_to_wiki/extensions/Auth_SMF.php on line 311
emanuele on April 03, 2013, 09:15:05 AM said
No idea about that one, sorry...
RustyBarnacle on April 22, 2013, 03:39:09 PM said
Does this work for the current version of mw. 1.20.4?  Or before I begin should I be looking at starting with an older version to guarantee it works with the latest tweaks posted in here?
emanuele on April 24, 2013, 05:08:57 AM said
I would suggest to use the latest and if you encounter any issue, you report it.
It has worked from WM 1.16 up to 1.20.3 with just a couple of minor tweaks (that BTW are not yet included in the "official" distribution, so you have to dig the topic to find them ;)), so I'm confident it will work with 1.20.4 with the same tweaks described in this topic.
RustyBarnacle on April 24, 2013, 02:02:38 PM said
Thats what I figured and we're in the process of doing.  So far it's just wiki building and we'll integrate when it's done.  Thanks!
AnakinSpain on April 29, 2013, 03:57:35 AM said
Why I have this error?

"Cannot retrieve contributors at this time"

I modified SMFPath according my instalation...
emanuele on April 29, 2013, 04:04:55 AM said
What version of SMF e MW? (In particular the latter.)

Never seen this error before...

Is the forum working properly?
Try checking your database and repair all the tables.
Do you have mods?
Are SMF and MW on the same database?
AnakinSpain on April 29, 2013, 04:44:02 AM said
What version of SMF e MW?: SMF 2.0.4   Media wiki: 1.20.4
Is the forum working properly?: Yes, you can see in www.clubsunroller.com/foro
Try checking your database and repair all the tables: No
Do you have mods?: Yes (
1.     Birthday On Register   
2.   Aeva Media    1.4w     
3.   Pretty URLs    1.0     
4.   Add Social Media Icons To Profiles    1.1.0     
5.   Social Login    2.2     
6.   YouTube BBCode    2.6     
7.   Karma Buttons    1.1     
8.   Disable Image Toggle    1.1     
9.   SimplePortal    2.3.5     
10.   Downloads System    2.0     
11.   Tapatalk SMF 2.0 RC5/Final Plugin    3.6.0 
12.   KeyCAPTCHA for SMF    2.5     [
13.   Ad Managment
Are SMF and MW on the same database?: YES

I have to say that I convert from phpbb and I have other membergroups.

I only modify localsettings in order to change mi forum path to "foro"
emanuele on April 29, 2013, 05:42:36 AM said
Try checking your database and repair all the tables: No
"No" you didn't do it?
"No" you don't want to do it?
"No" you don't know how to do it?
"No" it didn't work?
Just to be sure. ;)
AnakinSpain on April 29, 2013, 06:10:10 AM said
Try checking your database and repair all the tables: No
"No" you didn't do it?
"No" you don't want to do it?
"No" you don't know how to do it?
"No" it didn't work?
Just to be sure. ;)

Sorry, I do from MySQL panel and I get in a lot of tables this error: "The storage engine for the table doesn't support r.." doing rapair table.

Then I reinstall selecting MyISAM as type of document instead of inmo. But it is the same error.
"Cannot retrieve contributors at this time"
AnakinSpain on April 30, 2013, 01:56:42 PM said
Any solution?
AnakinSpain on May 03, 2013, 01:54:10 PM said
nothing?
emanuele on May 03, 2013, 03:35:02 PM said
What exactly did you do to use the auth file?
In other words, what exactly did you write in LocalSettings.php?
AnakinSpain on May 10, 2013, 06:06:19 AM said
Well now when I open my wiki: www.clubsunroller.com/wiki I didnt get anything just a code of gitub!!
emanuele on May 10, 2013, 06:14:32 AM said
That's why I asked you to post what exactly you did...but apparently it's not that easy to get answers... :P

https://raw.github.com/SimpleMachines/smf-mw-auth/master/Auth_SMF.php

Save this file on your desktop (ctrl+s in most of the browsers) and upload it via ftp to your MW extensions directory.
AnakinSpain on May 10, 2013, 06:21:38 AM said
Hehehe,sorry.

Well, now It runs.

 I did click in register It loads register page of SMF ->> It is OK, but How I login into wiki?

What I want is create a group in SMF, for example "Wiki redacters", and what I want is that:

- All users can read wiki
- Only admin and users of group "Wiki redacters" can create pages and content in wiki
emanuele on May 10, 2013, 07:43:01 AM said
Most of the answers are in the comment at the beginning of the auth file, starting from here:
https://github.com/SimpleMachines/smf-mw-auth/blob/master/Auth_SMF.php#L25
AnakinSpain on May 10, 2013, 10:23:10 AM said
Well, after modify files, I get an error: Warning: session destroy(): trying to destroy unitialized session in /path_to_wiki/extensions/auth_smf.php on line 311
Then I truncate table of user and then integration works very well.

Now I have to modify permisions.

I have create a group in SMF "Colaborador" wich I want to have permissions to create, and edit pages.

AnakinSpain on May 10, 2013, 02:09:17 PM said
All of that is new for me,  I have been all the afternoon trying to make it, but  I did not.

I have in SMF some groups, but I only are interested in two:
- Administrators: group id = 1
- Redactores wiki: group id = 5

I have in localsettings that:

Code: [Select]
# If you experience the issue where you appear to be logged in
# eventhough you are logged out then disable the page cache.
$wgEnableParserCache = false;
$wgCachePages = false;

# SMF Authentication
# To get started you only need to configure wgSMFPath.
# The rest of the settings are optional for advanced features.

# Relative path to the forum directory from the wiki
# Do not put a trailing /
# Example: /public_html/forum and /public_html/wiki -> ../forum
$wgSMFPath = "../foro";

# Use SMF's login system to automatically log you in/out of the wiki
# This works best if you are using SMF database sessions (default).
# Make sure "Use database driven sessions" is checked in the
# SMF Admin -> Server Settings -> Feature Configuration section
# NOTE: Make sure to configure the $wgCookieDomain below
$wgSMFLogin = true;
$wgCookieDomain = 'SMFCookie11';

# Members in these SMF groups will not be allowed to sign into wiki.
# This is useful for denying access to wiki and a easy anti-spam
# method.  The group ID, which can be found in the url (;group=XXX)
# when viewing the group from the administrator control panel.
#$wgSMFDenyGroupID = array(4);

# Grant members of this SMF group(s) access to the wiki
# NOTE: The wgSMFDenyGroupID group supersedes this.
#wgSMFGroupID = array(2);

# Grant members of this SMF group(s) wiki sysop privileges
# NOTE: These members must be able to login to the wiki
#$wgSMFAdminGroupID = array(1);

# SMF to wiki group translation.  This allows us to assign wiki groups
# to those in certain SMF groups.
$wgSMFSpecialGroups = array(
  // SMF Group ID => Wiki group name,
5 => 'autoconfirmed',
       1 => 'administrator',
       5 => 'editor',
);

# THIS MUST BE ADDED.  This prevents direct access to the Auth file.
define('SMF_IN_WIKI', true);

# Load up the extension
require_once "$IP/extensions/Auth_SMF.php";
$wgAuth = new Auth_SMF();


$wgGroupPermissions['*']['edit'] = false; // MediaWiki Setting

I want that only group adminstrators and "redactores wiki" can create and edit pages.
Other users only read.

But I can not do that...
emanuele on May 15, 2013, 05:14:09 PM said
Okay...I'm very sorry... :-[

I left that post around for a second (5 days ago) and in a minute the browser's window was filled with tabs and I completely forgot that this post was already written and waiting (and to be honest I thought I posted it)... :-[
Well, in the end it doesn't give much valuable informations... ::)

The bridge seems configured properly, now you should set the MW permissions, but that's something I have no experience with...you should ask on some mediawiki support forum/mailinglist/wikipage...
I may try to check, though I'm not sure when...
Draffi on July 21, 2013, 07:36:30 PM said
Definatly...the SMF Bridge for MW (v1.21.1) are not working.

(fresh installed on both, XAMPP)

Have an error:
Warning: session_destroy(): Trying to destroy uninitialized session...
Study Force on July 21, 2013, 11:18:07 PM said
I would love to see a "related topics" block in this theme. Is anyone interested in developing such a thing?

For example, if a wiki article is simple to a thread title, it shows it below. :D

I would pay for its development.
emanuele on July 22, 2013, 03:36:01 AM said
Definatly...the SMF Bridge for MW (v1.21.1) are not working.

(fresh installed on both, XAMPP)

Have an error:
Warning: session_destroy(): Trying to destroy uninitialized session...
I have installed the auth on a forum several weeks ago following few of the tricks I posted in this very topic and everything works as expected, so it *is* working.

One thing I remember I did at least once, but don't remember any more if it was related to the session_destroy or not, was to truncate the users table of the wiki...not a big suggestion, I know...
Draffi on July 22, 2013, 05:35:20 PM said
After trying almost the half day, to make the Bridge working, i finsihed this with a success.

you need to truncate the mediawiki user table, for to make this working

(smf 2.0.4 /MW 1.21.1)

I`m using the smfcurve-skin for the wiki - and i have a question:

How can i delete the "Logoff" Button in the UserInfo above the sidebar?
emanuele on July 22, 2013, 05:53:19 PM said
After trying almost the half day, to make the Bridge working, i finsihed this with a success.

you need to truncate the mediawiki user table, for to make this working
Probably when you created the user while installing MediaWiki, you created one with the same username as the one in SMF.

Why do you want to remove the logoff button?
I'm not sure it's possible.
Draffi on July 22, 2013, 06:02:23 PM said
Grr.....i was changing some settings in MW in the user-profile and now, i`m not able to log-in anymore....

 >:(

Exactly for this reason, i want to delete the logoff-Button: When i click on this, i logged off from the MW not from SMF !!!

(this was different when i was bridging MW 1.16)

HELP! How can i login again into MW?
emanuele on July 23, 2013, 03:23:48 AM said
https://github.com/SimpleMachines/smf-mw-auth/blob/master/Auth_SMF.php#L44
Study Force on July 24, 2013, 12:53:49 AM said
https://github.com/SimpleMachines/smf-mw-auth/blob/master/Auth_SMF.php#L44

Curious, does this work on SMF 1.x ?
vbgamer45 on July 24, 2013, 01:02:09 AM said
The code their does not work with SMF 1.1.x
Study Force on July 24, 2013, 01:14:03 AM said
The code their does not work with SMF 1.1.x

Thanks, just wondering.
emanuele on July 24, 2013, 04:19:28 AM said
Live627 adapted it for 1.1: https://github.com/live627/smf-mw-auth
Study Force on July 24, 2013, 03:49:51 PM said
Live627 adapted it for 1.1: https://github.com/live627/smf-mw-auth

Thanks man!
Draffi on July 24, 2013, 04:23:07 PM said
Quote
https://github.com/SimpleMachines/smf-mw-auth/blob/master/Auth_SMF.php#L44

If this answer was for me: I was donig this - bridge not working correctly, if you are log-out from MW 1.21.1 (and 1.19, too)

You CAN only re-log-in, if you are trunkate the mw_user table...
emanuele on July 24, 2013, 05:26:19 PM said
The answer was for you, yes.
Did you set the variable mentioned in the paragraph I linked?
Draffi on July 24, 2013, 05:39:57 PM said

Quote
# Make sure "Use database driven sessions" is checked in the
# SMF Admin -> Server Settings -> Feature Configuration section

CHECKED

Quote
# NOTE: Make sure to configure the wgCookeDomain below
#$wgSMFLogin = true;

Deleted the #-Symbol

Quote
#$wgCookieDomain = 'domain.com';
insert my domain, tested with myforum.com and www.myforum.com - not function.

Furthermore, when you use the smfcurve-skin with MW 1.21.1 you never can use the upper-menu-tabs in the wiki-personal settings...(Where timezone, skin-select, editor settings are stored...)

emanuele on July 24, 2013, 05:45:03 PM said
Quote
# NOTE: Make sure to configure the wgCookeDomain below
#$wgSMFLogin = true;

Deleted the #-Symbol
Is wgCookeDomain enabled or not in your case?
I've seen it work better if disabled (commented out).
Draffi on July 24, 2013, 05:52:48 PM said
i tried at first only with the "main setting" (require smf_auth), was not working (login), so step-by-step i turn all the settings on (together with the fixes from this thread, eg. comment out one line in smf_aut, trunkate the mw_user table...) at the end, i can login, but when i logout (in mw !) i never can login again.

for this reason i was asking to disable the link...
Draffi on July 24, 2013, 05:54:05 PM said
well....i stepback to MW 1.16 - in some month i will see if somebody have a better Bridge/newer version...

studentforums on November 04, 2013, 05:36:49 AM said
I installed the bridge and the wiki pages load but I am not logged into the wiki by logging into smf and I get this error when I log into the wiki

Unable to view external table
MySQL Error Number: 1054
MySQL Error Message: Unknown column 'memberName' in 'field list'

I have just upgraded bith smf to 2.05 and wikimedia to 1.21.2
emanuele on November 04, 2013, 06:32:21 AM said
Considering memberName is a 1.x column name, I bet you are using the wrong code.
Where exactly did you download it?
studentforums on November 04, 2013, 07:01:14 AM said
SMF from the smf website, mediawiki from mediawiki.
The file SMF_Auth.php was alread installed. I have not edited it.
Kindred on November 04, 2013, 07:41:38 AM said
SMF_Auth.php was already installed? ??? ???

From where?   that is not a part of either the MW or the SMF downloads... so, from where did you download the bridge?
studentforums on November 04, 2013, 08:18:32 AM said
The bridge was installed in 2009, and worked ok before the upgrade.
emanuele on November 04, 2013, 09:34:31 AM said
The file SMF_Auth.php was alread installed. I have not edited it.
But from where did you download it?
Did you by chance recently upgraded from SMF 1.1 and you were using the auth for SMF 1.1?
Kindred on November 04, 2013, 09:47:58 AM said
because the bridge for SMF 1.1.x will NOT work with SMF 2.0 (because the database table and column names changed)
studentforums on November 04, 2013, 01:31:06 PM said
I upgraded from smf 1.1.8
Arantor on November 04, 2013, 01:33:25 PM said
Right, so now you're on 2.0, the old bridge won't work because the database changed, and we have no idea what the old bridge looked like or did anyway - you should probably forget trying to make that old bridge work.
emanuele on November 04, 2013, 02:13:57 PM said
You can just download the one from github as explained in the first message of this topic and use it. ;)
studentforums on November 04, 2013, 02:56:53 PM said
Actually I did download the bridge from github and have been trying to make it work on and off all day
Kindred on November 04, 2013, 03:02:21 PM said
well, you didn't download the new bridge if you are getting an error regarding "'memberName"

if you did download the new bridge, why didn't you mention that earlier in the thread?
emanuele on November 04, 2013, 05:21:58 PM said
Actually I did download the bridge from github and have been trying to make it work on and off all day
And the one above is the error you are getting with the bridge from github? ???
I hope not. ;D
studentforums on November 05, 2013, 05:41:27 AM said
Using the file from github I get the error message

Hacking attempt on smf
studentforums on November 05, 2013, 06:41:36 AM said
Wey-Hey it works now.
Every time I fix something I have a beer.
studentforums on November 05, 2013, 08:46:36 AM said
I have been poking around trying to get the user settings right.
Logging into SMF does not log me into the wiki.
In addition setting the memebr groups in Localsettings.php produces a blank page.
I am trying to use these settings.

# Members in these SMF groups will not be allowed to sign into wiki.
# This is useful for denying access to wiki and a easy anti-spam
# method. The group ID, which can be found in the url (;group=XXX)
# when viewing the group from the administrator control panel.
$wgSMFDenyGroupID = array(4);

# Grant members of this SMF group(s) access to the wiki
# NOTE: The wgSMFDenyGroupID group supersedes this.
#wgSMFGroupID = array(1, 2, 5, 6, 7, 8, 9, 11, 13, 15, 14, 25, 16, 18, 19, 23, 20, 12);

# Grant members of this SMF group(s) wiki sysop privileges
# NOTE: These members must be able to login to the wiki
#$wgSMFAdminGroupID = array(1);

studentforums on November 05, 2013, 04:06:38 PM said
I fixed it. In SMF_Auth.php I replaced

$smf_member_id = $user->getOption('smf_member_id');

with

$smf_member_id =  $user_settings['id_member'];

All seems to work now.
SilverKnight on October 14, 2014, 06:14:03 PM said
I can't get the bridge to work with the latest version of mediawiki and smf (2.0.9). It's fully installed, hooked up to a subdomain wiki.domain.com and forums is forums.domain.com (same domain)

When on the wiki i click login, takes me to smf login, logs in fine however mediawiki does not reflect this login (It stays on the forum.)

My plugins:

1.   Split Forum Mod   1.10   [ Uninstall ]
2.   RSS Feed Poster   4.1   [ Uninstall ]
3.   Menu Editor Lite   1.0.5   [ Uninstall ]
4.   @mention members   1.1.2   [ Uninstall ]
5.   Default Avatar   2.3   [ Uninstall ]
6.   Spoiler Tag   0.7.2a   [ Uninstall ]
7.   Gamer IDs   1.4   [ Uninstall ]
8.   Ultimate Profile   0.9.1   [ Uninstall ]
9.   Download bbcode 2.0   2.0   [ Uninstall ]
10.   PartyMembers   1.0   [ Uninstall ]
11.   URL Popup   1.0.2   [ Uninstall ]
12.   VigLink   1.3   [ Uninstall ]
13.   Battle   1.14   [ Uninstall ]
14.   Member Color Link   3.1   [ Uninstall ]
15.   SimplePortal   2.3.5   [ Uninstall ]
16.   Tidy Child Boards   1.4.1   [ Uninstall ]
17.   Member Awards   3.0   [ Uninstall ]
18.   Relative Dates   1.3   [ Uninstall ]
19.   AJAX Recent Topics   1.1   [ Uninstall ]
20.   Tabbed smileys   0.3.99e   [ Uninstall ]
21.   BBC User Info   2.0   [ Uninstall ]
22.   Tagging System   3.0   [ Uninstall ]
23.   Stop Spammer   2.3.9   [ Uninstall ]
24.   reCAPTCHA for SMF   0.9.8a   [ Uninstall ]
25.   Board Icons   1.0   [ Uninstall ]
26.   SMF Social Groups   2.4.5   [ Uninstall ]
27.   Avatar On Board RC2   2.1   [ Uninstall ]
28.   SMF 2.0.8 Update   1.0   [ Uninstall ]
29.   SMF 2.0.7 Update   1.0   [ Uninstall ]
30.   SMF 1.1.19 / 2.0.6 Update   1.0   [ Uninstall ]
Illori on October 14, 2014, 06:57:20 PM said
have you just installed the bridge and it is now not working? if it is a new install have you enabled subdomain independent cookies? it is also more helpful if you pick one place or another to discuss your issue, having it here and github may end up confusing people.
SilverKnight on October 14, 2014, 07:07:06 PM said
have you just installed the bridge and it is now not working? if it is a new install have you enabled subdomain independent cookies? it is also more helpful if you pick one place or another to discuss your issue, having it here and github may end up confusing people.

Sorry, Thank you for your reply, I was not sure if to pick github or the forum as it's been a year here.

This is a old forum running smf 2.0.8. I have indeed installed the bridge as per the installation information in the github and reviewed the faq questions.

Auth_SMF.php is in extensions folder of wiki, LocalSettings.php is in the root folder of the wiki.

This is my localsettings.php file:

Quote
<?php
# This file was automatically generated by the MediaWiki 1.23.5
# installer. If you make manual changes, please keep track in case you
# need to recreate them later.
#
# See includes/DefaultSettings.php for all configurable settings
# and their default values, but don't forget to make changes in _this_
# file, not there.
#
# Further documentation for configuration settings may be found at:
# https://www.mediawiki.org/wiki/Manual:Configuration_settings

# Protect against web entry
if ( !defined( 'MEDIAWIKI' ) ) {
   exit;
}

## Uncomment this to disable output compression
# $wgDisableOutputCompression = true;

$wgSitename = "HyperGaming Network Wiki";
$wgMetaNamespace = "HyperGaming_Network_Wiki";

# Custom

$wgGroupPermissions['*']['edit'] = false; // MediaWiki Setting

## The URL base path to the directory containing the wiki;
## defaults for all runtime URL paths are based off of this.
## For more information on customizing the URLs
## (like /w/index.php/Page_title to /wiki/Page_title) please see:
## https://www.mediawiki.org/wiki/Manual:Short_URL
$wgScriptPath = "";
$wgScriptExtension = ".php";

## The protocol and server name to use in fully-qualified URLs
$wgServer = "http://wiki.hypergamer.net";

## The relative URL path to the skins directory
$wgStylePath = "$wgScriptPath/skins";

## The relative URL path to the logo.  Make sure you change this from the default,
## or else you'll overwrite your logo when you upgrade!
$wgLogo = "$wgStylePath/common/images/wiki.png";

## UPO means: this is also a user preference option

$wgEnableEmail = true;
$wgEnableUserEmail = true; # UPO

$wgEmergencyContact = "apache@wiki.hypergamer.net";
$wgPasswordSender = "apache@wiki.hypergamer.net";

$wgEnotifUserTalk = false; # UPO
$wgEnotifWatchlist = false; # UPO
$wgEmailAuthentication = true;

## Database settings
$wgDBtype = "mysql";
$wgDBserver = "localhost";
$wgDBname = "#########";
$wgDBuser = "##########";
$wgDBpassword = "#######";

# MySQL specific settings
$wgDBprefix = "wiki_";

# MySQL table options to use during installation or update
$wgDBTableOptions = "ENGINE=InnoDB, DEFAULT CHARSET=binary";

# Experimental charset support for MySQL 5.0.
$wgDBmysql5 = false;

## Shared memory settings
$wgMainCacheType = CACHE_NONE;
$wgMemCachedServers = array();

## To enable image uploads, make sure the 'images' directory
## is writable, then set this to true:
$wgEnableUploads = false;
#$wgUseImageMagick = true;
#$wgImageMagickConvertCommand = "/usr/bin/convert";

# InstantCommons allows wiki to use images from http://commons.wikimedia.org
$wgUseInstantCommons = false;

## If you use ImageMagick (or any other shell command) on a
## Linux server, this will need to be set to the name of an
## available UTF-8 locale
$wgShellLocale = "en_US.utf8";

## If you want to use image uploads under safe mode,
## create the directories images/archive, images/thumb and
## images/temp, and make them all writable. Then uncomment
## this, if it's not already uncommented:
#$wgHashedUploadDirectory = false;

## Set $wgCacheDirectory to a writable directory on the web server
## to make your wiki go slightly faster. The directory should not
## be publically accessible from the web.
#$wgCacheDirectory = "$IP/cache";

# Site language code, should be one of the list in ./languages/Names.php
$wgLanguageCode = "en";

$wgSecretKey = "b1ba4ca883b700636bff414badc026f99306360b07335dccfedd0e707b39fcdf";

# Site upgrade key. Must be set to a string (default provided) to turn on the
# web installer while LocalSettings.php is in place
$wgUpgradeKey = "5c5eb8de59c15c00";

## Default skin: you can change the default skin. Use the internal symbolic
## names, ie 'cologneblue', 'monobook', 'vector':
$wgDefaultSkin = "vector";

## For attaching licensing metadata to pages, and displaying an
## appropriate copyright notice / icon. GNU Free Documentation
## License and Creative Commons licenses are supported so far.
$wgRightsPage = ""; # Set to the title of a wiki page that describes your license/copyright
$wgRightsUrl = "";
$wgRightsText = "";
$wgRightsIcon = "";

# Path to the GNU diff3 utility. Used for conflict resolution.
$wgDiff3 = "/usr/bin/diff3";



# End of automatically generated settings.
# Add more configuration options below.

# If you experience the issue where you appear to be logged in
# eventhough you are logged out then disable the page cache.
#$wgEnableParserCache = false;
#$wgCachePages = false;

# SMF Authentication
# To get started you only need to configure wgSMFPath.
# The rest of the settings are optional for advanced features.

# Relative path to the forum directory from the wiki
# Do not put a trailing /
# Example: /public_html/forum and /public_html/wiki -> ../forum
$wgSMFPath = "../forums";

# Set to the version of SMF you are using.
#$wgSMFVersion = "1.1";
$wgSMFVersion = "2.0";

# Use SMF's login system to automatically log you in/out of the wiki
# This works best if you are using SMF database sessions (default).
# Make sure "Use database driven sessions" is checked in the
# SMF Admin -> Server Settings -> Feature Configuration section
# NOTE: Make sure to configure the $wgCookieDomain below
$wgSMFLogin = true;
$wgCookieDomain = 'forums.hypergamer.net';

# Members in these SMF groups will not be allowed to sign into wiki.
# This is useful for denying access to wiki and a easy anti-spam
# method.  The group ID, which can be found in the url (;group=XXX)
# when viewing the group from the administrator control panel.
#$wgSMFDenyGroupID = array(4);

# Grant members of this SMF group(s) access to the wiki
# NOTE: The wgSMFDenyGroupID group supersedes this.
$wgSMFGroupID = array(1,2,3,4,50,54,0);

# Grant members of this SMF group(s) wiki sysop privileges
# NOTE: These members must be able to login to the wiki
$wgSMFGroupID = array(1, 2, 5, 6, 7, 8, 9, 11, 13, 15, 14, 25, 16, 18, 19, 23, 20, 12);

# SMF to wiki group translation.  This allows us to assign wiki groups
# to those in certain SMF groups.
#$wgSMFSpecialGroups = array(
#  // SMF Group ID => Wiki group name,
#   5 => 'autoconfirmed'
#);

$wgFavicon = "../forums/favicon.ico";

# THIS MUST BE ADDED.  This prevents direct access to the Auth file.
define('SMF_IN_WIKI', true);

# Load up the extension
require_once "$IP/extensions/Auth_SMF.php";
$wgAuth = new Auth_SMF();





Quote
Enable local storage of cookies
(SSI won't work well with this on.) 

This is off

Quote
Use subdomain independent cookies
(turn off local cookies first!)

This is on.

www.forums.hypergamer.net - This is the forum
www.wiki.hypergamer.net - This is the wiki installation
SleePy on October 15, 2014, 10:24:52 PM said
Cookie domain should just be .hypergamer.net
If you use developer tools on your browser you can see the cookie that SMF is setting.  The bridge needs access to and needs to find the cookie in order to get your SMF session going again.
SilverKnight on October 16, 2014, 06:32:38 PM said
Cookie domain should just be .hypergamer.net
If you use developer tools on your browser you can see the cookie that SMF is setting.  The bridge needs access to and needs to find the cookie in order to get your SMF session going again.

Thank you for your reply, i have changed it as you suggested and now i get:

An Error Has Occurred!
You were unable to login. Please check your cookie settings.

The wiki is using .hypergamer.net as the domain and the forums shows the cookie under forums.hypergamer.net

It seems two cookies appear for both domain with the same name, what am i doing wrong?
GreenSage on January 05, 2015, 06:54:02 AM said
Ok I have the mediawiki up and working and it's allowing login/logout with SMF_Auth.

May I ask how I can implement my sites theme into the Wiki like you have? Any best tips?

Thanks.

The wiki is at http://www.thedragon13.com/wiki but it's just the normal default installation at the moment.
Kindred on January 05, 2015, 08:29:37 AM said
you would have to design a new wiki theme to match your forum theme...   that's what we did.
GreenSage on January 05, 2015, 12:52:22 PM said
you would have to design a new wiki theme to match your forum theme...   that's what we did.

Ok thanks for the info. I'm currently looking at the WikiHow article on creating a skin. :)
SleePy on January 07, 2015, 11:59:45 PM said
https://github.com/SimpleMachines/smfcurve
eKyNoX on March 08, 2015, 04:14:59 AM said
Hello,

Like @SilverKnight before, I got some troubles getting bridge (v1.14) working correctly.
Once installed, and autologin activated, MediaWiki redirect to SMF (2.0.9) Login page, using here my smf credentials.

1. If not logged already in SMF, after credentials input, smf redirect to wiki, but still not logged in from wiki side.
2. If already logged in smf, smf login page is displayed, and after credentials input, that time it redirect to SMF index (and don't redirect to MediaWiki). If I move myself alone to Wiki page, I appear as logged out from wiki.

Login with MediaWiki using SMF accounts works if $wgSMFLogin = false;
MediaWiki autologin feature looks like broken. I suppose related to cookies.

SMF installed in /httpdocs/
MediaWiki in /httpdocs/wiki/

domain used is taucetifederation.com or www.taucetifederation.com

Inside LocalSettings.php, I tried every possible way to set domain :

$wgSMFLogin = true;
$wgCookieDomain = '.taucetifederation.com';
or :  taucetifederation.com or www.taucetifederation.com or  taucetifederation.com/wiki or with http, without, ...

No Changes ...

Here is my config :

Code: [Select]
# This requires a user be logged into the wiki to make changes.
$wgGroupPermissions['*']['edit'] = false; // MediaWiki Setting

# If you experience the issue where you appear to be logged in
# eventhough you are logged out then disable the page cache.
#$wgEnableParserCache = false;
#$wgCachePages = false;

# SMF Authentication
# To get started you only need to configure wgSMFPath.
# The rest of the settings are optional for advanced features.

# Relative path to the forum directory from the wiki
# Do not put a trailing /
# Example: /public_html/forum and /public_html/wiki -> ../forum
$wgSMFPath = "../";

# Use SMF's login system to automatically log you in/out of the wiki
# This works best if you are using SMF database sessions (default).
# Make sure "Use database driven sessions" is checked in the
# SMF Admin -> Server Settings -> Feature Configuration section
# NOTE: Make sure to configure the wgCookeDomain below
$wgSMFLogin = true;
$wgCookieDomain = '.taucetifederation.com';

# Members in these SMF groups will not be allowed to sign into wiki.
# This is useful for denying access to wiki and a easy anti-spam
# method.  The group ID, which can be found in the url (;group=XXX)
# when viewing the group from the administrator control panel.
#$wgSMFDenyGroupID = array(4);

# Grant members of this SMF group(s) access to the wiki
# NOTE: The wgSMFDenyGroupID group supersedes this.
#wgSMFGroupID = array(2);

# Grant members of this SMF group(s) wiki sysop privileges
# NOTE: These members must be able to login to the wiki
#$wgSMFAdminGroupID = array(1, 3);

# SMF to wiki group translation.  This allows us to assign wiki groups
# to those in certain SMF groups.
#$wgSMFSpecialGroups = array(
# // SMF Group ID => Wiki group name.
# 5 => 'autoconfirmed',
#);

# THIS MUST BE ADDED.  This prevents direct access to the Auth file.
define('SMF_IN_WIKI', true);

# Load up the extension
require_once "$IP/extensions/Auth_SMF.php";
$wgAuth = new Auth_SMF();

If someone get caught by this problem, any help would be greatly appreciated.
Any additional informations could be asked if needed.

Thanks anyway :)


Kindred on March 08, 2015, 08:55:16 AM said
do you have subdomain independent cookies turned ON (and local cookies turned OFF) in SMF Admin server settings?
eKyNoX on March 08, 2015, 04:06:55 PM said
Hello and Thanks for your answer.

- So yes local cookie storage disabled
- Just activated "Use Subdomain independent cookies" with no changes.

No subdomains used currently anyway.



I have to correct my previous post, I have explained behavior using auth plugin 1.13 following http://www.mediawiki.org/wiki/Extension:SMF_Auth_Integration

I used 1.14 with no luck, I'll make more tests on latest 1.14 github version and coming back to you.
GreenSage on March 08, 2015, 04:28:40 PM said
Arghhhh I had this error I forgot how I fixed it now though. FFS. :o

Oh yea one of my errors was the actual path from wiki to forum. I started with a "/" at the beginning and the bridge didn't like that (in one of those settings you have to manually edit.)

I have my SMF in /forums and wiki in /wiki (both housed in public_html so for me this line was needed (after many wierd code attempts...don't try to figure it out it doesn't seem logical lol):

Code: [Select]
$wgScriptPath = "/wiki";
Does that help?

EDIT2: Is that your entire config or just the SMF part? That's really small.

EDIT3: Here's my SMF part of LocalSettings (on a working install. Took a few nights and many code changes heh):
Code: [Select]
# SMF Authentication
# To get started you only need to configure wgSMFPath and wgSMFVersion.
# The rest of the settings are optional for advanced features.

# Relative path to the forum directory from the wiki
# Do not put a trailing /
# Example: /public_html/forum and /public_html/wiki -> ../forum
$wgSMFPath = "../forums";

# Set to the version of SMF you are using.
#$wgSMFVersion = "1.1";
$wgSMFVersion = "2.0";

# Use SMF's login system to automatically log you in/out of the wiki
# This will only work if you are using SMF database sessions (default).
# Make sure "Use database driven sessions" is checked in the
# SMF Admin -> Server Settings -> Feature Configuration section
# NOTE: Make sure to configure the wgCookeDomain below
$wgSMFLogin = true;

# Make "Enable local storage of cookies" is unchecked in the
# SMF Admin -> Server Settings -> Feature Configuration section
# www.domain.org/wiki and www.domain.org/forums -> www.domain.org
# wiki.domain.org and forums.doman.org -> .domain.org
#$wgCookieDomain = 'www.domain.org';
#$wgCookiePath = '/'; // Optional, defaults to '/'
#$wgCookieSecure = false;  // Optional, only change on scheme mismatch

# Require members to be a part of this SMF group(s) to login
# NOTE: Members of the SMF Administrator group are always able to login
#$wgSMFGroupName = 'Wiki Editor';
#$wgSMFGroupName = array('Wiki Editor', 'Global Moderator');

# Grant members of this SMF group(s) wiki sysop privileges
# NOTE: These members must be able to login to the wiki
#$wgSMFAdminGroupName = 'Wiki Admin';
#$wgSMFAdminGroupName = array('Wiki Admin', 'Global Moderator');

# Load up the extension
require_once "$IP/extensions/Auth_SMF.php";
$wgAuth = new Auth_SMF();
eKyNoX on March 09, 2015, 07:16:29 AM said
Hello, thanks for all this informations.

I'll install back wiki and auth from scratch today to take steps carefully.

You use v1.13 auth plugin or 1.14?
eKyNoX on March 09, 2015, 09:46:06 AM said
Ok, still don't work but got some news.

With my fresh install, I started to use auth plugin v1.13 and behavior was the same like explained before (can login with smf credentials but when using $wgSMFLogin with cookie domain, do not redirect after login, and when back in wiki, I'm not logged in).

I tried after with auth plugin v1.14, I started here to not be able to login with my SMF administrator account and when using $wgSMFLogin, same problems as before occur ... but !

Used another smf account (not admin), it still do not redirect back to wiki, but I'm logged with that account inside mediawiki.

So ... why my main smf admin account is not accepted ?
Why too it do not redirect to wiki once logged?
Satissis on March 22, 2015, 05:51:21 PM said
Hi there.

I have just installed SMF v2.0.9 and MW v1.24.1

Once I add the Auth_SMF.php (v1.14) and added the stuff to the localSettings.php and set $wgSMFLogin = true;
I'm getting these warnings and the page do not load:
Code: [Select]
( ! ) Warning: session_name(): session.name cannot be a numeric or empty '' in E:\Administrator\PhpstormProjects\ModdingCentral\wiki\extensions\Auth_SMF.php on line 333
Call Stack
# Time Memory Function Location
1 0.0010 246976 {main}( ) ..\index.php:0
2 0.0390 7725072 MediaWiki->run( ) ..\index.php:46
3 0.0390 7726584 MediaWiki->main( ) ..\MediaWiki.php:435
4 0.0780 11844368 User->isLoggedIn( ) ..\MediaWiki.php:524
5 0.0780 11844496 User->getId( ) ..\User.php:3074
6 0.0780 11844792 User->load( ) ..\User.php:1922
7 0.0780 11845144 User->loadFromSession( ) ..\User.php:343
8 0.0780 11845648 wfRunHooks( ) ..\User.php:1066
9 0.0780 11845696 Hooks::run( ) ..\GlobalFunctions.php:3995
10 0.0780 11846592 call_user_func_array:{E:\Administrator\PhpstormProjects\ModdingCentral\wiki\includes\Hooks.php:206} ( ) ..\Hooks.php:206
11 0.0780 11847760 AutoAuthenticateSMF( ) ..\Hooks.php:206
12 0.0840 12586936 User->logout( ) ..\Auth_SMF.php:273
13 0.0840 12587352 wfRunHooks( ) ..\User.php:3446
14 0.0840 12587400 Hooks::run( ) ..\GlobalFunctions.php:3995
15 0.0840 12589296 call_user_func_array:{E:\Administrator\PhpstormProjects\ModdingCentral\wiki\includes\Hooks.php:206} ( ) ..\Hooks.php:206
16 0.0840 12589728 UserLogoutSMF( ) ..\Hooks.php:206
17 0.0850 12612928 session_name ( ) ..\Auth_SMF.php:333
and
Code: [Select]
( ! ) Warning: Cannot modify header information - headers already sent by (output started at E:\Administrator\PhpstormProjects\ModdingCentral\wiki\extensions\Auth_SMF.php:333) in E:\Administrator\PhpstormProjects\ModdingCentral\wiki\extensions\Auth_SMF.php on line 338
Call Stack
# Time Memory Function Location
1 0.0010 246976 {main}( ) ..\index.php:0
2 0.0390 7725072 MediaWiki->run( ) ..\index.php:46
3 0.0390 7726584 MediaWiki->main( ) ..\MediaWiki.php:435
4 0.0780 11844368 User->isLoggedIn( ) ..\MediaWiki.php:524
5 0.0780 11844496 User->getId( ) ..\User.php:3074
6 0.0780 11844792 User->load( ) ..\User.php:1922
7 0.0780 11845144 User->loadFromSession( ) ..\User.php:343
8 0.0780 11845648 wfRunHooks( ) ..\User.php:1066
9 0.0780 11845696 Hooks::run( ) ..\GlobalFunctions.php:3995
10 0.0780 11846592 call_user_func_array:{E:\Administrator\PhpstormProjects\ModdingCentral\wiki\includes\Hooks.php:206} ( ) ..\Hooks.php:206
11 0.0780 11847760 AutoAuthenticateSMF( ) ..\Hooks.php:206
12 0.0840 12586936 User->logout( ) ..\Auth_SMF.php:273
13 0.0840 12587352 wfRunHooks( ) ..\User.php:3446
14 0.0840 12587400 Hooks::run( ) ..\GlobalFunctions.php:3995
15 0.0840 12589296 call_user_func_array:{E:\Administrator\PhpstormProjects\ModdingCentral\wiki\includes\Hooks.php:206} ( ) ..\Hooks.php:206
16 0.0840 12589728 UserLogoutSMF( ) ..\Hooks.php:206
17 0.0890 12614784 setcookie ( ) ..\Auth_SMF.php:338

and a lot more of the "headers already sent" warnings.

Any thought on how to get it to work with the latest versions ?

Kind regards
Satis
GreenSage on March 22, 2015, 05:55:44 PM said
I only have one instance of session name and it's:
Code: [Select]
if( !isset( $_COOKIE[session_name()] )  ){
                    //User::SetupSession();
                    wfSetupSession();
}
Satissis on March 22, 2015, 08:14:26 PM said
I only have one instance of session name and it's:
Code: [Select]
if( !isset( $_COOKIE[session_name()] )  ){
                    //User::SetupSession();
                    wfSetupSession();
}
was this related to the post I posted above or to your own post further above?

If so, I don't see the connection

Kind regards
Satis
GreenSage on March 22, 2015, 10:21:28 PM said
I only have one instance of session name and it's:
Code: [Select]
if( !isset( $_COOKIE[session_name()] )  ){
                    //User::SetupSession();
                    wfSetupSession();
}
was this related to the post I posted above or to your own post further above?

If so, I don't see the connection

Kind regards
Satis

The error referenced that command so I printed out the command that's working on my installation. Does that match yours? We don't have your Auth_SMF.php to go off of so just using what information is present.
Satissis on March 23, 2015, 01:35:11 AM said
The error referenced that command so I printed out the command that's working on my installation. Does that match yours? We don't have your Auth_SMF.php to go off of so just using what information is present.
Alright, well the version of the Auth_SMF.php is the 1.14 from https://github.com/SimpleMachines/smf-mw-auth
I haven't changed anything in it since then. The warning message refers to this line:
https://github.com/SimpleMachines/smf-mw-auth/blob/master/Auth_SMF.php#L333 (link not working right since I don't have posted at least 10 postes)

I don't think I have seen your code in it, so maybe there is an updated version somewhere else ?

Kind regards
Satis
GreenSage on March 23, 2015, 02:33:06 AM said
The error referenced that command so I printed out the command that's working on my installation. Does that match yours? We don't have your Auth_SMF.php to go off of so just using what information is present.
Alright, well the version of the Auth_SMF.php is the 1.14 from https://github.com/SimpleMachines/smf-mw-auth
I haven't changed anything in it since then. The warning message refers to this line:
https://github.com/SimpleMachines/smf-mw-auth/blob/master/Auth_SMF.php#L333 (link not working right since I don't have posted at least 10 postes)

I don't think I have seen your code in it, so maybe there is an updated version somewhere else ?

Kind regards
Satis

Mine looks totally different then that file...I'm not sure sorry.
Satissis on March 23, 2015, 09:43:16 AM said
Mine looks totally different then that file...I'm not sure sorry.

BlueTiger what version of SMF and MW do you use ?

If those are the same versions as I posted above, then could you post your Auth_SMF.php code here then ?

Kind regards
Satis
Satissis on March 29, 2015, 10:41:41 AM said
Alright.

I have used some time fixing the warnings I was getting and can now see the page again.
Then I hit a snack that even that I was logged into the forum, it would not log me into the wiki. That I also fixed, since I found an small bug in the "AutoAuthenticateSMF" function, that didn't work with smf 2.0.9 and mw v1.24.1 and that might also fix the problem for some others having the same problems with not being able to see they are logged into the wiki after they are logged into the forum as well on older versions.

Now I have two small problem left.
1. When redirecting to the login page on the forum and login, it do not redirect me back to the wiki after I have logged in. This is due to when redirecting from the wiki to the forum login, the $_SESSION['old_url'] is set to "http://localhost/moddingcentral/moddingcentral/index.php" but was set to "http://localhost/moddingcentral/wiki/index.php?title=Main+Page&board=redirect" before redirecting to the forum login page but the forum did not catch that session value some how.

2. When logging out, it never logs out of the forum, so once logged out, it shows a logged out, but if you refresh the wiki page, you are automatic logged back in again. I did some tests and found out that it never got redirected to the forum to make it log out. Well the code is there for it, but never reaches it.
Here is why:
In the "UserLogoutSMF" function at the bottom, you have this:
Code: [Select]
// This means we have no SMF session data or unable to find it.
if (empty($_SESSION['session_var']))
return true;

smf_redirectWrapper('logout_url', 'logout;' . $_SESSION['session_var'] . '=' . $_SESSION['session_value']);
Somehow the $_SESSION['session_var'] is empty, so the redirect to the forum never happens and the login session is not terminated.

Any help is appreciated.

Kind regards
Satis
Dominus Arbitrationis on April 18, 2015, 07:32:38 PM said
I have been trying this for a long time now, and it just isn't working. I am running Mediawiki 1.19.24 and SMF 2.0.9. I have tried using the default Auth_SMF.php, placing that in my extensions directory, and adding the code that is commented out to my LocalSettings.php, along with pointing it to my databases. My problem is it refuses to connect to the database, with the message "SMF was unable to connect to the database." despite the database clearly being configured correctly, since I can login using the credentials.

This is all on a brand new install of MediaWiki and an old SMF install that is currently in use. The wiki is located at /publichtml/mediawiki and the forum is located at /publichtml/forums

Please note that I have censored the files' data to avoid any security issues.
Code: (Auth_SMF.php) [Select]
<?php
/*
SMF and MediaWiki Integration
=============================
Author: SleePy (sleepy at simplemachines dot org)
Original Author: Ryan Wagoner (rswagoner at gmail dot com)
Version: 1.14

Copyright
=============================
Copyright © 2012 Simple Machines. All rights reserved.

 Developed by: Simple Machines Forum Project
 Simple Machines
 http://www.simplemachines.org

 Redistribution and use in source and binary forms, with or without modification, are permitted provided that the following conditions are met:
[x] Redistributions of source code must retain the above copyright notice, this list of conditions and the following disclaimers.
[x] Redistributions in binary form must reproduce the above copyright notice, this list of conditions and the following disclaimers in the documentation and/or other materials provided with the distribution.
[x] Neither the names of Simple Machines Forum, Simple Machines, nor the names of its contributors may be used to endorse or promote products derived from this Software without specific prior written permission.

Place this file in your wiki/extenstions folder. If you
encouter an issue be sure to read the known issues below.

Add to LocalSettings.php
========================
# This requires a user be logged into the wiki to make changes.
$wgGroupPermissions['*']['edit'] = false; // MediaWiki Setting

# If you experience the issue where you appear to be logged in
# eventhough you are logged out then disable the page cache.
#$wgEnableParserCache = false;
#$wgCachePages = false;

# SMF Authentication
# To get started you only need to configure wgSMFPath. 
# The rest of the settings are optional for advanced features.

# Relative path to the forum directory from the wiki
# Do not put a trailing /
# Example: /public_html/forum and /public_html/wiki -> ../forum
$wgSMFPath = "../forum"; 

# Use SMF's login system to automatically log you in/out of the wiki
# This works best if you are using SMF database sessions (default).
# Make sure "Use database driven sessions" is checked in the
# SMF Admin -> Server Settings -> Feature Configuration section
# NOTE: Make sure to configure the wgCookeDomain below
#$wgSMFLogin = true;
#$wgCookieDomain = 'domain.com';

# Members in these SMF groups will not be allowed to sign into wiki.
# This is useful for denying access to wiki and a easy anti-spam
# method.  The group ID, which can be found in the url (;group=XXX)
# when viewing the group from the administrator control panel.
#$wgSMFDenyGroupID = array(4);

# Grant members of this SMF group(s) access to the wiki
# NOTE: The wgSMFDenyGroupID group supersedes this.
#wgSMFGroupID = array(2);

# Grant members of this SMF group(s) wiki sysop privileges
# NOTE: These members must be able to login to the wiki
#$wgSMFAdminGroupID = array(1, 3);

# SMF to wiki group translation.  This allows us to assign wiki groups
# to those in certain SMF groups.
#$wgSMFSpecialGroups = array(
# // SMF Group ID => Wiki group name.
# 5 => 'autoconfirmed',
#);

# THIS MUST BE ADDED.  This prevents direct access to the Auth file.
define('SMF_IN_WIKI', true);

# Load up the extension
require_once "$IP/extensions/Auth_SMF.php";
$wgAuth = new Auth_SMF();

 */
if (!defined('SMF_IN_WIKI'))
exit('Hacking attempt on SMF...');

// Only usefull for debugging purposes.
$wgSMFDebug false;

// More information if we are debugging.
if ($wgSMFDebug)
error_reporting(E_ALL);

if (
file_exists("$wgSMFPath/Settings.php"))
{
// If you are upgrading the wiki, loading SMF will break it because it defines $maintenace as well.
if (isset($maintenance))
$mediawiki_maintenance $maintenance;

require_once("$wgSMFPath/Settings.php");

// Restore mediawiki $maintenance if needed.
$smf_maintenance $maintenance;
if (isset($mediawiki_maintenance))
$maintenance $mediawiki_maintenance;
}
else
die('Check to make sure $wgSMFPath is correctly set in LocalSettings.php!');

$smf_settings['http://mydomain.com/forums/'] = $boardurl;
$smf_settings['SMFCookie463'] = $cookiename;
$smf_settings['correctDBserver'] = $db_server;
$smf_settings['correctDBname'] = $db_name;
$smf_settings['correctDBuser'] = $db_user;
$smf_settings['correctpassword'] = $db_passwd;
$smf_settings[''] = $db_prefix;
$smf_settings['debug_wiki'] = $wgSMFDebug;

/**
 * Check the SMF cookie and automatically log the user into the wiki.
 *
 * @param User $user
 * @return bool
 * @public
 */
function AutoAuthenticateSMF ($initial_user_data, &$user)
{
global $wgAuth$smf_settings$modSettings$smf_member_id$user_settings$ID_MEMBER;

// As to why we need to do this makes no sense really.
// Thanks to Norv of SimpleMachines.org for the fix.
$ID_MEMBER 0;
$user $initial_user_data;

if (isset($_COOKIE[$smf_settings['cookiename']]))
{
$_COOKIE[$smf_settings['cookiename']] = stripslashes($_COOKIE[$smf_settings['cookiename']]);

// MediaWiki doesn't support PHP4 since 1.6.12, so no check for a security issue is needed.
list ($ID_MEMBER$password) = @unserialize($_COOKIE[$smf_settings['cookiename']]);
$ID_MEMBER = !empty($ID_MEMBER) && strlen($password) > ? (int) $ID_MEMBER 0;
}

// Only load this stuff if the user isn't a guest.
if ($ID_MEMBER != 0)
{
if (!empty($smf_settings['debug_wiki']) || (empty($_SESSION['user_settings']) || empty($_SESSION['user_settings_time']) || time() > $_SESSION['user_settings_time'] + 900))
{
$request $wgAuth->query("
SELECT id_member, member_name, email_address, real_name,
is_activated, passwd, password_salt,
id_group, id_post_group, additional_groups
FROM 
$smf_settings[db_prefix]members
WHERE id_member = '
{$ID_MEMBER}'
AND is_activated = 1
LIMIT 1"
);

$user_settings mysql_fetch_assoc($request);

$_SESSION['user_settings'] = serialize($user_settings);
mysql_free_result($request);
}
else
$user_settings unserialize($_SESSION['user_settings']);

// Did we find 'im?  If not, junk it.
if (!empty($user_settings))
{
// SHA-1 passwords should be 40 characters long.
if (strlen($password) == 40)
$check sha1($user_settings['passwd'] . $user_settings['password_salt']) == $password;
else
$check false;

// Wrong password or not activated - either way, you're going nowhere.
$ID_MEMBER $check && ($user_settings['is_activated'] == || $user_settings['is_activated'] == 11) ? $user_settings['id_member'] : 0;
}
else
$ID_MEMBER 0;

// This just simplifies things further on.
$user_settings['smf_groups'] = array_merge(array($user_settings['id_group'], $user_settings['id_post_group']), explode(','$user_settings['additional_groups']));
}

// Log out guests or members with invalid cookie passwords.
if ($ID_MEMBER == 0)
{
// A bug seems to exist in isLoggedIn when it calls getId.
// getId appears to try to load user data, which may not exist at this point.
// Why getId just doesn't return $this->mId, I have no idea.
$user->doLogout();
return false;
}

// Do we know the SMF member id yet?
if (empty($smf_member_id))
$smf_member_id =  $user_settings['id_member'];

// If the username has an underscore or space accept the first registered user.
if (empty($smf_member_id) && (strpos($user_settings['member_name'], ' ') !== false || strpos($user_settings['member_name'], '_') !== false))
{
$request $wgAuth->query("
SELECT id_member 
FROM 
$smf_settings[db_prefix]members
WHERE member_name = '" 
$user_settings['member_name'] . "'
ORDER BY date_registered ASC
LIMIT 1"
);

list($id) = mysql_fetch_row($request);
mysql_free_result($request);

// Sorry your name was taken already!
if ($id != $ID_MEMBER)
{
if($user->isLoggedIn())
$user->logout();
return true;
}
}

// Lastly check to see if they are not banned and allowed to login
if (!$wgAuth->isNotBanned($ID_MEMBER) || !$wgAuth->canLogin())
{
if ($user->isLoggedIn())
$user->logout();
return true;
}

// Mediawiki username rules: http://www.mediawiki.org/wiki/Thread:Project:Support_desk/Username_rules
// MediaWiki Username are always capatlized, considers spaces and _ the same
// MediaWiki disallows #<>[]|{}, non-printable characters 0 through 31, and 127
// SMF disallows <>&"'=\
// Because of SMF and MediaWiki naming differences, we replace and adjust the naming to be compatible with MediaWiki, while allowing a reverse engineering to so speak.
$username ucfirst(str_replace('_''\''$user_settings['member_name']));
$username strtr($username, array('[' => '='']' => '"''|' => '&''#' => '\\'));
$username strtr($username, array('{' => '==''}' => '""'));

// Only poll the database if no session or username mismatch.
if (!($user->isLoggedIn() && $user->getName() == $username))
{
       
$user->setId($user->idFromName($username));

// No ID we need to add this member to the wiki database.
if ($user->getID() == 0)
{
// getID clears out the name set above.
$user->setName($username);
$user->setEmail($user_settings['email_address']);
$user->setRealName($user_settings['real_name']);

// Let wiki know that their email has been verified.
$user->mEmailAuthenticated wfTimestampNow(); 

// Finally create the user.
$user->addToDatabase();

// Don't worry about clearing the cache, the setEmail will do that.
$user->setOption('smf_member_id'$ID_MEMBER);
$user->setOption('smf_last_update'time());

// Some reason addToDatabase doesn't set options.  So we do this manually.
$user->saveSettings();
}
}

// Do we know the SMF member id yet?
if (empty($smf_member_id))
$smf_member_id $user->getOption('smf_member_id');

// We have tried all we can, but the data just doesn't match up.
if (empty($smf_member_id) || $smf_member_id != $ID_MEMBER)
{
// TODO: Log errors if the ids don't match?

if ($user->isLoggedIn())
$user->logout();
return true;
}

// Keep their email and real name up to date with SMF
$last_update = (int) $user->getOption('smf_last_update'0);

if (empty($last_update) || time() > ($last_update 900))
{
$user->setEmail($user_settings['email_address']);
$user->setRealName($user_settings['real_name']);

// We have some sort of group change.
$wgAuth->isGroupAllowed($user_settings['member_name'], $user);
$wgAuth->setAdminGroup($user$smf_member_id);

// Save!
$user->setOption('smf_last_update'time());
$user->saveSettings();
}

// Go ahead and log 'em in, but only if the session isn't already going.
if (session_id() === '')
{
wfSetupSession();
$user->setCookies();
}

return true;
}

/**
 * Redirect them to the SMF login page.
 *
 * @param User $user
 * @public
 */
function UserLoginFormSMF (&$user)
{
smf_sessionSetup();
smf_redirectWrapper('old_url''login');
}

/**
 * Redirect and utilize the SMF logout function.
 * This also destroys the wiki session, preventing issues
 * where wiki still believes a user is logged in.
 *
 * @param User $user
 * @public
 */
function UserLogoutSMF (&$user)
{
global $wgCookiePrefix$wgSessionName;

// Log them out of wiki first.
$user->doLogout();

// Destory their session.
$wgCookiePrefix strtr($wgCookiePrefix"=,; +.\"'\\[""__________");
$old_session session_name(isset($wgSessionName) ? $wgSessionName $wgCookiePrefix '_session');
session_destroy();

// Destroy the cookie!
    
$params session_get_cookie_params();
    
setcookie(session_name(), ''time() - 42000$params['path'], $params['domain'], $params['secure'], $params['httponly']);

// Back to whatever we had (we hope mediawiki).
session_name($old_session);

// Now SMFs turn.
smf_sessionSetup();

// This means we have no SMF session data or unable to find it.
if (empty($_SESSION['session_var']))
return true;

smf_redirectWrapper('logout_url''logout;' $_SESSION['session_var'] . '=' $_SESSION['session_value']);
}

/**
 * Redirect and utilize the SMF register function.
 *
 * @public
 */
function UserRegisterSMF (&$template)
{
smf_sessionSetup();
smf_redirectWrapper('old_url''register');
}

/**
 * Wrapper to configure the SMF session and perform the redirect.
 *
 * @public
 */
function smf_redirectWrapper($session$action) {
global $wgScriptPath$smf_settings;

$page = !empty($_GET['returnto']) ? '?title=' urlencode($_GET['returnto']) . '&' '?';
$_SESSION[$session] = 'http://' $_SERVER['SERVER_NAME'] . $wgScriptPath '/index.php' $page 'board=redirect';

// Do the actual redirect.
header ('Location: ' $smf_settings['boardurl'] . '/index.php?action=' $action);
exit();
}

/**
 * If the user has visited the forum during the browser session
 * then load up the exisiting session. Otherwise start a new
 * session that SMF can use.
 *
 * @public
 */
function smf_sessionSetup()
{
global $wgSessionsInMemcached$wgCookieDomain$smf_settings;

// Clean out the existing session. This should have no affect
// since we are going to redirct the user to the SMF page.
@session_write_close();

// We can guess if wiki is using memcache sessions, so is SMF.
if ($wgSessionsInMemcached)
@ini_set('session.save_handler''memcache');

// Why MediaWiki doesn't store the original.
$old_session session_name();
session_name(ini_get('session.name'));

// Start your engines.
session_start();

// Load up the SMF session and set the redirect URL.
if (isset($_COOKIE[$smf_settings['cookiename']]))
session_decode($_COOKIE[$smf_settings['cookiename']]);
// No exisiting session, create one
else
{
// Grab us a unique ID for SMF.
session_regenerate_id();

// Needed for SMF checks.
$_SESSION['rand_code'] = md5(session_id() . rand());
$_SESSION['USER_AGENT'] = $_SERVER['HTTP_USER_AGENT'];

// Set the cookie.
$data serialize(array(0''0));
setcookie($smf_settings['cookiename'], $datatime() + 3600'/'$wgCookieDomain0);
}

// Restore the old session.
session_name($old_session);
}

// First check if class has already been defined.
if (!class_exists('AuthPlugin'))
require_once "$IP/includes/AuthPlugin.php";

class 
Auth_SMF extends AuthPlugin
{
var $conn 0;

/**
 * Class constructor that will initialize the hooks and database connection.
 */
function Auth_SMF()
{
global $wgSMFLogin$wgHooks$wgDefaultUserOptions;

// Integrate with SMF login / logout?
if (isset($wgSMFLogin) && $wgSMFLogin)
{
$wgHooks['AutoAuthenticate'][] = 'AutoAuthenticateSMF';
$wgHooks['UserLoadFromSession'][] = 'AutoAuthenticateSMF';
$wgHooks['UserLoginForm'][] = 'UserLoginFormSMF';
$wgHooks['UserLogout'][] = 'UserLogoutSMF';
}

// Default some settings we us.
$wgDefaultUserOptions['smf_member_id'] = 0;
$wgDefaultUserOptions['smf_last_update'] = 0;

// Always redirect registration to SMF.
$wgHooks['UserCreateForm'][] = 'UserRegisterSMF';

// Connect to the database.
$this->connect();
}

/**
 * Check whether there exists a user account with the given name.
 * The name will be normalized to MediaWiki's requirements, so
 * you might need to munge it (for instance, for lowercase initial
 * letters).
 *
 * @param $username String: username.
 * @return bool
 * @public
 */
public function userExists($username)
{
global $smf_settings$smf_member_id;

// Check if we did this already recently.
if (empty($smf_settings['debug_wiki']) && isset($_SESSION['smf_uE_t'], $_SESSION['smf_uE']) && time() < ($_SESSION['smf_uE'] + 300))
return $_SESSION['smf_uE'];
$_SESSION['smf_uE'] = time();

$username $this->fixUsername($username);
$request $this->query("
SELECT member_name
FROM 
$smf_settings[db_prefix]members
WHERE id_member = '
{$smf_member_id}'
LIMIT 1"
);

list ($user) = mysql_fetch_row($request);
mysql_free_result($request);

// Play it safe and double check the match.
$_SESSION['smf_uE'] = strtolower($user) == strtolower($username) ? true false;

return $_SESSION['smf_uE'];
}

/**
 * Check if a username+password pair is a valid login.
 * The name will be normalized to MediaWiki's requirements, so
 * you might need to munge it (for instance, for lowercase initial
 * letters).
 *
 * @param $username String: username.
 * @param $password String: user password.
 * @return bool
 * @public
 */
public function authenticate($username$password)
{
global $smf_settings$smf_member_id;

// No id, you must be unauthorized.
if ($smf_member_id == 0)
return false;

$username $this->fixUsername($username);
$request $this->query("
SELECT member_name, passwd
FROM 
$smf_settings[db_prefix]members
WHERE id_member = '
{$smf_member_id}'
AND is_activated = 1
LIMIT 1"
);

list($member_name$passwd) = mysql_fetch_row($request);
mysql_free_result($request);

$pw sha1(strtolower($username) . $password);

// Check for password match, the user is not banned, and the user is allowed.
if($pw == $passwd && $this->isNotBanned($smf_member_id) && $this->isGroupAllowed($username))
return true;

return false;
}

/**
 * Modify options in the login template.
 *
 * @param $template UserLoginTemplate object.
 * @public
 */
public function modifyUITemplate(&$template, &$type)
{
$template->set('usedomain',   false); // We do not want a domain name.
$template->set('create',      false); // Remove option to create new accounts from the wiki.
$template->set('useemail',    false); // Disable the mail new password box.
}

/**
 * Set the domain this plugin is supposed to use when authenticating.
 *
 * @param $domain String: authentication domain.
 * @public
 */
public function setDomain($domain)
{
$this->domain $domain;
}

/**
 * Check to see if the specific domain is a valid domain.
 *
 * @param $domain String: authentication domain.
 * @return bool
 * @public
 */
public function validDomain($domain)
{
return true;
}

/**
* This allows us to disable properties we don't want to allow users to modify
* @param $prop String: property to disallow
* @return bool
* @public
*/
public function allowPropChange($prop '')
{
if ($prop == 'emailaddress')
return false;

return true;
}

/**
 * When a user logs in, optionally fill in preferences and such.
 * For instance, you might pull the email address or real name from the
 * external user database.
 *
 * The User object is passed by reference so it can be modified; don't
 * forget the & on your function declaration.
 *
 * @param User $user
 * @public
 */
public function updateUser(&$user)
{
global $smf_settings$smf_member_id;

// No id, you must be unauthorized.
if ($smf_member_id == 0)
return false;

$username $this->fixUsername($user->getName());
$request $this->query("
SELECT email_address, real_name
FROM 
$smf_settings[db_prefix]members
WHERE id_member = '
{$smf_member_id}'
LIMIT 1"
);

while ($row mysql_fetch_assoc($request))
{
$user->setRealName($row['real_name']);
$user->setEmail($row['email_address']);

$this->setAdminGroup($user);

$user->setOption('smf_last_update'time());
$user->saveSettings();
}
mysql_free_result($request);

return true;
}


/**
 * Return true if the wiki should create a new local account automatically
 * when asked to login a user who doesn't exist locally but does in the
 * external auth database.
 *
 * If you don't automatically create accounts, you must still create
 * accounts in some way. It's not possible to authenticate without
 * a local account.
 *
 * This is just a question, and shouldn't perform any actions.
 *
 * @return bool
 * @public
 */
public function autoCreate()
{
return true;
}

/**
 * Can users change their passwords?
 *
 * @return bool
 */
public function allowPasswordChange()
{
global $wgSMFLogin;

// Only allow password change if not using auto login.
// Otherwise we would need a bunch of code to rewrite
// the SMF login cookie with the new password.
if (isset($wgSMFLogin) && $wgSMFLogin)
return false;

return true;
}

/**
 * Update user information in the external authentication database.
 * Return true if successful.
 *
 * @param $user User object.
 * @return bool
 * @public
 */
public function updateExternalDB($user)
{
return true;
}

/**
 * Check to see if external accounts can be created.
 * Return true if external accounts can be created.
 * @return bool
 * @public
 */
public function canCreateAccounts()
{
return false;
}

/**
 * Add a user to the external authentication database.
 * Return true if successful.
 *
 * @param User $user - only the name should be assumed valid at this point
 * @param string $password
 * @param string $email
 * @param string $realname
 * @return bool
 * @public
 */
public function addUser($user$password$email=''$realname='')
{
return true;
}


/**
 * Return true to prevent logins that don't authenticate here from being
 * checked against the local database's password fields.
 *
 * This is just a question, and shouldn't perform any actions.
 *
 * @return bool
 * @public
 */
public function strict()
{
return true;
}

/**
 * When creating a user account, optionally fill in preferences and such.
 * For instance, you might pull the email address or real name from the
 * external user database.
 *
 * The User object is passed by reference so it can be modified; don't
 * forget the & on your function declaration.
 *
 * @param $user User object.
 * @param $autocreate bool True if user is being autocreated on login
 * @public
 */
public function initUser(&$user$autocreate false)
{
global $smf_settings$smf_member_id;

// No id, you must be unauthorized.
if ($smf_member_id == 0)
return false;

// Check what time we last did this.
$last_update $user->getOption('smf_last_update'0);
if (!empty($last_update) && time() > $last_update 900)
return true;

$username $this->fixUsername($user->getName());
$request $this->query("
SELECT id_member, email_address, real_name
FROM 
$smf_settings[db_prefix]members
WHERE id_member = '
{$smf_member_id}'
LIMIT 1"
);

while ($row mysql_fetch_assoc($request))
{
$user->setRealName($row[real_name]);
$user->setEmail($row[email_address]);

// Let wiki know that their email has been verified.
$user->mEmailAuthenticated wfTimestampNow(); 

$this->setAdminGroup($user);

$user->setOption('smf_last_update'time());
$user->saveSettings();
}
mysql_free_result($request);

return true;
}

/**
 * If you want to munge the case of an account name before the final
 * check, now is your chance.
 *
 * @public
 */
public function getCanonicalName($username)
{
/**
 * wiki converts username (john_doe -> John doe)
 * then getCanonicalName is called
 * user not in wiki database call userExists
 * lastly call authenticate
 */
return $username;
}

/**
 * The wiki converts underscores to spaces. Attempt to work around this
 * by checking for both cases. Hopefully we'll only get one match.
 * Otherwise the first registered SMF account takes priority.
 *
 * @public
 */
public function fixUsername($username)
{
global $smf_settings$smf_member_id;
static $fixed_name '';

// No space no problem.
if(strpos($username' ') === false)
return $username;

// We may have done this once already.
if (!empty($fixed_name))
return $fixed_name;

// Look for either case sorted by date.
$request $this->query("
SELECT member_name 
FROM 
$smf_settings[db_prefix]members
WHERE member_name = '
{$username}
OR member_name = '" 
strtr(strtr($username, array(' ' => '_''[' => '='']' => '"''|' => '&''#' => '\\')), array('{' => '==''}' => '""')) . "'
ORDER BY date_registered ASC
LIMIT 1"
);

list($user) = mysql_fetch_row($request);
mysql_free_result($request);

// No result play it safe and return the original.
$fixed_name $user;
return !isset($user) ? $username $user;
}

/**
 * Check to see if the user is banned partially
 * restricting their ability to post or login.
 *
 * @public
 */
public function isNotBanned($id_member)
{
global $smf_settings$smf_member_id;

// Perhaps we have it cached in the session.
if (empty($smf_settings['debug_wiki']) && isset($_SESSION['smf_iNB_t'], $_SESSION['smf_iNB']) && time() < ($_SESSION['smf_iNB_t'] + 900))
return $_SESSION['smf_iNB'] ? true false;

$request $this->query("
SELECT id_ban
FROM 
$smf_settings[db_prefix]ban_items AS i
LEFT JOIN 
$smf_settings[db_prefix]ban_groups AS g
ON (i.id_ban_group = g.id_ban_group)
WHERE i.id_member = '
{$id_member}'
AND (g.cannot_post = 1 OR g.cannot_login = 1)"
);

$banned mysql_num_rows($request);
mysql_free_result($request);

$_SESSION['smf_iNB_t'] = time();
$_SESSION['smf_iNB'] = $banned false true;

return $_SESSION['smf_iNB'];
}

/**
 * Check to see if the user is able to login.
 *
 * @public
 */
public function canLogin()
{
global $wgSMFDenyGroupID$user_settings;

if (empty($smf_settings['debug_wiki']) && isset($_SESSION['smf_cL_t'], $_SESSION['smf_cL']) && time() < ($_SESSION['smf_cL_t'] + 900))
return $_SESSION['smf_cL'] ? true false;

$_SESSION['smf_iNB_t'] = time();
$_SESSION['smf_cL'] = true;

if (!empty($wgSMFDenyGroupID) && array_intersect($user_settings['smf_groups'], $wgSMFDenyGroupID) != array())
$_SESSION['smf_cL'] = false;

return $_SESSION['smf_cL'];
}

/**
 * Check to see if the user should have sysop rights.
 * Either they are an administrator or are in one
 * of the define groups.
 *
 * To save database queries the fixed username is used.
 *
 * @public
 */
public function setAdminGroup(&$user)
{
global $wgSMFAdminGroupID$user_settings;
static $already_done false;

// Loop prevention.
if ($already_done)
return;
$already_done true;

// Check if we did this already recently.
if (empty($smf_settings['debug_wiki']) && isset($_SESSION['smf_sAG']) && time() < ($_SESSION['smf_sAG'] + 900))
return;
$_SESSION['smf_sAG'] = time();

// Administrator always get admin rights.
if (!in_array(1$wgSMFAdminGroupID))
$wgSMFAdminGroupID[] = 1;

// Search through all groups, if match give them admin rights.
if (!empty($wgSMFAdminGroupID) && array_intersect($user_settings['smf_groups'], $wgSMFAdminGroupID) != array())
{
if (!in_array("sysop"$user->getEffectiveGroups()))
$user->addGroup("sysop");

return;
}

// No go! Make sure they are not a sysop.
if (in_array("sysop"$user->getEffectiveGroups()))
$user->removeGroup("sysop");
return;
}


/**
 * Check to see if the user is allowed to log in.
 * Either they are an administrator or are in one
 * of the define groups.
 *
 * @public
 */
public function isGroupAllowed($username, &$user)
{
global $wgSMFGroupID$wgSMFDenyGroupID$wgSMFSpecialGroups$user_settings;

// Check if we did this already recently.
if (empty($smf_settings['debug_wiki']) && isset($_SESSION['smf_iSA_t'], $_SESSION['smf_iSA']) && time() < ($_SESSION['smf_iSA_t'] + 900))
return $_SESSION['smf_iSA'];
$_SESSION['smf_iSA_t'] = time();

// This allows us to wiki assign groups based on SMF member groups.
if (!empty($wgSMFSpecialGroups))
{
// This is done for speed purposes when working with a large array.
$temp_groups explode(','$user_settings['additional_groups']);

foreach ($wgSMFSpecialGroups as $smf_group => $wiki_group)

if (in_array($smf_group$temp_groups) && !in_array($wiki_group$user->getEffectiveGroups()))
{
$user->addGroup($wiki_group);
$group_added true;
}
}
}

// Do they happen to be in a deny group?
if (!empty($wgSMFDenyGroupID) && array_intersect($user_settings['smf_groups'], $wgSMFDenyGroupID) != array())
$_SESSION['smf_iSA'] = false;
// This comes from the group add above.
elseif (!empty($group_added))
$_SESSION['smf_iSA'] = true;
// No limitations.
elseif (empty($wgSMFGroupID))
$_SESSION['smf_iSA'] = true;
// Search through all groups, if match give them admin rights.
elseif (!empty($wgSMFGroupID) && array_intersect($user_settings['smf_groups'], $wgSMFGroupID) != array())
$_SESSION['smf_iSA'] = true;
else
// No go!
$_SESSION['smf_iSA'] = false;

return $_SESSION['smf_iSA'];
}

/**
 * Connect to the database. Use the settings from smf.
 *
 * {@source}
 * @return resource
 */
public function connect()
{
global $smf_settings;

// Connect to database.
$this->conn = @mysql_pconnect($smf_settings['db_server'], $smf_settings['db_user'],
  $smf_settings['db_passwd'], true);

// Check if we are connected to the database.
if (!$this->conn)
$this->mysqlerror("SMF was unable to connect to the database.<br />\n");

// Select database: this assumes the wiki and smf are in the same database.
$db_selected = @mysql_select_db($smf_settings['db_name'], $this->conn);

// Check if we were able to select the database.
if (!$db_selected)
$this->mysqlerror("SMF was unable to connect to the database.<br />\n");

// As of now, we don't suport anything other than UTF8 with SMF.
mysql_query('SET NAMES UTF8'$this->conn);
}

/**
 * Run the query and if applicable display the mysql error.
 *
 * @param string $query
 * @return resource
 */
public function query($query)
{
$request mysql_query($query$this->conn);

if(!$request)
$this->mysqlerror('Unable to view external table.');

return $request;
}

/**
 * Display an error when a mysql error is found.
 *
 * @param string $message
 * @access public
 */
public function mysqlerror($message)
{
global $wgSMFDebug;

echo $message "<br /><br />\n\n";

// Only if we are debugging.
if ($wgSMFDebug)
echo 'mySQL error number: 'mysql_errno(), "<br />\n"'mySQL error message: 'mysql_error(), "<br /><br />\n\n";

exit;
}
}

// Set the default options for a few settings we add.
// These are here as they do not need to be configurable.
$wgDefaultUserOptions['smf_member_id'] = 0;
$wgDefaultUserOptions['smf_last_update'] = 0;
$wgHooks['UserSaveOptions'][] = 'wfProfileSMFID';

// This prevents your SMF member ID from being lost when preferences are saved.
function wfProfileSMFID($user, &$saveOptions)
{
global $ID_MEMBER;

// Preserve our member id.
if (empty($saveOptions['smf_member_id']) && !empty($user->mOptionOverrides['smf_member_id']))
$saveOptions['smf_member_id'] = $user->mOptionOverrides['smf_member_id'];

// Still empty, maybe we can save the day.
if (empty($saveOptions['smf_member_id']) && !empty($ID_MEMBER))
$saveOptions['smf_member_id'] = (int) $ID_MEMBER;

// Note: We do not protect smf_last_update from being lost since we disabled
// changing emails means it would be lost and causes an error.  This way the
// Auth will restore it on the next page load (ie right after the page save).

return true;
}

Code: (Relevant LocalSettings.php) [Select]
# This requires a user be logged into the wiki to make changes.
$wgGroupPermissions['*']['edit'] = false; // MediaWiki Setting

# If you experience the issue where you appear to be logged in
# eventhough you are logged out then disable the page cache.
#$wgEnableParserCache = false;
#$wgCachePages = false;

# SMF Authentication
# To get started you only need to configure wgSMFPath.
# The rest of the settings are optional for advanced features.

# Relative path to the forum directory from the wiki
# Do not put a trailing /
# Example: /public_html/forum and /public_html/wiki -> ../forum
$wgSMFPath = "../forums";

# Use SMF's login system to automatically log you in/out of the wiki
# This works best if you are using SMF database sessions (default).
# Make sure "Use database driven sessions" is checked in the
# SMF Admin -> Server Settings -> Feature Configuration section
# NOTE: Make sure to configure the wgCookeDomain below
$wgSMFLogin = true;
$wgCookieDomain = 'mydomain.com';

# Members in these SMF groups will not be allowed to sign into wiki.
# This is useful for denying access to wiki and a easy anti-spam
# method.  The group ID, which can be found in the url (;group=XXX)
# when viewing the group from the administrator control panel.
#$wgSMFDenyGroupID = array(4);

# Grant members of this SMF group(s) access to the wiki
# NOTE: The wgSMFDenyGroupID group supersedes this.
#wgSMFGroupID = array(2);

# Grant members of this SMF group(s) wiki sysop privileges
# NOTE: These members must be able to login to the wiki
#$wgSMFAdminGroupID = array(1, 3);

# SMF to wiki group translation.  This allows us to assign wiki groups
# to those in certain SMF groups.
#$wgSMFSpecialGroups = array(
# // SMF Group ID => Wiki group name.
# 5 => 'autoconfirmed',
#);

# THIS MUST BE ADDED.  This prevents direct access to the Auth file.
define('SMF_IN_WIKI', true);

# Load up the extension
require_once "$IP/extensions/Auth_SMF.php";
$wgAuth = new Auth_SMF();

Shadra on July 31, 2015, 04:54:14 AM said
Hey!

I've some trouble with SMF_Auth, SMF and MW, maybe it's just a little thing, but who knows?
I use this versions of software: SMF 2.0.10, SMF_Auth 1.14 and MW 1.25.1

My SMF_Auth part of the localsettings.php looks like that:
Code: [Select]
# If you experience the issue where you appear to be logged in
# eventhough you are logged out then disable the page cache.
#$wgEnableParserCache = false;
#$wgCachePages = false;

# SMF Authentication
# To get started you only need to configure wgSMFPath.
# The rest of the settings are optional for advanced features.

# Relative path to the forum directory from the wiki
# Do not put a trailing /
# Example: /public_html/forum and /public_html/wiki -> ../forum
$wgSMFPath = "../forum";

# Use SMF's login system to automatically log you in/out of the wiki
# This works best if you are using SMF database sessions (default).
# Make sure "Use database driven sessions" is checked in the
# SMF Admin -> Server Settings -> Feature Configuration section
# NOTE: Make sure to configure the $wgCookieDomain below
$wgSMFLogin = true;
$wgCookieDomain = '.mydomain.com';

# Members in these SMF groups will not be allowed to sign into wiki.
# This is useful for denying access to wiki and a easy anti-spam
# method.  The group ID, which can be found in the url (;group=XXX)
# when viewing the group from the administrator control panel.
#$wgSMFDenyGroupID = array(4);

# Grant members of this SMF group(s) access to the wiki
# NOTE: The wgSMFDenyGroupID group supersedes this.
#wgSMFGroupID = array(2);

# Grant members of this SMF group(s) wiki sysop privileges
# NOTE: These members must be able to login to the wiki
#$wgSMFAdminGroupID = array(1, 3);

# SMF to wiki group translation.  This allows us to assign wiki groups
# to those in certain SMF groups.
#$wgSMFSpecialGroups = array(
#  // SMF Group ID => Wiki group name,
# 5 => 'autoconfirmed'
#);

# THIS MUST BE ADDED.  This prevents direct access to the Auth file.
define('SMF_IN_WIKI', true);

# Load up the extension
require_once "$IP/extensions/Auth_SMF.php";
$wgAuth = new Auth_SMF();

My SMF server settings are:
Local storage: off
Subdomain cookies: off
Database session: on
Browser caching: on


I know in my localsetting I set the cookie domain to ".mydomain.com". At first I tried "mydomain.com", but it doesn't work. SMF always tell me something about "session and cookie", when I try to login from my wiki.

The folder structure is this:
mydomain.com/folder/forum/
mydomain.com/folder/wiki/
No subdomains!

When I click on "login" at my wiki I get redirected to my SMF login page, when I entered my username and password I'm loged in, but don't get redirected to my wiki. If I change the URL to my wiki I'm loged out - so nothing happend. I think it's a cookie/session problem, but all things I tried don't work.
I tried in the localsettings.php this combinations of cookie names: mydomain.com - .mydomain.com - mydomain.com/folder/ - .mydomain.com/folder/
Now I have no idea what I can do :(

Can someone help me, please?
Illori on July 31, 2015, 05:06:03 AM said
even though your wiki is not in a sub domain i believe you need to have subdomain cookies enabled.

also i dont believe that after you log in on the forum there is a redirect back to the wiki as the forum does not know you were on the wiki.
Shadra on July 31, 2015, 05:15:49 AM said
You are right, the SMF doesn't know something about the wiki, I add a new Tab and it's okay.

I tested the thing with subdomain cookies and I can login at my SMF without any error. But the MW give me new warnings: "session_name() [function.session-name.php]: session.name cannot be numeric or empty " in /home/restofthepath/folder/wiki/extensions/Auth_SMF.php on line 333" and "session_destroy () [function.session-destroy.php]: Trying to destroy uninitialized session in /home/restofthepath/folder/wiki/extensions/Auth_SMF.php on line 334"

This is the function
Code: [Select]
function UserLogoutSMF (&$user)
{
global $wgCookiePrefix, $wgSessionName;

// Log them out of wiki first.
$user->doLogout();

// Destory their session.
$wgCookiePrefix = strtr($wgCookiePrefix, "=,; +.\"'\\[", "__________");
$old_session = session_name(isset($wgSessionName) ? $wgSessionName : $wgCookiePrefix . '_session');
session_destroy();

// Destroy the cookie!
    $params = session_get_cookie_params();
    setcookie(session_name(), '', time() - 42000, $params['path'], $params['domain'], $params['secure'], $params['httponly']);

// Back to whatever we had (we hope mediawiki).
session_name($old_session);

// Now SMFs turn.
smf_sessionSetup();

// This means we have no SMF session data or unable to find it.
if (empty($_SESSION['session_var']))
return true;

smf_redirectWrapper('logout_url', 'logout;' . $_SESSION['session_var'] . '=' . $_SESSION['session_value']);
}

Line 333 and 334 are
   $old_session = session_name(isset($wgSessionName) ? $wgSessionName : $wgCookiePrefix . '_session');
   session_destroy();


I changed in the localsettings.php the domain cookie from ".mydomain.com" to "mydomain.com" and after reload the wiki I got only the first warning with line 333.
Shadra on August 03, 2015, 07:12:51 AM said
Sorry for double post, but I tried some other things and they work. Actually I've the same problem like ekynox a few months earlier.

...cut from shadra...

Used another smf account (not admin), it still do not redirect back to wiki, but I'm logged with that account inside mediawiki.

So ... why my main smf admin account is not accepted ?
...cut from shadra...

So all members of my board can now start spaming the wiki, without me as admin/sysop.
I uncommented in the localsettings.php this two values:
$wgSMFGroupID = array(2);
$wgSMFAdminGroupID = array(1, 3);

But nothing works, my latin is at the end :(
But one thing is now clear: it's no longer a cookie problem, but something else is wrong or so.
cody on December 07, 2015, 01:18:43 PM said
Has anybody been able to get this to work on mediawiki 1.25.x?

I'm getting the same session.name cannot be numeric or empty  error and not being able to logon
Shadra on December 14, 2015, 11:14:20 AM said
As I wrote a post before yours:
I uncommented in the localsettings.php this two values:
$wgSMFGroupID = array(2);
$wgSMFAdminGroupID = array(1, 3);

And only "not administrator's" can use the mediawiki. I couldn't fix it, that I - as admin - can use the bridge as well and nobody from the SMF team cares about the broken bridge (very sad). eKyNoX had the problem as well and wrote about it in march 2015. Nobody has done something so far and I don't think it will happen any time soon.
You see, since august - my last post - nobody respond. Hopefully this will help you a little bit, but maybe you can fix it and publish it to the community. :)

cheers Shadra
SleePy on December 24, 2015, 07:06:23 PM said
Shadra,
If you use $wgSMFGroupID, you need to specify all group ids that can access the wiki.  In SMF by default groups that have to exist:
1 = Administrators
2 = Global Moderators
3 = Moderators (pseudo type group that is only autofilled when viewing a board though)
After that you have the groups it creates by default with IDs 4 to 8 for some post based groups.

In the example, $wgSMFGroupID uses group ID 2, which are Global Moderators.  So only those who are Global Moderators will be able to use the wiki if you follow the example.

We don't make use of $wgSMFGroupID here, we actually use $wgSMFDenyGroupID and use the same group id provided in the example (4).  This prevents users with less than 10 posts from being able to login/modify the wiki and we do this as it offers us the best spam control on our wiki.  We usually can find and stop a spammer on the forums before they reach 10 posts, legit users usually can get past this in a short time and then are free to modify the wiki.
Shadra on January 06, 2016, 04:50:00 AM said
Hi SleePy

I checked my MW Settings and set them to:
Code: [Select]
# Members in these SMF groups will not be allowed to sign into wiki.
# This is useful for denying access to wiki and a easy anti-spam
# method.  The group ID, which can be found in the url (;group=XXX)
# when viewing the group from the administrator control panel.
#$wgSMFDenyGroupID = array(4);

# Grant members of this SMF group(s) access to the wiki
# NOTE: The wgSMFDenyGroupID group supersedes this.
$wgSMFGroupID = array(4);

# Grant members of this SMF group(s) wiki sysop privileges
# NOTE: These members must be able to login to the wiki
$wgSMFAdminGroupID = array(1, 2);

So all users, including myself, should now have access to the wiki, but I've still the problem that my session don't work.

Warning: session_name() [function.session-name.php]: session.name cannot be a numeric or empty '' /wiki/extensions/Auth_SMF.php on line 333
Warning: session_destroy() [function.session-destroy.php]: Trying to destroy uninitialized session in ' /wiki/extensions/Auth_SMF.php on line 333

Code: [Select]
function UserLogoutSMF (&$user)
{
global $wgCookiePrefix, $wgSessionName;

// Log them out of wiki first.
$user->doLogout();

// Destory their session.
$wgCookiePrefix = strtr($wgCookiePrefix, "=,; +.\"'\\[", "__________");
$old_session = session_name(isset($wgSessionName) ? $wgSessionName : $wgCookiePrefix . '_session');
session_destroy();

// Destroy the cookie!
    $params = session_get_cookie_params();
    setcookie(session_name(), '', time() - 42000, $params['path'], $params['domain'], $params['secure'], $params['httponly']);

// Back to whatever we had (we hope mediawiki).
session_name($old_session);

// Now SMFs turn.
smf_sessionSetup();

// This means we have no SMF session data or unable to find it.
if (empty($_SESSION['session_var']))
return true;

smf_redirectWrapper('logout_url', 'logout;' . $_SESSION['session_var'] . '=' . $_SESSION['session_value']);
}

I'm loged in on my board, but as user that doesn't matter, because I'm automaticly loged in on the wiki, too. But not as admin.
wintstar on February 13, 2016, 12:49:58 PM said
I have a problem with this bridge. I have, I think, already tried all options. In the MediaWiki Forum members are not detected. It can not log any in the MediaWiki. There are only the standard groups of the Forum.
The Forum and the MediaWiki lying on the sub domain wwx.unterdomain.hauptdomain.dev.
The root of the MediaWiki is as subfolder of the root of the forum. Both use the same database.

smf-mw-auth from here => https://github.com/SimpleMachines/smf-mw-auth
SMF 2.0.11
MediaWiki 1.26.2
PHP     5.5.31 (cgi-fcgi)
MySQL     5.5.47-log

Setting of the Forum
Enable local storage of cookies = no active
HelpUse subdomain independent cookies = no active
Use database driven sessions = active
 
and tested with
Enable local storage of cookies = active
HelpUse subdomain independent cookies = no active
Use database driven sessions = active
 
and tested with
Enable local storage of cookies = no active
HelpUse subdomain independent cookies = active
Use database driven sessions = active

and tested with
Enable local storage of cookies = active
HelpUse subdomain independent cookies = active
Use database driven sessions = active 

Setting of the MediaWiki
# This requires a user be logged into the wiki to make changes.
$wgGroupPermissions['*']['edit'] = true; // MediaWiki Setting

and tested with
# This requires a user be logged into the wiki to make changes.
#$wgGroupPermissions['*']['edit'] = true; // MediaWiki Setting

# Use SMF's login system to automatically log you in/out of the wiki
# This works best if you are using SMF database sessions (default).
# Make sure "Use database driven sessions" is checked in the
# SMF Admin -> Server Settings -> Feature Configuration section
# NOTE: Make sure to configure the $wgCookieDomain below
#$wgSMFLogin = true;
$wgCookieDomain = 'hauptdomain.dev';
and tested it with
$wgCookieDomain = 'unterdomain.hauptdomain.dev';
Study Force on July 07, 2017, 03:06:07 PM said
When installing mediawiki, does it have to be in the same database as SMF?
SleePy on July 07, 2017, 08:06:38 PM said
It does not.  The auth will however use SMF's database credentials to authenticate a user.  Their is no need for cross database permissions.
Study Force on July 09, 2017, 11:38:59 AM said
Thank you for clarifying. I tried installing mediawiki 1.26, but they have a different system for calling extensions. Where can I find the updated version, the json file, required to install this extension?

The old method of requiring a file via localsettings.php changed after 1.25, I believe.
SleePy on July 09, 2017, 09:36:18 PM said
You can still use the old LocalSettings.php modifications.  I haven't had time to update it properly to use the json requirements.
Study Force on July 09, 2017, 11:37:41 PM said
You can still use the old LocalSettings.php modifications.  I haven't had time to update it properly to use the json requirements.


Hi SleePy, you can't from when I tried. You'd need to create a new JSON file for the extension.

I went ahead and used the 1.24.6 version anyway. If you get a chance please let us know
SleePy on July 11, 2017, 08:50:53 PM said
If you look at our wiki, we are using 1.27.3 and still loading the integration via LocalSettings.php modifications.
XanoKais on July 27, 2017, 10:06:16 AM said
Just a note to those who may be stumbling in getting the cookie to carry over (MediaWiki continuously showing log in).  I was able to resolve it by pulling down the July 2014 version of the Auth_SMF.php file and using that rather than the Fix #12 version from July 2017.

This was on SMF 2.0.14 and MW 1.27.3 LTS. 
Study Force on July 28, 2017, 02:42:17 PM said
Thanks ^^
nemwar on October 23, 2017, 03:55:14 AM said
Hello,

i can't get the bridge to work,

I've installed the last version of SMF 2 (2.0.14) and the MediaWiki 1.29.1 (incl. the bluespice add-on).

After editing all files for the bridge i can't login into the wiki.
It didn't work for the admin and also for a new member i created for testing reason.

It would be great if somebody could help me.

Regards
NemWar
Marketing Hallo Welt! on October 24, 2017, 06:43:27 AM said
Hello Nemwar,

BlueSpice doesn't support MediaWiki 1.29.
It supports the latest Long Term Support (LTS) version 1.27. That is most probably the reason.

You can find all system requirements at the BlueSpice Helpdesk (Setup Portal).

The next supported LTS version will be 1.31, which is announced by the Wikimedia Foundation for 2018.

Best regards!
Richard