Topic: SMF MediaWiki integration released

[planet9]

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]

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]

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.


[Liam_michael]

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]

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]

---
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]

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...

[Liam_michael]

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]

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]

help me please

http://www.simplemachines.org/community/index.php?topic=475177.0

[Liam_michael]

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]

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]

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]

Are you using the latest version of mediawiki?

[Nutbolt]

Yup, using the latest version of MW and SMF.

[Attoy]

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]

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]

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]

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 )...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]

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 )...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?