I need to validate the logs currently being written using log4j2 for sanitizing the input passed to it. I see ESAPI API provides an option to sanitize the input passed to it.
My question is I am not sure how I can use the ESAPI with logging methods.
Is there something like a filter or interceptor which I need to add for while logging in my methods to transparently filter and sanitise the logged text accordingly or should I write a custom Logger Class which extends the base Logger class and then logs accordingly by wrapping the call to ESAPI api.
If anyone has faced a similar issue can you please help me on this.
I’m guessing that with “sanitise” you mean things like obfuscating password strings and perhaps replacing IDs with tokens.
Log4j2 provides a Rewrite appender that allows you to replace a LogEvent with another LogEvent before it’s passed to the destination (e.g. File) Appender.
Alternatively you can use Log4j2 Filters to prevent some log events from going to certain (or all) appenders. This may be too drastic for your needs.
Related
I use #Slf4j to add logs in all layers in my SpringBoot project.
I want to use some unque ID for all logs inside onq request.
For example generate UUID at the RestController and automatic add it to every logs in this thread
For example
[..... Some UUID ....] "The real logger message"
How to do this?
It need to have possibility to filter all logs of specific request.
If your application is threaded (or any better word to describe "opposed to a reactive application where it might be possible that everything happens in the main thread"), use the mapped diagnostic context (MDC). The MDC is a thread-bound Key-Value Map, where you can put and retrieve data. Baeldung has a tutorial on logging with the mdc using multiple logging frameworks. Also, there are plenty of examples across the web.
If your application should be reactive, you may wanna check out this project reactor reference.
My program has an underlaying system that persist every log in elasticsearch.
I have a class that fetches data online and logs it with slf4j log.error(data).
This allow the underlaying system to persist the log in elasticsearch, but it also floods the console with every fetched data.
I wish to disable the consoleAppender just for this specific class.
I've seen other post where people would disable the consoleAppender with logback or would exclude all logging from a specific class, but I couldn't find any information on how to disable one logger in one class.
Is this possible?
It sounds like you just need to set the logging level for that class. Set it to ERROR, WARN or another level, depending on the level of the messages that are flooding the console. Try modifying the application.properties file by adding something like:
logging.level.com.test.MyClass=WARN
We're using Jasypt to encrypt some config properties (database passwords) but since the decryption key is stored on each environment's file system we have to do some manual #Bean configuration to load the password from the file then overlay loading properties with an EncryptablePropertiesPropertySource.
Because it is so manual we've had to run this code in #PostConstruct of the WebApplicationConfig class and (although this hasn't happened yet) it runs the risk of loading these after the datasource bean is configured with calls to the Environment - giving null pointer exception. #Lazy loading would be an option but obviously this means we'd then be working with fragile config which we'd like to avoid.
Ultimately we want to be able to use the default classpath:application.properties so don't want to affect existing (default) setup, but we do want to be able to use an encryptable property source as a complete replacement to the Spring one, and to have Spring load the decryption code from a file before anything else happens. Is there a way to tighter integrate loading encryptable properties earlier in the application startup and configuration?
I'm "tailoring down" my previous answer since it got deleted because it was duplicate from a different question:
This library does exactly what you need jasypt-spring-boot which is basically to allow you use the #PropertySource annotation to define your properties the same way you're use to. You just have to add an extra annotation (#EnableEncryptableProperties) to your configuration file.
It is not only limited to that, every PropertySource present in Environment will be converted to EncryptablePropertySourceWrapper, a custom wrapper that checks when a property is encrypted and decrypts it on access.
The link Dave provided in the comments section unfortunately points to nothing now, but navigating from its root I got to the following example project:
https://github.com/spring-cloud-samples/configserver (also written mostly by Dave, of course)
I think it serves as a great example for what was discussed in the comments until now.
Also, for future reference (maybe it will be done at some point), there's a Spring Framework Jira ticket for the feature of using encrypted properties: https://jira.spring.io/browse/SPR-12420
I was wondering if there is any way already implemented in Apache Camel to be able to log to different loggers depending on the route. I am using Spring DSL to create the routes. My use case is that I want a different log file for each route I am defining.
Is that possible?
You can enabled MDC logging, which then include details about which route is currently being logged from: http://camel.apache.org/mdc-logging.html
Then the logging framework you use, such as log4j, logback, etc. can be configured to log to different appenders based on a MDC key (eg camel.routeId)
I am working on a well undocumented project and I was wondering if is it possible to get the controller used for a certain url or view?
Without knowing more information, one of the easiest ways is to turn on DEBUG logging for the Spring servlet. For example if you are using log4j:
log4j.logger.org.springframework.web.servlet=DEBUG
After you turn that on, you'll see log entries anytime a page is hit like this:
Mapping [/some/path] to HandlerExecutionChain with handler [com.myapp.controller.MyController#4cda661a]
Anyway, there are various ways to do this, including scanning the code for the view name or path. Another approach would be to create a interceptor that logs some additional information for every request.
You could try Spring Tool Suite (comes either standalone or as an add-on for Eclipse). It's essentially Eclipse with extra Spring-specific features, one of them is what you're looking for: