Logging unauthorized request (error chain) about logbook HOT 7 CLOSED

Maybe we just add a note in the README that error dispatch should not be used in such cases (or "must be handled by the dev").

We should still do the logging in a try-finally.

from logbook.

• discourage use of ERROR dispatch in README
• remove ERROR dispatch from examples
• remove ERROR dispatch from Auto Configuration
• log responses in authorized filter in a try-finally block
• treat exceptions during chain execution in unauthorized filter as unauthorized requests (as long as the second filter didn't log them already? @lukasniemeier)
• switch to jetty-based tests for logbook-servlet

from logbook.

as long as the second filter didn't log them already?

I am trying to identify the scenario: something after the authorized filter throws an exception, the authorized filter logs the response (bullet point 4), now the unauthorized filter would log the response again (due to the exception-as-unauthorized semantic). Correct?

If we would want to prevent such scenario the two filters would need to be linked somehow, so that the unauthorized filter knows to be silent. Is this something special for this two-filter-security setup?

from logbook.

I am trying to identify the scenario: something after the authorized filter throws an exception, the authorized filter logs the response (bullet point 4), now the unauthorized filter would log the response again (due to the exception-as-unauthorized semantic). Correct?

Correct.

If we would want to prevent such scenario the two filters would need to be linked somehow, so that the unauthorized filter knows to be silent.

Exactly.

Is this something special for this two-filter-security setup?

Yes, I think it would only apply in that case.

Communication between the filters can be done using request attributes.

from logbook.

Working on

• log responses in authorized filter in a try-finally block
• treat exceptions during chain execution in unauthorized filter as unauthorized requests (as long as the second filter didn't log them already)

in https://github.com/lukasniemeier-zalando/logbook/tree/log-despite-exception

from logbook.

After looking into this again I think we should not continue with the proposed change to always log responses in the authorized filter.

If there is a chain exception the state of the response that the filter will capture may not represent what is actually returned to the client. Other filters or the servlet container may decide to output something else. This is for example the case if you use Undertow and deactivate the error chain completely. Logbook would log an empty 200 response despite the client would actually receive a 500 (written by Undertow itself).

• If there is an exception after the authorized filter Logbook would log the request but no response. In the end users would need to leverage the logging of the container to see what is going on.
• If there is an exception before the authorized filter we could stick with the change of the unauthorized filter (exception as unauthorized) - Logbook would log a partial log.
• If there is an exception before the unauthorized filter... 😉

Therefore I am proposing to just implement the exception-as-unauthorized semantic.

from logbook.

Therefore I am proposing to just implement the exception-as-unauthorized semantic.

Agreed.

from logbook.