$_POST['passwrd'] blank after login

[dorje77]

Hi!
I'm using SMF2WPBridge and it worked (I found out 2 users created by the bridge in WP). Today I saw a new user in WP without password and I decided to start a debug. I deleted (in WP) a fake user that I've tested days ago with the bridge (and that has been created without problems in WP). Then I tried to log in again in SMF, but this doesn't create user in WP.
Debugging step-by-step the plugin, I found that it stops here:

Code Select Expand


} else if (!empty($_POST['passwrd'])) {

In fact, the value is empty - so the plugin doesn't trigger the user creation stuff.

Any ideas?

[Arantor]

The password is invariably taken away and replaced with an encrypted version during login.

I'd personally do it via the integration hooks, e.g. the one for user login, to test if the user exists on the WP side.

[dorje77]

The password is invariably taken away and replaced with an encrypted version during login.

I suspected something like this. What I really don't understand is: how the hell were other users created in WP, if the password is invariably taken away before triggering code of SMF2WPbridge?

I'd personally do it via the integration hooks, e.g. the one for user login, to test if the user exists on the WP side.

Yes, this is how the plugin actually works.

[Arantor]

...still not sure why you need the actual password. I'd argue WP should be deferring checking password to SMF or vice versa.

[dorje77]

...still not sure why you need the actual password. I'd argue WP should be deferring checking password to SMF or vice versa.

The plugin uses (includes) wp scripts "saveged" from wp installation path to create users, if they are  not found in wp.

The $_POST['passwrd'] value is used as argument in wp_create_user function, as is.

The strange thing is that this value was not empty some days ago... Users were created without problem.

I only changed thigs in my tamplate - but I didn't see login - related parts.

[dorje77]

Forcing

Code Select Expand


$context['disable_login_hashing'] = true;


solved that... I wonder if there are problems with this kind of workaround?

[Kindred]

 it is distinctly insecure?

[Arantor]

it is distinctly insecure?

Only if you're still using HTTP.

[dorje77]

Only if you're still using HTTP.

Well, just implemented ssl a week ago! 

Thank you for brainstorming.

[Aleksi "Lex" Kilpinen]

So, is this topic ready to be marked solved then?