-
Notifications
You must be signed in to change notification settings - Fork 4.2k
feat(apigatewayv2): HttpStage
access logging
#33977
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
} else { | ||
if (accessLogFormat !== undefined && | ||
!Token.isUnresolved(accessLogFormat.toString()) && | ||
!/.*\$context.(requestId|extendedRequestId)\b.*/.test(accessLogFormat.toString())) { |
Check failure
Code scanning / CodeQL
Polynomial regular expression used on uncontrolled data High
This regular expression that depends on library input may run slow on strings with many repetitions of 'a'.
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.
Could we modify this check to check that the accessLofFormat.toString()
includes either contextRequestId or contextExtendedRequestId instead of using a regex? Something like this:
if (
accessLogFormat !== undefined &&
!Token.isUnresolved(accessLogFormat.toString()) &&
!accessLogFormat.toString().includes('$context.requestId') &&
!accessLogFormat.toString().includes('$context.extendedRequestId')
) {
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.
Intention is to prevent user from mistakenly using something like $context.requestIdxxx
. In such case, .includes('$context.requestId')
passes, but later fail on runtime.
I personally think we are fine with this. Let me know your point.
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.
Oh I see, thanks for clarifying. Then maybe we can do a stricter exact match like so:
const allowedValues = new Set([
'$context.requestId',
'$context.extendedRequestId'
]);
if (
accessLogFormat !== undefined &&
!Token.isUnresolved(accessLogFormat.toString()) &&
!allowedValues.has(accessLogFormat.toString())
) {
throw new ValidationError(...);
}
I agree the current change would probably be fine but better to satisfy the CodeQL checks where possible. What do you think?
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.
Thanks for the recommendation. I updated to use your first solution.
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.
The first solution would accept an input like $context.requestIdxxx
like you mentioned but that's not what we want. I think we should use the second option which uses stricter exact string matching.
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.
format
contains multiple parameters, eg: $context.responseLength $context.requestId
. So 2nd solution .has
doesn't work as it check for the exact string. Anw, i've updated the regex to pass CodeQL. Please let me know what you think.
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.
Good point, the current solution lgtm!
Codecov ReportAll modified and coverable lines are covered by tests ✅
Additional details and impacted files@@ Coverage Diff @@
## main #33977 +/- ##
==========================================
+ Coverage 82.39% 83.98% +1.58%
==========================================
Files 120 120
Lines 6960 6976 +16
Branches 1175 1178 +3
==========================================
+ Hits 5735 5859 +124
+ Misses 1120 1005 -115
- Partials 105 112 +7
Flags with carried forward coverage won't be shown. Click here to find out more.
🚀 New features to boost your workflow:
|
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.
Hi @phuhung273, thank you for this contribution for this very highly community-requested feature! I've just left a few comments for some changes.
} else { | ||
if (accessLogFormat !== undefined && | ||
!Token.isUnresolved(accessLogFormat.toString()) && | ||
!/.*\$context.(requestId|extendedRequestId)\b.*/.test(accessLogFormat.toString())) { |
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.
Could we modify this check to check that the accessLofFormat.toString()
includes either contextRequestId or contextExtendedRequestId instead of using a regex? Something like this:
if (
accessLogFormat !== undefined &&
!Token.isUnresolved(accessLogFormat.toString()) &&
!accessLogFormat.toString().includes('$context.requestId') &&
!accessLogFormat.toString().includes('$context.extendedRequestId')
) {
/** | ||
* The CloudWatch Logs log group or Firehose delivery stream where to write access logs. | ||
* | ||
* @default - No destination | ||
*/ | ||
readonly accessLogDestination?: IAccessLogDestination; | ||
|
||
/** | ||
* A single line format of access logs of data, as specified by selected $context variables. | ||
* The format must include either `AccessLogFormat.contextRequestId()` | ||
* or `AccessLogFormat.contextExtendedRequestId()`. | ||
* | ||
* @see https://docs.aws.amazon.com/apigateway/latest/developerguide/http-api-logging-variables.html | ||
* | ||
* @default - Common Log Format | ||
*/ | ||
readonly accessLogFormat?: AccessLogFormat; |
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.
Since the accessLogDestination
property must be conditionally set if accessLogFormat
is set, let's combine these two properties into an interface so that they must be specified together. Something like
interface IAccessLogOptions { // or IAccessLogSettings
readonly accessLogDestnation: IAccessLogDestination;
readonly accessLogFormat: AccessLogFormat;
}
This way we enforce that they must be set together and then we won't need the validation in the HttpStage
constructor.
Note: I see that the old aws-apigateway
's implementation for accessLogSettings
has these two properties as separate properties, but I think we should still combine the properties even though it would differ from the existing convention. Wherever possible, we would like to enforce conditional properties with the API design rather than runtime validation.
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.
Thanks for your advice. Agree that we should combine.
Another point, what do you think about making accessLogFormat
optional with default value AccessLogFormat.clf()
. IMO, most user just want to put the destination.
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.
Ya I think that's a good idea. Is it a valid use case to specify the destination
without a format
? If so then I think this change is fine as it is now.
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.
format
is always required according to CloudFormation. But I like the logic of apigwv1 to make it optional by providing default value if not specified, more user-friendly I think. So I kept it.
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.
I see, I think that is fine then if we have the same behaviour in apigv1. Thanks!
Seeing community demand for the same setting in I did try to include aws-cdk/packages/aws-cdk-lib/aws-apigateway/lib/restapi.ts Lines 162 to 167 in 74cbe27
Therefore, decided to only change |
Hi @phuhung273, thanks for your quick response to the requested changes. I've just left two more comments:
Happy to approve after those changes are made! |
8877d58
to
53bc7f5
Compare
53bc7f5
to
d67296c
Compare
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.
Great work! Thanks for your contribution @phuhung273!
@Mergifyio update |
Thank you for contributing! Your pull request will be updated from main and then merged automatically (do not update manually, and be sure to allow changes to be pushed to your fork). |
☑️ Nothing to do
|
AWS CodeBuild CI Report
Powered by github-codebuild-logs, available on the AWS Serverless Application Repository |
Thank you for contributing! Your pull request will be updated from main and then merged automatically (do not update manually, and be sure to allow changes to be pushed to your fork). |
Comments on closed issues and PRs are hard for our team to see. |
Issue # (if applicable)
Closes #11100
Description of changes
Description of how you validated changes
Unit + Integ
Checklist
By submitting this pull request, I confirm that my contribution is made under the terms of the Apache-2.0 license