-
Notifications
You must be signed in to change notification settings - Fork 776
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
Validate regex patterns against non-backtracking engine #16687
Conversation
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.
Pull Request Overview
This PR introduces functionality to validate regular expression patterns against .NET’s non-backtracking engine. The key changes include:
- Adding helper methods in TypeHelper to validate regex patterns.
- Enforcing regex pattern validation in StringType.
- Updating various resource type factories to use the new validation helper.
Reviewed Changes
Copilot reviewed 6 out of 6 changed files in this pull request and generated no comments.
Show a summary per file
File | Description |
---|---|
src/Bicep.Core.IntegrationTests/ScenarioTests.cs | Adds a new test method to ensure provider-sourced regexes degrade gracefully. |
src/Bicep.Core/TypeSystem/TypeHelper.cs | Adds helper methods for validating regex patterns against the non-backtracking engine. |
src/Bicep.Core/TypeSystem/Types/StringType.cs | Enforces regex pattern validation in the StringType constructor. |
src/Bicep.Core/TypeSystem/Providers/MicrosoftGraph/MicrosoftGraphResourceTypeFactory.cs | Updates to apply the new regex validation helper. |
src/Bicep.Core/TypeSystem/Providers/ThirdParty/ExtensibilityResourceTypeFactory.cs | Updates to apply the new regex validation helper. |
src/Bicep.Core/TypeSystem/Providers/Az/AzResourceTypeFactory.cs | Updates to apply the new regex validation helper. |
Comments suppressed due to low confidence (2)
src/Bicep.Core.IntegrationTests/ScenarioTests.cs:7085
- Consider adding a case with an explicitly invalid regex pattern in this test. This would clearly verify that the graceful degradation behavior is working as intended.
public void Non_spec_compliant_provider_sourced_regexes_degrade_gracefully()
src/Bicep.Core/TypeSystem/Types/StringType.cs:13
- [nitpick] The error message includes regex delimiters (slashes) which may be misleading if the pattern does not normally include them. Consider removing the delimiters or clarifying in the message that they are added for readability.
throw new ArgumentException($"The supplied regular expression pattern /{pattern}/ is not valid", error);
@@ -115,7 +115,7 @@ private TypeSymbol ToTypeSymbol(Azure.Bicep.Types.Concrete.TypeBase typeBase, bo | |||
case Azure.Bicep.Types.Concrete.StringType @string: | |||
return TypeFactory.CreateStringType(@string.MinLength, | |||
@string.MaxLength, | |||
@string.Pattern, | |||
TypeHelper.AsOptionalValidFiniteRegexPattern(@string.Pattern), |
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.
We end up parsing each regex twice with this pattern, but I think that's fine since provider types are cached and including a check in StringType
constructor means that downstream code can assume any pattern attached to a StringType
instance is valid.
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.
For a second I thought this fixes #8409, maybe next time 😆
Test this change out locally with the following install scripts (Action run 14036496189) VSCode
Azure CLI
|
Dotnet Test Results 78 files - 39 78 suites - 39 33m 44s ⏱️ - 15m 34s Results for commit f0dad59. ± Comparison against base commit 66b73c2. This pull request removes 1780 and adds 610 tests. Note that renamed tests count towards both.
|
Resolves #16676
Resolves #16681
Microsoft Reviewers: Open in CodeFlow