Originally filed by hefox in the security queue. Since the 7.x branch is not affected by this issue and the 6.x branch is not supported, this can now be public:

The login resource only calls user_authenticate to login in a given user, http://drupalcode.org/project/services.git/blob/refs/heads/6.x-3.x:/reso..., which both ignores the other validation handles core provides (e.g. http://api.drupal.org/api/drupal/modules!user!user.module/function/user_... ) and any that a contrib module may have added.

To reproduce (haven't directly tested, based on looking at code)
1) install and configure resources
2) Create a user then block their name
3) Try to login via that user using login block -- should fail
4) Try to login via services resource -- won't fail

This, http://drupalcode.org/project/bakery.git/blob/refs/heads/6.x-2.x:/bakery..., is how bakery handles the situation.

Looking at 6.x, haven't checked if similar problems exist in 7.x


marcingy’s picture

Priority: Critical » Normal

As services d6 is not supported dropping the priority level

marcingy’s picture

greggles’s picture

I just meant "critical" in terms of something that has to be fixed before a release not in terms of the priority the maintainers should put on it.

How about this tag?

kylebrowning’s picture

Status: Active » Closed (fixed)
greggles’s picture

Status: Closed (fixed) » Needs work
return services_error(t('!user is blocked.', array('!user' => $username)), 406);

Unless services_error does its own filtering, a username should get an @user placeholder.

kylebrowning’s picture

Status: Needs work » Closed (fixed)