-
Notifications
You must be signed in to change notification settings - Fork 630
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
AuditHandler cannot logged request, response, query parameters if response is sent by a framework middleware handler #840
Comments
@jiachen1120 I would prefer the second option and still position the dump handler as a debugging tool for the dev environment as it is too heavy. @miklish What do you think? |
@stevehu Yeah. Acctually the second situation already can fulfill our customer's requirements. Just wondering will it be useful if we also added dumpped request and response into auditMap in dev environment when people enable dumpped handler for debugging? I personally think option2 should be enough. @miklish Looking forward to your opinion. |
I prefer option 2 as well @stevehu @jiachen1120 |
* - solved networknt#840 - audit request if bodyHandler enabled - audit query parameters if request contains it - audit response on error * - auditing all request components - auditing serviceId * - added more test cases
The current design of the audit handler is that users implement their own way to audit their requests and response in their own handler.
However, it seems if the response is sent by framework middleware handler, people may be hard to auditing the request and response. For example, if openapi validation error happen, status will be sent back but this response won't be auditted.
Probably we can provide a option to users to audit these kind of request and response.
There are two situation:
The text was updated successfully, but these errors were encountered: