Copilot commented on code in PR #13374:
URL: https://github.com/apache/trafficserver/pull/13374#discussion_r3553002400
##########
doc/admin-guide/files/logging.yaml.en.rst:
##########
@@ -258,6 +258,60 @@ supported at this time.
expect. If, for example, we had 2 accept log filters, each disjoint from
the other,
nothing will ever get logged on the given log object.
+Wiping Query Parameter Values
+~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
+
+The ``wipe_field_value`` action masks the values of matching query string
+parameters before the event is written to the log. Unlike ``accept`` and
+``reject``, a ``wipe_field_value`` filter never drops an event; it only
rewrites
+the logged field. This is useful for keeping secrets such as passwords, session
+tokens, or email addresses out of the access log while still logging the
request.
+
+The filter examines the query string of the field named in the ``condition``
+(typically ``cquuc``, the client request URL) and, for every query parameter
+whose **name** matches one of the filter values, replaces that parameter's
value
+with a run of ``X`` characters of the same length. The ``condition`` operator
and
+values behave exactly as described above; use ``CASE_INSENSITIVE_CONTAIN`` (or
+``CONTAIN``) so that any parameter name containing one of the listed tokens is
+wiped.
+
+.. important::
+
+ Only the query parameter **names** are matched, never their values. A
+ parameter is wiped only when the pattern appears in the part of the
parameter
+ before its ``=``. A value that happens to equal one of the filter tokens is
+ left untouched.
+
+The following filter wipes the values of a set of sensitive parameters:
+
+.. code:: yaml
+
+ filters:
+ - name: queryparamescaper_cquuc
+ action: WIPE_FIELD_VALUE
+ condition: cquuc CASE_INSENSITIVE_CONTAIN
password,secret,access_token,session_redirect,email
Review Comment:
The PR description says the example filter configuration is taken directly
from the existing `log-filter` autest, but the documented `condition` token
list doesn’t match `tests/gold_tests/logging/log-filter.test.py` (missing
`cardNumber,code,query,search-query,prefix,keywords,handle`). Either align this
line with the test config for traceability, or update the PR description/intent.
##########
doc/admin-guide/files/logging.yaml.en.rst:
##########
@@ -258,6 +258,60 @@ supported at this time.
expect. If, for example, we had 2 accept log filters, each disjoint from
the other,
nothing will ever get logged on the given log object.
+Wiping Query Parameter Values
+~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
+
+The ``wipe_field_value`` action masks the values of matching query string
+parameters before the event is written to the log. Unlike ``accept`` and
+``reject``, a ``wipe_field_value`` filter never drops an event; it only
rewrites
+the logged field. This is useful for keeping secrets such as passwords, session
+tokens, or email addresses out of the access log while still logging the
request.
+
+The filter examines the query string of the field named in the ``condition``
+(typically ``cquuc``, the client request URL) and, for every query parameter
+whose **name** matches one of the filter values, replaces that parameter's
value
+with a run of ``X`` characters of the same length. The ``condition`` operator
and
+values behave exactly as described above; use ``CASE_INSENSITIVE_CONTAIN`` (or
+``CONTAIN``) so that any parameter name containing one of the listed tokens is
+wiped.
+
+.. important::
+
+ Only the query parameter **names** are matched, never their values. A
+ parameter is wiped only when the pattern appears in the part of the
parameter
+ before its ``=``. A value that happens to equal one of the filter tokens is
+ left untouched.
+
+The following filter wipes the values of a set of sensitive parameters:
+
+.. code:: yaml
+
+ filters:
+ - name: queryparamescaper_cquuc
+ action: WIPE_FIELD_VALUE
+ condition: cquuc CASE_INSENSITIVE_CONTAIN
password,secret,access_token,session_redirect,email
+
+Given that filter attached to a log using the ``%<cquuc>`` format, the
following
+request URLs are logged as shown:
+
+=======================================================================================
=======================================================================================
+Requested URL
Logged value
+=======================================================================================
=======================================================================================
+``/test-1?name=value&[email protected]``
``/test-1?name=value&email=XXXXXXXXXXXXX``
+``/[email protected]&name=password``
``/test-2?email=XXXXXXXXXXXXX&name=password``
+``/test-3?trivial=password&name1=val1&[email protected]``
``/test-3?trivial=password&name1=val1&email=XXXXXXXXXXXXX``
+``/test-4?trivial=password&email=&name=handle&session_redirect=wiped_string``
``/test-4?trivial=password&email=&name=handle&session_redirect=XXXXXXXXXXXX``
Review Comment:
The logged values in this table don’t match the existing gold test output
for `%<cquuc>` (the `cquuc` field is a canonical URL and includes scheme/host,
so the log lines include `http://example.com/...`). Keeping the table aligned
with `tests/gold_tests/logging/gold/filter-test.gold` will prevent confusion
when users compare docs to real log output.
--
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
To unsubscribe, e-mail: [email protected]
For queries about this service, please contact Infrastructure at:
[email protected]
