[WIP] WordPress 3.0+ / SMF 2.0 RC4+ User Integration

[SlammedDime]

If that is showing when visiting your wordpress site, then the php code for the salts/keys weren't copied correctly to your wp-config.php file.

[Ken.]

I copied and pasted the codes directly after the existing 'define' entries in the file... should the code for the keys/salt go somewhere else?

[SlammedDime]

Can you attach your wp-config.php file, replacing all of the sensitive information with dummy data?

[Ken.]

OK, here it is.

[SlammedDime]

I see the salts are a bit different from the original error... is the error still occurring after you have replaced them with new ones?  I dropped the file into my WP install and adjusted the database info and it worked without issue...

[Ken.]

My existing WP has content and may have file issues, so I did a clean install to a new db and tried the bridge to that new WP and it all seems to work OK now... the Role Settings now open to a CP for setting membergroup access(s).

Now I just need to find and fix whatever the issue is with my existing install of WP, or move the content into this new one. 

Couple of questions:
Must a blog button be manually added, or is the mod supposed to install one?
If registration is off in WP will it pick up the registrations from SMF, including those already in place?
http://www.ourfamilyforum.org/SMF2.0/index.php
http://www.ourfamilyforum.org/wordpress2/

EDIT: The reg question arises because in your description it says, "If a user doesn't exist in one of the systems when logging in, they will be created automatically"... But when my 'testuser' is logged into SMF the user in not showing up in the WP users.

EDIT#2: NM on the reg question... after a couple of cycles of the page the testuser showed up in the WP membership.

[I Agree]

Any idea why this is failing when it should not be?

Code Select Expand


require_once($boarddir.'/WordpressPassword.php'); //$sourcedir
$wpPass = new WordpressPassword(8); 
if(!$wpPass->checkPassword($_POST['passwrd'],$wpUser['user_pass'])) return 'retry';


Is the password decryption more complicated than this?

EDITED: WordPress was upgraded to 3.1 for the record. I also reset the password since it was pre 3.0 before I started. I don't have any "salt" values in the wp-config file. But I don't see anywhere within checkPassword that requires any such values.

[Antes]

Parse error: syntax error, unexpected T_STATIC in /home/***/public_html/forummyth/Sources/WordpressBridge.php on line 1037

[SlammedDime]

I Agree - I have no idea why it would be failing... either the password isn't correct, or wpUser['user_pass'] doesn't have the proper value.

Antes - On line 1037, try changing 'static::' to 'self::' and see if/how that affects operation.

[Antes]

Parse error: syntax error, unexpected T_STATIC, expecting T_STRING or T_VARIABLE or '$' in /home/***/public_html/forummyth/Sources/WordpressBridge.php on line 1067

I changed static to self on 1067 too and get

Parse error: syntax error, unexpected T_STATIC, expecting T_STRING or T_VARIABLE or '$' in /home/***/public_html/forummyth/Sources/WordpressBridge.php on line 1070

By the way forget to add using WP 3.1.1 MU

[SlammedDime]

Yea, there are a few instances of 'static::'... change them all to 'self::' and see if it will work... if not, PHP 5.3 will be required for the time being until I can figure out a way around that...

[Antes]

Changed all 'static::' to 'self::'

Fatal error: protected static $__CLASS__ = __CLASS__; must be contained in child class in /home/***/public_html/forummyth/Sources/WordpressBridge.php on line 1068

[SlammedDime]

Yea, looks like the static keyword is PHP 5.3 only.  I'll have to look into trying to work around that.

[altdot]

Wow, I'm really excited about this! I've been holding out on 1.1.x waiting for a production-ready 2.0 install... but this? Might be enough to tempt me over early.

[I Agree]

I Agree - I have no idea why it would be failing... either the password isn't correct, or wpUser['user_pass'] doesn't have the proper value.

Hmmm, I thought I'd checked $_POST['passwrd'] before but maybe it was $user instead... anyway, it's empty. I assumed $_POST['passwrd'] would have to be set. There is a hidden hash_passwrd field on the form in the theme. I suppose actually returning what's in passwrd client side would be a bad thing to do, assuming it would be sent as is (type="password") ??

Thoughts? Your integrate_validate_login seems to rely upon $_POST['passwrd'] being set. Does it set it itself somewhere? Or does it just expect a different situation? Might be worth considering if different themes do things differently.

If you have any advice, that would be cool! Thanks.

[I Agree]

^So now the situation is I have $_POST['hash_passwrd'] and no $_POST['passwrd']  (dunno if they are different) which is the same as the hashpassword arg provided the integrate_validate_login hook.

I'm stuck comparing the hashword with the value in the WP db.  I'm not sure what the passwords even are. I assume none of them are the literal password.

Anyway, I'm confused why WordPressBridge.php uses $_POST['passwrd']. Is it supposed to have something in it on login?

Thanks

[SlammedDime]

on a normal SMF login, hash_password is set.  As far as the bridge goes, if a user does not exist in one or the other, I can't insert them without having a plaintext password.  By returning 'retry', this causes login hashing to be disabled, so the next login attempt sends a plaintext password in $_POST['passwrd'].

[I Agree]

on a normal SMF login, hash_password is set.  As far as the bridge goes, if a user does not exist in one or the other, I can't insert them without having a plaintext password.  By returning 'retry', this causes login hashing to be disabled, so the next login attempt sends a plaintext password in $_POST['passwrd'].

Ah, the plot thickens. I was kinda getting that kind of vibe from some of the inline documentation (comments) around the hook definition. I don't like the sound of this.... surely there is a better way to go? Does WP's code receive the same hash? Or is it tailored to SMF? Like by some javascript or something?

I've always wondered myself why their's not a popular webapp for user/password verification that all webapps could agree to share/support. That seems a lot more reasonable than every webapp trying to provide every service. But that's another topic. One of many.

I'd not think plaintext passwords would be transmitted in this day and age. What with https not being very common  (read: provider friendly) and wireless being more so.

Anyway, I need to be able to verify the login against the WP password. I can't assume the SMF one is identical. Please throw me a bone if you can. Or explain why the situation is hopeless if it really is

[SlammedDime]

It's not really hopeless... the only way to create a SMF user or a Wordpress user, or validate a wordpress password from SMF is to have a plaintext password to work with (just like SMF does when you register, the plain text password is transmitted and transformed on the backend).  Wordpress uses phpass, a portable php password system, whereas SMF, and many other pieces of software use some sort of md5 or sha1 variant.  The advantage of using the latter is the ability to hash client side before transmitting. 

With Wordpress, Drupal, phpBB, that's not possible due to the complexities of generating the password and validating.  With phpass, a single password can generate thousands upon thousands of different hashes, yet still validate.  This isn't the case with sha1 or md5 varients.  With phpass, the plaintext password and the hashed password are both required to validate the password.  The hashed password itself contains the salt that creates the password, which is needed to then recreate the hashed password from plaintext for verification.

Since the two systems use two different hashes (albeit, you can throw a wordpress hash into the SMF database and SMF can 'fix it' into an SMF variant by doing the same thing this mod does, which is asking the user for their password again, and then properly hashing it, as Wordpress uses the same password scheme that phpBB3 does, which SMF supports), it is not possible to easily register a person into either system without their plaintext password.

[I Agree]

It's not really hopeless... the only way to create a SMF user or a Wordpress user, or validate a wordpress password from SMF is to have a plaintext password to work with (just like SMF does when you register, the plain text password is transmitted and transformed on the backend).  Wordpress uses phpass, a portable php password system, whereas SMF, and many other pieces of software use some sort of md5 or sha1 variant.  The advantage of using the latter is the ability to hash client side before transmitting. 

With Wordpress, Drupal, phpBB, that's not possible due to the complexities of generating the password and validating.  With phpass, a single password can generate thousands upon thousands of different hashes, yet still validate.  This isn't the case with sha1 or md5 varients.  With phpass, the plaintext password and the hashed password are both required to validate the password.  The hashed password itself contains the salt that creates the password, which is needed to then recreate the hashed password from plaintext for verification.

Since the two systems use two different hashes (albeit, you can throw a wordpress hash into the SMF database and SMF can 'fix it' into an SMF variant by doing the same thing this mod does, which is asking the user for their password again, and then properly hashing it, as Wordpress uses the same password scheme that phpBB3 does, which SMF supports), it is not possible to easily register a person into either system without their plaintext password.

Well I have a better idea of what is going on now. I don't have a problem with getting the plaintext if it's totally necessary if the WP password does not validate (ie. has probably been changed on the WP end) ... is btw the plaintext literally transmitted as plaintext? Or is it (other than any kind of compression) at least obscured in a reversible way by virtue of being a password input?

It seems like the thing to do then, is to have the login prompts generate both kinds of hashes client side, then just copy whatever the WP sources do to validate the WP hashword.

EDITED: Or does PHPass mean the password is always transmitted in plaintext?? Since as you say nothing is done before transmission.

I swear to god though there's got to be a better way to manage passwords than this. But I'd just like to do what is expedient for now.

Has anyone here ever heard of something (not like OpenID) that is like WordPress/SMF (a webapp with a problem domain) but is strictly interested in storing/verifying usernames/passwords via a database? It seems like if there was something like that (that caught on) all frameworks like SMF would want to be interoperable with it out of the box.

I like the idea of just passing validation off to a 3rd party like ReCaptcha or something. But it would have to allow for fine grain anonymity and allow service providers to dictate their own namespace to be my cup of tea. Would make biometrics more manageable, and might be more secureable than trusting X websites to not let your password/email be stolen on their end. I dunno if the hashing is any good for preventing those passwords from being reused or not.

^Also the hypothetical 3rd party could easily provide an SSL certificate.