chrisjantzen
commented
2 years ago I did a deep-dive into the module's code today and I think I've found the issue.
In the Get-CosmosDbAuthorizationHeadersFromContext util the code checks for a valid token where the token's resource matches the resource you are querying: https://github.com/PlagueHO/CosmosDB/blob/f6d628cdc3066fafc94c8624a4893fbe2c1cfa55/source/Private/utils/Get-CosmosDbAuthorizationHeadersFromContext.ps1#L23-L25
When creating a token, the resource connected to the token looks like dbs/Usage/colls/Users, and as noted above, you cannot set the resource to dbs/Usage/colls/Users/docs.
If you simply query a collection (like in the example for resource tokens) the resource looks like dbs/Usage/colls/Users. This matches so $matchToken is set.
If you query a document in that collection, the resource becomes dbs/Usage/colls/Users/docs and no match is found. Therefore no auth headers can be made from a token and in the Invoke-CosmosDbRequest function it falls back to looking for a master key.
If no master key is set, the query fails. I believe it should allow sub resources in the token check and that this is an issue in the module code.
Looking at Invoke-CosmosDbRequest, we actually seem to have all the data we need to make this work. The $resourceId is a parsed version of the resource link which in this case strips off docs making the resource id dbs/Usage/colls/Users, which will work in the resource check in this scenario. I'm not certain, but I believe it should work in most other scenario's as well.
I attempted a fix: Lines 80 to 147 of source/Private/utils/Invoke-CosmosDbRequest.ps1
# Generate the resource link value that will be used in the URI and to generate the resource id
switch ($resourceType)
{
'dbs'
{
# Request for a database object (not containined in a database)
if ([System.String]::IsNullOrEmpty($ResourcePath))
{
$ResourceLink = 'dbs'
$AuthLink = 'dbs' # +++
}
else
{
$resourceLink = $ResourcePath
$resourceId = $resourceLink
$authLink = $resourceId # +++
}
}
'offers'
{
# Request for an offer object (not contained in a database)
if ([System.String]::IsNullOrEmpty($ResourcePath))
{
$ResourceLink = 'offers'
$AuthLink = 'offers' # +++
}
else
{
$resourceLink = $ResourcePath
$resourceId = ($ResourceLink -split '/')[1].ToLowerInvariant()
$authLink = $resourceId # +++
}
}
default
{
# Request for an object that is within a database
$resourceLink = ('dbs/{0}' -f $Database)
if ($PSBoundParameters.ContainsKey('ResourcePath'))
{
$resourceLink = ('{0}/{1}' -f $resourceLink, $ResourcePath)
}
else
{
$resourceLink = ('{0}/{1}' -f $resourceLink, $ResourceType)
}
# Generate the resource Id from the resource link value
$resourceElements = [System.Collections.ArrayList] ($resourceLink -split '/')
if (($resourceElements.Count % 2) -eq 0)
{
$resourceId = $resourceLink
}
else
{
$resourceElements.RemoveAt($resourceElements.Count - 1)
$resourceId = $resourceElements -Join '/'
}
$authLink = $resourceId # +++
}
}
# Generate the URI from the base connection URI and the resource link
$baseUri = $Context.BaseUri.ToString()
$uri = [uri]::New(('{0}{1}' -f $baseUri, $resourceLink))
# Try to build the authorization headers from the Context
$authorizationHeaders = Get-CosmosDbAuthorizationHeadersFromContext `
-Context $Context `
-ResourceLink $authLink # changed from $resourceLink to $authLinkIn the above code I've simply added the $authLink, then used that for the auth headers function. We could use $resourceId but it isn't set for the dbs or offers cases and I didn't want to risk setting it and breaking something.
TLDR / Summary I've tested the above code out and it seems to work in this scenario. I can query documents in this collection as well as the collection directly. Considering this works, it seems to be this is the way the Cosmos DB api permissions are meant to work, the issue is this module doing a resource link check for validation, and preventing the query. I'm not certain my above fix is the best option, which is why I haven't put in a commit. Though it seems that this check needs to be more generalized to allow the base resource link (up to the collection) to work for sub resource links (such as docs).
Considering the resource tokens are not a new feature, and this seems like a pretty big issue that prevents them from being all that useable, I could be way off target. I suspect this isn't a commonly used part of the module but I'm still surprised the issue hasn't come up before. Have I missed something?
PlagueHO
I am trying to setup a key broker and am struggling to get it working. I used the example to setup a User and configured a Permission on that user, this seemed to work smoothly, I then create a Resource Auth Token but when using the Resource Context I am getting an error. Here is the code I have used so far:
The TimeStamp is the main thing done differently from the example but I found the example didn't work quite right and this seemed to work well enough as a workaround. I also hardcoded the resource path, but I have also tested
Get-CosmosDbCollectionResourcePathand end up with the same result.This all appears to work and creates a context object with the Token set:
If I try to use this context object to get the Users collection's info like in the example it works fine, but if I try to query documents I get an error.
This works:
Get-CosmosDbCollection -Context $resourceContext -Id 'Users'This does not:
It returns the following error:
VERBOSE: Searching context tokens for resource matching 'dbs/Usage/colls/Users/docs'.VERBOSE: Context token with resource 'dbs/Usage/colls/Users/docs' not found.System.InvalidOperationException: The authorization key is empty. It must be passed in the context or a valid token context for the resource being accessed must be supplied.If anyone has any suggestions or could point me in the right direction, I'd really appreciate it! I've went through the code but can't figure out why it's not working. It seems like the permission's aren't correct for this. I did try setting a permission on the resource
dbs/Usage/colls/Users/docs, but it wouldn't take that as a valid option.