I was looking at the code for OpenID, and noticed that during user authentication, user_login_name_validate() is called with an incorrect set of parameters, which seems like it will lead blocked users to not be blocked if they log in via OpenID.

This is presumably a security issue; however, it's D7 only so can be a public issue. The equivalent code in D6 is in http://api.drupal.org/api/function/user_external_login/6 and appears to work correctly (although it has a minor bug where it passes along an extra unneeded parameter).

Patch coming in a second.

Support from Acquia helps fund testing for Drupal Acquia logo

Comments

David_Rothstein’s picture

FileSize
857 bytes

Here is the patch.

The code in this area seems somewhat fragile, so it could probably use a test, although that might require a fair bit of rewriting. Sounds like something to deal with after the code freeze :)

brianV’s picture

Issue tags: +Needs tests

Seems correct to me, but definately needs tests. Tagging.

c960657’s picture

Issue tags: -Needs tests
FileSize
3.73 KB

Added a test.

c960657’s picture

Reroll.

brianV’s picture

Status: Needs review » Reviewed & tested by the community

Perfect!

webchick’s picture

Status: Reviewed & tested by the community » Fixed

Ouch! That's a nasty little bug.

Committed to HEAD, thanks! :)

Status: Fixed » Closed (fixed)

Automatically closed -- issue fixed for 2 weeks with no activity.

Gábor Hojtsy’s picture

Status: Closed (fixed) » Active
FileSize
1.31 KB

Same bug appears in the initial registration too. D6 is not affected, since it uses user_external_login() which will not log the user in, if she is blocked. However, D7 just plain logs in the user regardless of user status. Bad.

This suggested patch adds an explicit check for user status right before we attempt to log the user in (but after we saved the OpenID association). If the newly registered user was blocked, we inform her that the account is awaiting admin approval.

Gábor Hojtsy’s picture

Looks like the refactoring at #395340: Email verification not enforced with OpenID auto-registration solves this issue as well, but let's ensure that its solved, cause otherwise this is a security issue (therefore critical).

Dries’s picture

Gábor Hojtsy’s picture

Well, it will not even apply anymore then. I think we need to retest this manually, since the process is very different now for registrations. We might also want to extend the tests for registrations to test for this condition. Anyway, we need to verify that this is not an issue anymore with the updated code.

Gábor Hojtsy’s picture

Status: Active » Fixed

I've verified on a test install site, and #395340: Email verification not enforced with OpenID auto-registration did indeed solve this problem as well. We can consider this fixed as far as I see.

Status: Fixed » Closed (fixed)

Automatically closed -- issue fixed for 2 weeks with no activity.