-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA256
Mark,
On 11/8/19 11:54, Mark Thomas wrote:
>> Konstantin,
>>
>> On 11/7/19 15:20, Konstantin Kolinko wrote:
>>> чт, 7 нояб. 2019 г. в 17:11, Christopher Schultz
>>> <ch...@christopherschultz.net>:
>>>>
>>>> I'm using bin/catalina.sh start to launch Tomcat on Macos.
>>>> The 'ps' command shows the following partial command-line:
>>>>
>>>> [...] -
>>>> -Djava.util.logging.config.file=${CATALINA_BASE}/conf/logging.prope
rt
>>
>>>>
ies
>>>>
>>>>
>> -
>> -Djava.util.logging.manager=org.apache.juli.ClassLoaderLogManager
>> [... ]
>>>>
>>>> The file ${CATALINA_BASE}/conf/logging.properties does
>>>> indeed have the changes below.
>>
>>> OK, good.
>>
>>> (I hope that `ps` shows the actual path to logging.properties.
>>> There should not be unexpanded reference to a environment
>>> variable above.)
>>
>> Yep. I hand-edited that to shorten the real path.
>>
>>> This reminds me: ClassLoaderLogManager allows each web
>>> application to have its own configuration of logging. If you
>>> have a "logging.properties" file elsewhere in classpath of that
>>> web application, it will have precedence over the default one.
>>
>>> The recommended use of this technology is to place your
>>> configuration into WEB-INF/classes/logging.properties file of
>>> your web application.
>>
>> My web application DOES have a WEB-INF/classes/logging.properties
>> and it does indeed say nothing about the CsrfPreventionFilter.
>>
>> Since the TCCL is the WebappClassloader during execution of the
>> Filter (it's defined in my app's WEB-INF/web.xml file), it must
>> be using the application's logging.properties and not the global
>> one.
>>
>> This makes sense and is a little irritating to me, but
>> definitely fixable. I'll double-check that this is the case,
>> shortly.
>>
>> I think I'm going to commit my trace logging to
>> CsrfPreventionFilter because I find it helpful to see what's
>> happening in there when trying to deploy CSRF protections.
>
> +1 but please use debug. Tomcat generally doesn't use trace. The
> expectation is that debug enables all logging.
Really? I'm happy to use whatever you guys recommend, but this will do
things like:
log.debug("Generating new CSRF nonce for session " + sessionId + ":
" nonceValue);
...
log.debug("Evicting CSRF nonce for session " + sessionId + ": " +
nonceValue);
...
log.debug("Rejecting request for " + requestURI + " to session " +
sessionId + " for invalid CSRF nonce: " + nonceValue);
That's .... super chatty. I suppose you can always set the .level for
this class specifically.
In my own code, I tend to differentiate between trace and debug in
this way:
1. TRACE tells you everything that happens
2. DEBUG tells you when something out of the ordinary happens
In the above examples, TRACE would apply (using my policy) to the
"generating" and "evicting" messages, but DEBUG would apply when
logging the rejection of the request.
- -chris
-----BEGIN PGP SIGNATURE-----
Comment: Using GnuPG with Thunderbird - https://www.enigmail.net/
iQIzBAEBCAAdFiEEMmKgYcQvxMe7tcJcHPApP6U8pFgFAl3FpQoACgkQHPApP6U8
pFjt6A/+MtAJyh6pLcigwvfqMVOsoQ1MH7Lq+I/X1xR6ScfTds2UBNRV1iGBr2gw
KjqC5eX+oIpmNo4ON0Vh53VgskKplwGR6bio2Jexy7f9HEf7j/4gW73GQBV8Fm0/
CtiIg3zjCLAYlXYnslt6vdc1X6GlxwtRvFI/TXAzwSWUY+FJpfvZHx2M+6kTV6zW
qFKtDzryvh2jNmwFjrkiJsMuLgCthWKCRHFVxImqc1RG5e8hRQbZ5hUm9WUXu0dH
3Y+ZdFHT+yVJxPS4RBtursic8g25PI9Sg1tI/W77ewP+SY9V8i1LNJwVK/GkSh8w
yhc2Dol/bIGGLNsxY9IjgwbdQyeTfXXJ5b6wm0pG5tLI+D0trVUX7CxBHi6XenSb
kRYKPjWbAwV+Ss7eZNBu5jei4DvF3V8m2oUXxBNAipSV8T8Z1G29/b137146feqq
Y4Tsz8Rodmks4k+o8neYDI2CQ+sN9JYFhKsKxlKFrVh/vvaCBxPL6rpJarCUUSKe
LKDkT/HsjZxvAKLpDqnJuILxsoxrKKg+KdsjMu7SSZ4kPmAGdW5EFRwPhsdaXmxn
3ITJyGtNSKCGBTC6bZI1FjKmstwTFEKCJHQVcAD26wnfMbmc7zyta2uH3OLIatSt
dw+iOOkKg9zGU3icvpB6bHwhrn2B/QNWDq03TzdUu+ts18PU5NY=
=Q/4i
-----END PGP SIGNATURE-----
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
For additional commands, e-mail: users-h...@tomcat.apache.org
