Hey, I've been using the WordPress integration method described here which worked wonderfully. However, as of 2.5, WordPress now uses phpass and salts the hashes, as well as encrypts cookies (Described here towards the bottom). I've already tried to figure out how to modify the implementation but I just can't figure it out. I believe I have to use either wp_hash_password or wp_check_password. I don't care if the auto-authentication works (It might not because that involved cookies, and WordPress changed the way it does cookies). There is a plugin to revert to the original plain md5 hashing method here here, but I would prefer the extra layer of security. Here are the definitions of wp_check_password() and wp_hash_password().

I would appreciate if anyone has any answers or could help in any way with this, as I would like to keep Vanilla forums. I don't mind doing this myself, I just need some type of guidance. SirNot, please help :(

I forgot to mention. To use WordPress functions such as the ones I mentioned earlier, wp_check_password() and wp_hash_password(), one must follow the procedure outlined here. This will allow one to call functions as if they were working on WordPress files themselves.

@rmccue: If you do write one eventually, please let me know! I'd be glad to help if you need anything, by the way.

I've updated the WordpressAuthenticator written by Mark.

Please consider:

• I'm currently using the plugin to store passwords with md5 encryption.
• You need to login from wordpress at least one time to let it create the "secret" option that is the secret salt (or at least verify that the option exists!).
• You need to specify a $Configuration['WP_SECRET_KEY'] to match exactly the SECRET_KEY defined in wp-config.php
• This is highly experimental!

The previous version uses two cookies, one to store the plain username and one to store che double-md5-ed password. So to get the identity it verifies the stored username and password with the ones in the cookies.
In this version as long as I've got this right it uses only one cookie to store a string made by the username, the expiration time (I've set this to one hour) and a hash.
So Vanilla has to verify this hash.
I'm concerned to not weak the security in a way I've not understood, so, please, may you confirm this?

I've set up a gdoc with the source, but tell me if there is a better way to share it (I can send the source to Mark if needed).

The source: http://docs.google.com/View?docid=dhg8h5q9_1dmb7m967

Thanks!

Mic

You're right we've done the same thing: fast and effective. :)
I've only forgotten to remove a couple not used variables from the custom version of the file I'm using in my webapp.

So I assume that this is the right way and we're not weakening the wp security.

Mic

Yes rmccue, you're right.
But I was only referring to the new cookie management.
I know using that plugin (I didn't write) is reverting to the old md5 password system.

The code I and mafro wrote is about the way Wordpress 2.5 is using the cookie to mantain the authentication and my concern was only about that.

I think you can use the wp login form with the new passowrd system and, after the authentication, with the modified WordpressAuthenticator file, the user should still logged into vanilla.
I've not tested it thought.

I hope someone will come out with the modification you need.

Silkjaer,

have you checked if in your wp option table there is the "secret" option?
Have you specified a $Configuration['WP_SECRET_KEY'] to match exactly the SECRET_KEY defined in wp-config.php?

Given those, it should work.
Let me know.

@micz: Thanks man I really appreciate it. I noticed that you are using the MD5 hash plugin for WordPress. This is great since it at least works, but it'd be better if we could make use of the new security features in WordPress. Someone was kind enough to provide a working fix for the WordPress to phpBB3 bridge, WP-United. I think that the method they used could be implemented into the Vanilla bridge. What I mean by this is we can see how they modified the existing code (Since it operated in the same manner as this bridge, the whole hashing of passwords, storing of cookies, etc.) and modify ours respectively. I will try to do this myself but I don't know just how right I could do it. I have provided you with the information you'll need though, I believe.

Thanks again micz, I really appreciate even this fix. I would definitely appreciate a fix that makes use of the new features though. Like I've said, to be able to use the WordPress functions, you'll want to do what is outlined here.

Alright then. So the fix that micz provided is mainly to fix the cookie handling? Because it seems that why (Else why still use the MD5 Hash plugin). I'm fine with that, it's working perfectly fine now (When I go to the forums I am logged in). Thanks.

oh! perhaps this is what caused my problem...

I hope that the solutions soon: D

So I did the changes to my Wordpress bridge to make this work with 2.5.1. Unfortunately my modded wordpress/forum effort is so far different from a default install that I can't be sure that mine will work for any of you as is.

Hence, I quickly did a (very slightly) modified version of micz's code from above which you should hopefully be able to drop into a default install. Find it here:
http://docs.google.com/Doc?id=dcf7jf9g_1gcjpktgg

If anyone would care to test this, ill have a look if you find any problems. If I had more time i'd do a default install and test myself!

Cheers all
mafro

Ok I just did a default install and integration of WP 2.5.1 and Vanilla 1.1.4. I followed essentially the same steps as you did, but to clarify also:

- I use the wp_users table, with the additional columns for Vanilla.
- I don't use the WP login form. I redirect any requests for wp-login.php onto the Vanilla login page (see some code below). This shouldn't really make any difference however!

I tried the modded code I posted previously, and yes it didn't work. Ill have a look at working out why later - I don't have time now. But, I did drop in my WordpressAuthenticator (posted originally above) and it worked fine.

Try this code as a drop in replacement and let me know how you get on.

http://docs.google.com/View?docid=dcf7jf9g_2dw92g6z8

For reference this is the excerpt from my conf/database.php:

// Map to the wordpress user table
$DatabaseTables['User'] = 'wp_users';

// Map existing wordpress columns to Vanilla
$DatabaseColumns['User']['UserID'] = 'ID';
$DatabaseColumns['User']['UserLogin'] = 'user_login';
$DatabaseColumns['User']['Name'] = 'display_name';
$DatabaseColumns['User']['Password'] = 'user_pass';
$DatabaseColumns['User']['Email'] = 'user_email';
$DatabaseColumns['User']['DateFirstVisit'] = 'user_registered';
And here's the little bit of redirect code I added to wp-login.php. If you use this, set ROOT_URL to the location of your wordpress install (prob just / on live server).

define("ROOT_URL", "/wordpress251/");

if(($_GET['action'] == "logout") || ($_GET['loggedout'] == "true")) {
//redirect Wordpress logout requests to home
$return_url = ROOT_URL;

}else if(strlen($_SERVER['QUERY_STRING']) == 0) {
//redirect Wordpress login with no return_url to home
$return_url = ROOT_URL;

}else if(strpos($_SERVER['REQUEST_URI'], "wp-login.php?redirect_to=") > 0) {
//crop off the Wordpress wp-login redirect
$return_url = str_replace(ROOT_URL."wp-login.php?redirect_to=", "", $_SERVER['REQUEST_URI']);
$return_url = urldecode($return_url);

}else{
$return_url = $_SERVER['REQUEST_URI'];
}

//dont use Wordpress login
header("location: forum/people.php?PageAction=SignOutNow&ReturnUrl=".$return_url);
exit;
mafro

Sorry for this late answer. I've updated my code, you'll find it at the usual url: http://docs.google.com/View?docid=dhg8h5q9_1dmb7m967

Please, report any problem.
Thanks.

@circuit I've tested it locally on my pc and it works fine. I think it could be better also for you to test this script locally before use it in production on your live site.
Regards.

OMG hooray! It works. I've only tested locally, but it seems to be pretty solid. I'm not using the login re-direct; I'll have to try that, too.

Thank you mafro, micz, and everyone else.

UPDATE: I can't get the login redirect to work reliably.
@mafro: In your instructions, you say you "added" the redirect code to wp-login.php. Where exactly did you add it? I'm not a very sharp programmer, so maybe I put in the wrong place...

@mafro: Thanks for the clarification on the placement of the redirect code. The problem I'm having is that I still can't seem to directly access my WP admin. If I go /wordpress/wp-admin.php, I'm redirected to the Vanilla login as expected, but then after logging in, I'm shown Vanilla's two options:

You are signed in
* Click here to continue to the discussions
* Click here to continue to the categories

In other words, I am not taken to the WP admin, which was my original destination. I can, of course, type in the address again, and I will be taken there, but that will be a bit confusing for some of my users, I think.

(I'm having other problems, too. But that is my primary issue now.)

Right, my secret keys all match. I cleared out my cache and started over, and here's what's happening now. (It's slightly different, but maybe it sheds light on things):

1) I hit the front page of your site - /wordpress/ and are currently not logged in.
2) I navigate to /wordpress/wp-admin/
3) I am redirected to /wordpress/forum/people.php?PageAction=SignOutNow&ReturnUrl=/~username/wordpress/wp-admin/
4) I login and get a 404 error

I think the problem lies in the ReturnUrl parameter including my username in the path. But I don't know how to change that. (As I said before, I'm a horrible programmer. :-) )

EDIT: Oh, wow, I didn't realize how easy it was to simply change the username through the database. I didn't do this before because I thought it'd blow up or something, but it worked :D

I've tried to implement this a few times using Vanilla 1.1.4 and WP 2.5.1 (using my old install and fresh installs), but it's just not working for me :(
The secret keys match, I'm using the right db mappings etc. What happens, is that I can use the Wordpress.Authenticator to login via Vanilla, and it will log me into Wordpress, but not into Vanilla. They're both running on the same domain, one is /blog/ and the other is /forum/, so I can't work out what the problem is.

Any ideas/suggestions would be much appreciated

wordpress may have similar settings that need fixed. look in to it.

get rid of the "/x" portion of the setting, and see if that fixes it

Man, I'd pay $50 to someone who writes some kind of a plugin or something that makes this whole Vanilla/WP integration work. Seems like we're all close, but not quite there...

(I'm serious about the $50, by the way.) :-)

This thread has been incredibly helpful. Thanks to everyone who has had input on resolving various problems.

Now I have a quick question that perhaps someone will have some insight on...

I have wordpress and vanilla installed on one server, and I'm moving everything over to a second server with fresh installs and an integrated database, then importing the data over... The first hurdle is just about complete (the integration) except for a couple of quirks that I've noticed. (please bear with me, I'm still a bit of a database n00b)

I followed all of the instructions I could find for the integration and was able to login to wordpress as Admin and then navigate to the forum and stay logged in as Admin - first success! Then I took a test user account on my old vanilla forum and manually copied/pasted the various fields over to the new wp_users table (tedious, I know - but I only have about a dozen user accounts so I figure it's not too bad and I'll learn something in the process). I realized that there's another table that wordpress needs - the wp_usermeta to set the First/Last name and access type. No biggie. I logged in as Admin and set that information there, and then was able to login as the migration test user and everything was kosher. I could navigate to the forum and post a new topic and everything is working fine. However, I saw some strange behavior.

Now, vanilla is using the wp_users table for all of its information. The instructions walk you through creating the extra columns for the info that vanilla uses/needs, but wordpress doesn't have there. However, in this table there are first/last name columns where vanilla gets that information from for the vanilla profile. Yet wordpress gets this information from the wp_usermeta table.

That's a bit frustrating. So my users have to go into 2 places to update/set their first/last name? Does anyone know of a way to tell vanilla to just use the wordpress data from the other table? There's gotta be a simpler way than I'm thinking of, because right now the only thing I can think of is to setup a cron job to run and compare the fields and make them match so there's no discrepancies (which is a bit ridiculous).

I know this isn't any help, but I just wanted to say that I've had similar problems, elorg. I've done probably half a dozen fresh installs, and I get different results every time. Obviously, I'm making small errors along the way, but figuring out where is difficult when there are so many opportunities for small errors.

I'm about to give up on this altogether. Which sucks, because I love Vanilla.

Well I'll be damned. It was the wordpress table prefix rename? I just reinstalled ... countless times. If I leave the wordpress table prefix to wp_ it works. If I rename it before I even begin the migration - or anywhere in between - it stops allowing the users' login to pass from wordpress to vanilla.

If you rename the tables, where do you need to update in vanilla?
database.php
People.Class.WordpressAuthentication.php

Anywhere else?

I realized that last night I was able to post a reply to an existing discussion. Today, I'm no longer able to. That certainly makes things interesting.