Problem caused by code wiping out global $user variable when a user enters incorrect password

I had originally posted this as a bug against Taxonomy_access, ( http://drupal.org/node/58097 ) but as the problem is caused by a specific behavior of user.module, I'm reposting it here as perhaps it is user.module that is not working as it should.

Description

I found this while debugging a strange error message that originally seemed to be caused by the img_assist module, but on deeper inspection turned out to be caused by an interacction between the user and taxonomy_access modules.

I am running Drupal 4.6.5 and the latest image and image_ast modules for 4.6, and taxonomy_access.

The cause of my error stems from a problem with an interaction between the "taxonomy_access" and the "user" modules, and arises when someone tries to login with an incorrect password. Here's what happens:

1. I have used image assist to upload images which I then include in my page design. I have created a custom block that includes the following code:
[img_assist|fid=37|thumb=1|alt=Chico Interrogación].

2. When a user trys to log in using an incorrect password, the "user_login" function is called, which in turn calls "user_authenticate", which in turn calls "user_load", which attempts to load the user. The sql which searches for the user (based on login name and password) returns an empty set (remember, I'm discussing the case where the user enters an incorrect password). When this happens, the following line is executed within "user_load": $user= new StdClass(); - i.e. an empty object - and immediately afterwards: return $user;. This passes control back to user authenticate, which assigns this empty object to the GLOBAL $user variable. Prior to this, the global $user was not an empty object, but had several attributes, incluiding $user->uid = 0, and $user->roles[1]="anonymous userj". These attributes are therefore gone after this point.

3. Execution continues normally, until the blocks are loaded, and in loading my custom block a call to img_assist_load_image is made. Because the image is a node, before the image can be loaded a call to node_access_grants is made while constructing the sql. Within this function, the GLOBAL $user (which is now an empty object) is passed through "module_invoke_all" down to "taxonomy_access_node_grants". The content of this short function is as follows:

function taxonomy_access_node_grants($user, $op) {
return array('term_access' => array_keys(is_array($user->roles) ? $user->roles : array()));
}

Given that $user is empty, the output of the function is an array whose key is 'term_access', and whose value is an empty array. Normally, for an anonymous user, the key would be 'term_access', and the value would be an array[1]="anonymous user".

4. To make a long story shorter, the function _node_access_where_sql (in node.module) would normally generate the following where clause segment in the case of an anonymous user: "na.grant_view = 1 AND CONCAT(na.realm, na.gid) IN ('all0', 'term_access1')" . However, in this situation, the 'term_access1' is left out, which causes the sql generated for img_assist_load_image to return an empty set instead of the path to the image. A subsequent call to getimagesize generates an error, as it is passed an incorrect path.

Possible solutions:
a. Modify taxonomy_access_node_grants so that if $user is empty, it automatically assumes a role of anonymous user, and thus would return array['term_access'][1]='anonymous user'.
b. Modify user_load so that it doesn't wipe out the GLOBAL $user variable when an incorrect password is entered
c. Modify node_access_grants to detect whether GLOBAL $user is empty, and if so, set $user_object->roles = array(1 => 'anonymous user')

I'm not familiar enough with these three modules (taxonomy_access, user, node) to know what the impact of each of the proposed solutions, so I'm hoping one of the owners can suggest a solution.

Thanks!

---- end of original post

For the sake of completeness, I finally chose solution a). It seems to be working fine now, haven't noticed any side-effects.