1

I currently have the Logback SMTPAppender working with the following <appender> declaration inside my logback.xml configuration file:

<appender name="logManager-smtpAppender" class="ch.qos.logback.classic.net.SMTPAppender">
    <smtpHost>my-smtp-host</smtpHost>
    <to>john.smith@example.com</to>
    <from>no-reply@example.com</from>
    <username>my_user</username>
    <password>my_password</password>
    <subject>%logger{20} - %m</subject>
    <layout class="ch.qos.logback.classic.html.HTMLLayout"/>
    <cyclicBufferTracker class="ch.qos.logback.core.spi.CyclicBufferTracker">
        <bufferSize>1</bufferSize>
    </cyclicBufferTracker>
</appender>

This works fine, but I hate the fact that it forces me to specify username/password as plaintext. Ideally, I'd like to be able to read username and password from a keystore/realm/DB instead of hardcoding it into the XML file. Any remedies available? Or any other ideas? Thanks in advance!

IAmYourFaja
  • 55,468
  • 181
  • 466
  • 756
  • 1
    Logback allows you to pull the Mail session from a JNDI context. otherwise, if your installation will allow it, it is easy enough to subclass the SMTPAppender and add what you need. I suspect you can simply override the getUsername() and getPassword() methods with your own implementations. https://github.com/qos-ch/logback/blob/master/logback-core/src/main/java/ch/qos/logback/core/net/SMTPAppenderBase.java – Darius X. May 28 '13 at 20:36
  • Thanks @DariusX. (+1) - can you provide a working example of pulling the Mail session from a JNDI context? Or, if you would prefer to subclass `SMTPAppender`, can you provide an example? For that option, I'm worried that Joran would still be looking for `` and `` fields inside the `logback.xml` file...thanks again! – IAmYourFaja May 28 '13 at 22:13
  • You can retain the XML as is, just put some dummy information in there. In your subclass, simply override getUsername() and/or getPassword() to do whatever you wish. If you intend to use the existing class variables for username and password, also override setUsername() and setpassword() so that they do not do anything. – Darius X. May 29 '13 at 14:52
  • Needless to say, you might simply be exchanging one vulnerability for another if your custom code then has a userid in it, or something like that. After all, if you assume that someone can see your logback.xml, then they can probably see everything on your machine, and even decompile your custom code. – Darius X. May 29 '13 at 14:53

0 Answers0