[JAVA-651] MapReduce output to a temp db collection failed due to unauthorization issue Created: 25/Sep/12 Updated: 25/Jun/13 Resolved: 25/Apr/13 |
|
| Status: | Closed |
| Project: | Java Driver |
| Component/s: | Connection Management |
| Affects Version/s: | 2.9.0 |
| Fix Version/s: | None |
| Type: | Bug | Priority: | Major - P3 |
| Reporter: | Yong Ouyang | Assignee: | Unassigned |
| Resolution: | Duplicate | Votes: | 0 |
| Labels: | driver | ||
| Remaining Estimate: | Not Specified | ||
| Time Spent: | Not Specified | ||
| Original Estimate: | Not Specified | ||
| Environment: |
MongoDB v2.2.0 (replica set with authentication turned on) |
||
| Issue Links: |
|
||||||||||||||||
| Description |
|
When MapReduce command outputs to a temp DB, it will fail due to unauthorization error. This is because the output DB of MapReduce is not the same as the one I issue the MapReduce command on, DBPort will not be able to authenticate against the output DB. I've figured out a workaround that I have to add a method to DB class to enforce authentication, such that before sending out the MapReduce command, I can ensure my temp DB is authenticated for that connection. But this is not ideal, as the client shouldn't need to deal with all these complexities. |
| Comments |
| Comment by Jeffrey Yemin [ 25/Apr/13 ] | ||||||||
|
Reviewing this ticket again, this was actually fixed in 2.11.0, as we changed the way we do authentication. In 2.11.x, every credential is authenticated against every connection, whereas it used to be done lazily based on which database the operation was applied to. See | ||||||||
| Comment by Jeffrey Yemin [ 25/Sep/12 ] | ||||||||
|
This will work in most cases, but is not totally reliable as there is no hard guarantee that the same connection will be used for enforceAuthentication and mapReduce, though in practice it usually will. | ||||||||
| Comment by Yong Ouyang [ 25/Sep/12 ] | ||||||||
|
I added the following method into the DB class as my workaround. It works well so far (about 2 weeks of our continuous integration tests), as I found that there seems to be no harm actually authenticate the same DB twice.
| ||||||||
| Comment by Jeffrey Yemin [ 25/Sep/12 ] | ||||||||
|
Thanks for the bug report. Can you post the code for your workaround please? |