Nexus 2.8+
- As the admin user, go to Administration -> Logging -> Loggers
- Click Add to enter a new Logger name. Enter
org.eclipse.jetty.server.Server
. Set the level toDEBUG
and Save. - Click Add to enter a new Logger Name. Enter
org.sonatype.security.internal.UserIdMdcHelper
. Set the level toTRACE
and Save.
Now all subsequent requests will print log lines in nexus.log
describing request, response and the authenticated user name that the request was made as. Example single request/response using the admin
user:
2014-06-03 20:48:57,638-0300 DEBUG [qtp1151354962-114] org.eclipse.jetty.server.Server - REQUEST /nexus/service/siesta/logging/loggers on AsyncHttpConnection@56c3c50a,g=HttpGenerator{s=0,h=-1,b=-1,c=-1},p=HttpParser{s=-5,l=10,c=0},r=25
2014-06-03 20:48:57,639-0300 TRACE [qtp1151354962-114] org.sonatype.security.internal.UserIdMdcHelper - Set: admin
2014-06-03 20:48:57,642-0300 DEBUG [qtp1151354962-114] org.eclipse.jetty.server.Server - RESPONSE /nexus/service/siesta/logging/loggers 200 handled=true
Nexus 2.6+
There are still a few edge cases where a log message may include an unrelated user name as part of the log pattern. This is a logging error and does not constitute a security escalation. We continue to track and fix these misleading messages. Your feedback as an issue is welcome for any unreported issues you encounter.
In some cases, Nexus 2.5 printed an incorrect userid in log messages if the executing thread was not a Jetty 'qtp' thread. We improved this problem so that each spawned thread should have the correct context of the user that launched the thread.
Nexus 2.5
Starting with Nexus 2.5, you can see the userid of the user requesting content from Nexus by looking in the nexus.log files.
If using Nexus 2.5 or greater, edit sonatype-work/nexus/conf/logback-nexus.xml and add
<logger name="org.sonatype.nexus.web.NexusRestletServlet" level="DEBUG" />
You should then see lines like this, where 'admin' is the user name of the user in this case:
2013-06-03 16:38:36 DEBUG [qtp1509640694-74] admin org.sonatype.nexus.web.NexusRestletServlet - Processing: HEAD /nexus/content/groups/public/junit/junit/4.11/junit-4.11.jar (http://localhost:8082/nexus/content/groups/public/junit/junit/4.11/junit-4.11.jar)
Note: Due to a bug in Nexus 2.5, only threads from Jetty's thread pool, starting with 'qtp', should be trusted to print the correct userid. All other threads which print a userid could be showing an incorrect userid. Nexus 2.6 fixes this.
Nexus 2.0-2.4
In earlier versions of Nexus, you can see the userid of the user and the path they are requesting by looking in the nexus.log files, after making some logging adjustments.
Edit sonatype-work/nexus/conf/logback-nexus.xml , adding:
<logger name="org.eclipse.jetty.server.AbstractHttpConnection" level="DEBUG" />
<logger name="org.apache.shiro.realm.AuthenticatingRealm" level="DEBUG" />
Also, edit the section:
<appender name="logfile" class="ch.qos.logback.core.rolling.RollingFileAppender">
<File>${appender.file}</File>
<Append>true</Append>
<encoder>
<pattern>${appender.pattern}</pattern>
</encoder>
<rollingPolicy class="ch.qos.logback.core.rolling.TimeBasedRollingPolicy">
<fileNamePattern>${appender.file}.%d{yyyy-MM-dd}.gz</fileNamePattern>
</rollingPolicy>
</appender>
to
<appender name="logfile" class="ch.qos.logback.core.rolling.RollingFileAppender">
<File>${appender.file}</File>
<Append>true</Append>
<encoder>
<pattern>%4d{yyyy-MM-dd HH:mm:ss} %-5p [%thread] %c - %m%n</pattern>
</encoder>
<rollingPolicy class="ch.qos.logback.core.rolling.TimeBasedRollingPolicy">
<fileNamePattern>${appender.file}.%d{yyyy-MM-dd}.gz</fileNamePattern>
</rollingPolicy>
</appender>
Note: This second change will prevent Nexus from picking up future appender pattern changes from logback.properties should you upgrade. Also the relative request path will now be printed as part of the Jetty thread id.
The result is you should see log lines similar to this in nexus.log:
2013-06-03 17:03:58 DEBUG [qtp2123009988-75 - /nexus/content/groups/public/junit/junit/maven-metadata.xml.sha1] org.apache.shiro.realm.AuthenticatingRealm - Looked up AuthenticationInfo [admin] from doGetAuthenticationInfo
0 Comments