I have found a bit of a minor annoyance with user impersonation in its current form. Right now we use the 'sudo' cookie to hold the unique ID of the target user (the user being impersonated), and whenever a person logs out or a session is ended the cookie is erased (that is, it's value is set to 0 with an expiration date in the past). Given that, if, somehow, a sudo cookie manages to persist through a logout and subsequent login, and the person who has logged in is an sudoer, then that user will suddenly find himself in a sudo session that he did not start. This is not as big a problem as it may seem, because the user who gets into this situation will still be an sudo, and should be able to recognize and properly terminate the session. To solve this problem, I would like to change the value stored in the sudo cookie. Instead of holding the unique ID of the user being impersonated, I want to put that value into a token. The token would be created when the session is started, and the unique ID of the token would be placed into the sudo cookie. Then we would have an additional check in the login method: If the token is not associated with the user who is actually logged in right now then the sudo session will not be started.

Bugzilla 3.2 is now frozen. Only enhancements blocking 3.2 or specifically approved for 3.2 may be checked in to the 3.2 branch. If you would like to nominate your enhancement for Bugzilla 3.2, set the "blocking3.2" flag to "?". Then, either the target milestone will be changed back, or the blocking3.2 flag will be granted, if we will accept this enhancement for Bugzilla 3.2. This particular bug has not been touched in over eight months, and thus is being retargeted to "---" instead of "Bugzilla 4.0". If you believe this is a mistake, feel free to retarget it to Bugzilla 4.0.