[SERVER-28972] Relax KeysCollectionManager::getKeyForValidation keyId restriction Created: 25/Apr/17  Updated: 30/Oct/23  Resolved: 13/Jun/17

Status: Closed
Project: Core Server
Component/s: None
Affects Version/s: 3.5.7
Fix Version/s: 3.5.9

Type: Improvement Priority: Major - P3
Reporter: Randolph Tan Assignee: Misha Tyulenev
Resolution: Fixed Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Issue Links:
Related
is related to SERVER-28883 Avoid the scenario when KeyManager cr... Closed
Backwards Compatibility: Fully Compatible
Sprint: Sharding 2017-06-19
Participants:

 Description   

to allow matching keyId to keys even though they are not the best choice if expiredAt is the only criteria.

Example:

key1: { _id: 1, expiredAt: 10 }
key2: { _id: 2, expiredAt: 12 }
request: { _id: 2, time: 8 }

In the example above, getKeyForValidation will choose key1 since it has the closest expiredAt for the given time and since the keyId does not match, it will return an error. This scenario should not happen unless key2 was created before key1, which might be possible with SERVER-28883.



 Comments   
Comment by Githook User [ 13/Jun/17 ]

Author:

{u'username': u'mikety', u'name': u'Misha Tyulenev', u'email': u'misha@mongodb.com'}

Message: SERVER-28972 match return key by keyId in KeysCollectionManager::getKeyForValidation
Branch: master
https://github.com/mongodb/mongo/commit/04710415238d2e2aae526a9d63f93306de60fce3

Generated at Thu Feb 08 04:19:34 UTC 2024 using Jira 9.7.1#970001-sha1:2222b88b221c4928ef0de3161136cc90c8356a66.