In 2.2.0, the behavior of mapReduce changed with respect to authentication. In 2.0.x, if the output collection is in a different database than the input collection (using "db" field in "out" document), the server would write to that collection even if the connection was not authenticated to that db. In 2.2 that changes, and the server returns an error:

{ "serverUsed" : "localhost/127.0.0.1:30000" , "errmsg" : "exception: unauthorized db:mrtesttarget ns:mrtesttarget.tmp.mr.imr1_0_inc lock type:1 client:127.0.0.1" , "code" : 10057 , "ok" : 0.0}

The problem is that many drivers lazily authenticate connections based on the database that a command is being run against, and do not consider things like different output directories for mapReduce (or for future support in aggregation framework). So even if an application authenticates against the other database, the connection that ends of being used for the mapReduce command may or not have been authenticated to that other database, depending on if that connection happened to already have been used to run some operation against that other database already.

This could be fixed solely in the drivers, but it would involve either:

• authenticating every connection against every database
• pushing knowledge of commands down to a lower level of the driver
• parsing the error message returned by the server and retrying the command

A possible way to handle this more gracefully is to have the server respond with a challenge document that identifies additional databases that need to be authenticated against before the command can be executed.