[
http://jira.qos.ch/browse/LBCLASSIC-185?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=11513#action_11513
]
Ralph Goers edited comment on LBCLASSIC-185 at 2/5/10 8:43 AM:
---------------------------------------------------------------
I don't have a problem with adding this to logback-examples but it isn't
appropriate to add to logback-classic as there is no "correct" way to do this.
For example,http://www.slf4j.org/extensions.html#event_logger shows code that
works differently. In a lot of my implementations we have a hook into log in
that captures most of the information in a Map that is stored in the session.
Then the servlet filter just copies everything in the Map into the MDC and then
adds a couple of request specific values.
Furthermore, while it is a good goal to standardize some of these names in the
MDC, doing that in a ServletFilter is horrible. We have implemented a class
named RequestContext just for that purpose. It has all the key name constants
and provides static methods such as
public static String getRequestId() {
return MDC.get(REQUEST_ID);
}
That class becomes the glue to bind things together, not the ServletFilter.
One other issue with this code is that it puts the session id into the MDC
where it can potentially be logged. There is no good reason to do this and it
should never be logged as it makes the application susceptible to session
hijacking. See
http://www.owasp.org/index.php/Top_10_2007-Broken_Authentication_and_Session_Management.
Instead, a psuedo sessionid, such as a generated UUID, should be used in its
place to correlate all the requests in a session.
was (Author: [email protected]):
I don't have a problem with adding this to logback-examples but it isn't
appropriate to add to logback-classic as there is no "correct" way to do this.
For example,http://www.slf4j.org/extensions.html#event_logger shows code that
works differently. In a lot of my implementations we have a hook into log in
that captures most of the information in a Map that is stored in the session.
Then the servlet filter just copies everything in the Map into the MDC and then
adds a couple of request specific values.
Furthermore, while it is a good goal to standardize some of these names in the
MDC, doing that in a ServletFilter is horrible. We have implemented a class
named RequestContext just for that purpose. It has all the key name constants
and provides static methods such as
public static String getRequestId() {
return MDC.get(REQUEST_ID);
}
That class becomes the glue to bind things together, not the ServletFilter.
One other issue with this code is that it puts the session id into the request.
There is no good reason to do this and it should never be logged as it makes
the application susceptible to session hijacking. See
http://www.owasp.org/index.php/Top_10_2007-Broken_Authentication_and_Session_Management
> Servlet filter which puts servlet-specific data into MDC
> --------------------------------------------------------
>
> Key: LBCLASSIC-185
> URL: http://jira.qos.ch/browse/LBCLASSIC-185
> Project: logback-classic
> Issue Type: New Feature
> Components: Other
> Affects Versions: 0.9.18
> Reporter: Torsten Juergeleit
> Assignee: Ceki Gulcu
> Attachments: logback-test.xml, RequestLogFilter.java,
> RequestLogFilterTest.java
>
>
> Attached you can find a servlet filter which implements a strategy to put
> servlet-specific data into the SL4F MDC using the following keys:
> * {{slf4j.servlet.requestId}} - Unique ID of the single HTTP request handled
> by this filter
> * {{slf4j.servlet.sessionId}} - ID of the HTTP session this HTTP request is
> associated with or "" if no HTTP session was created yet
> * {{slf4j.servlet.contextPath}} - Web apps context path
> * {{slf4j.servlet.userName}} - Name of authenticated user or "" if no user is
> authenticated
> This data is removed after the request is processed.
> The following configuration parameters are supported by this filter:
> * {{maxSessionIdLength}} - limiting the HTTP session id length to a certain
> value, e.g. for WebLogic this could be 52 (default: -1 [unlimited])
> To use this filter add the following lines to the {{web.xml file}}:
> <code>
> <filter>
> <filter-name>RequestLogFilter</filter-name>
> <filter-class>ch.qos.logback.classic.RequestLogFilter</filter-class>
> <init-param>
> <param-name>maxSessionIdLength</param-name>
> <param-value>52</param-value>
> </init-param>
> </filter><br>
> :
> <filter-mapping>
> <filter-name>RequestLogFilter</filter-name>
> <url-pattern>/*</url-pattern>
> </filter-mapping>
> <code>
> An SLF4 Logger named {{ch.qos.logback.classic.RequestLogFilter}} is used to
> log the start end end of calling the filter chain. This information should go
> into a separate log file.
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
http://jira.qos.ch/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
_______________________________________________
logback-dev mailing list
[email protected]
http://qos.ch/mailman/listinfo/logback-dev
