-
Notifications
You must be signed in to change notification settings - Fork 567
Fix regression matching templated McpServerResources #897
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Conversation
| public override bool CanReadUri(string uri) | ||
| { | ||
| Throw.IfNull(uri); | ||
| return TryMatch(uri, out _); |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This is going to create the Match object if it does match. It'd be better if the Can path used IsMatch instead
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
@halter73, you marked this as resolved, but it's not actually resolved... is it that you have a fix for it locally?
- Improve comments
This fixes a regression reported in #821 that was caused by changes in #733 which caused resource template matching to break when there were multiple templated resources.
It's important for the auth pipeline to determine which resource is matched to make authorization decisions without executing the handlers associated with reading the resource. So rather than call McpServerResource.ReadAsync prior to running the filter pipeline, #733 wrongly assumed the first templated McpServerResource it saw would be able to handle any templated request. To fix this while still avoiding calling McpServerResource.ReadAsync just to see if the resource matched before auth filter can prevent it, this PR adds a new McpServerResource.CanReadUri method.
Unlike before, this will call Regex.Match twice for the matched resource. We could flow the Match to the eventual ReadAsync call via the RequestContext, but I don't think this one additional call is a huge concern though, considering that we already call Regex.Match O(N) times where N is the number of templated resources. I figure we'll probably use some sort of trie if/when we further optimize this path at which point we could look at preserving the matches.
Fixes #821