[logback-dev] [JIRA] Issue Comment Edited: (LBCLASSIC-185) Servlet filter which puts servlet-specific data into MDC

[Ralph Goers (JIRA)]

    [ 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: rgoers at apache.org):
    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