With phpass installed, calls to user_authenticate() fail. This is because user_authenticate() calls user_load() with an array of user information that includes a plaintext password, and user_load() has a hardcoded md5() call to resolve the password. pwolanin suggested a core patch to be shipped with phpass, which is the only solution I can think of as well.
| Comment | File | Size | Author |
|---|---|---|---|
| #16 | 1370988-16-D5.patch | 3.45 KB | pwolanin |
| #10 | 1370988-10.patch | 3.5 KB | pwolanin |
| #9 | 1370988-9.patch | 1.45 KB | pwolanin |
| #8 | 1370988-8-user_load.D6.patch | 1.3 KB | pwolanin |
| #7 | 1370988-7-user_load.D6.patch | 1.24 KB | pwolanin |
Comments
Comment #1
ksenzeeNot sure if this is the right idea or not. It looks like once phpass is installed it's there for good, so I didn't add a module_exists check. I also didn't write it in such a way as to be acceptable in the core queue - getting it into core doesn't seem like an achievable goal. But maybe I'm a pessimist.
Comment #2
gábor hojtsyHow did this not come up before?
Comment #3
pwolanin commentedIt's not a facility used by core, only by external authentication modules using the password. I was aware it could be an issue, but didn't seem critical.
Patch looks reasonable to me - I think if you apply this patch you are not going to disable phpass. The only value I could see to a module_exists check would be that the patch could be applied prior to phpass being installed.
Comment #4
pwolanin commentedOk, well discovered now that user_authenticate() *is* used by core when you have email verification disabled for user registration.
I think in addition to supplying this patch with the module, we need to make the module work around that problem absent the patch.
Comment #5
pwolanin commentedHere's a patch for the module itself that works around the authentication failure.
The core registration code flow is very wonky, but I think the logic here is both correct and minimal.
Comment #6
pwolanin commentedoops missed-used an undefined $form_values that should be $form_state['values']
Comment #7
pwolanin commentedwe could perhaps add a define() to the core patch? That way we can 100% skip the extra submit function if the core patch is applied.
Comment #8
pwolanin commentedwith code comment
Comment #9
pwolanin commentedcorresponding module patch
Comment #10
pwolanin commentedfull patch
Comment #11
pwolanin commentedcommitted to 6.x
Comment #12
gregglesThis seems like it could just be "won't fixed" as 5.x should no longer be supported.
Comment #13
drummYep.
Comment #14
pwolanin commentedWell, I wanted to still support 5x for now - but this is low priority obviously
Comment #15
gregglesUpdating priority to reflect #14.
Comment #16
pwolanin commentedIf you want to test this D5 seems to only work with PHP 5.2, not 5.3.
I'm not sure why D5 user module doesn't have a session regenerate call in it, but as best I can tell this does the same as the D6 patch and code.