A simple EhCache3 based EventLogger

If you are using EhCache3 and need to know when a cache entry is created, updated etc. you can implement a simple EventLogger like this:

public class EventLogger implements CacheEventListener<Object> {
    
    private static final Logger LOG = LoggerFactory.getLogger(EventLogger.class);

    @Override
    public void onEvent(CacheEvent event) {
        if (LOG.isDebugEnabled()) {
            LOG.debug("CacheEvent {} with key {}", event.getType(), event.getKey());
        }
    }
}

Now you include the EventLogger in the ehcache.xml:

<config xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xmlns="http://www.ehcache.org/v3"
    xsi:schemaLocation="http://www.ehcache.org/v3 http://www.ehcache.org/schema/ehcache-core-3.0.xsd">

    <cache-template name="default">
        <listeners>
            <listener>
                <class>de.engelh.EventLogger</class>
                <event-firing-mode>ASYNCHRONOUS</event-firing-mode>
                <event-ordering-mode>UNORDERED</event-ordering-mode>
                <events-to-fire-on>CREATED</events-to-fire-on>
                <events-to-fire-on>UPDATED</events-to-fire-on>
                <events-to-fire-on>EXPIRED</events-to-fire-on>
                <events-to-fire-on>REMOVED</events-to-fire-on>
                <events-to-fire-on>EVICTED</events-to-fire-on>
            </listener>
        </listeners>
    </cache-template>
    
    <cache alias="someCache" uses-template="default">
	...
    </cache>

</config>
Round red and white Trust signage

Security Flaw: Don’t use @Cacheable on Methods handling Access-Control

Introduction

I recently stumbled over the following code in our codebase:

// Security flaw!
@Cacheable("permissionsOnContracts")
public boolean isAllowedToRead(ContractId contractId) {
    return expensiveOperationOrRemoteCall(contractId); 
}

The intent of the Cacheable-Annotation was obviously to reduce calls of #expensiveOperationOrRemoteCall, which makes sense in a way, especially when #isAllowedToRead is called often. Note that the #expensiveOperationOrRemoteCall determines the calling user internally by itself (eg. by using the SecurityContext, an OAuth2-Token, …).

It also introduces a severe security problem.

Read more

Using Spring Boot Devtools with LiveReload

The (very) short introduction

Using the Spring Boot Devtools can help to increase your development speed. Simply put the corresponding Spring Boot Starter into your application’s dependency tree and voilà—restart, reload, development-optimised settings, … (obviously I’m still in the “wow-that-is-sooooo-amazing”-phase and haven’t had any issues with the devtools so far. Which explains my enthusiasm.).

Nonetheless, including the Spring Boot Devtools in your application will also start a LiveReload-Server:

The spring-boot-devtools module includes an embedded LiveReload server that can be used to trigger a browser refresh when a resource is changed. LiveReload browser extensions are freely available for Chrome, Firefox and Safari from livereload.com.

(Taken from https://docs.spring.io/spring-boot/docs/current/reference/htmlsingle/#using-boot-devtools-livereload

And that’s where the fun begins: most of the plugins are outdated; don’t connect to a LiveReload-Server, but rather simply refreshe the current tab in a given interval; or aren’t that popular (in downloads/likes/whatever) that I want them to be running in my browser.

But there is another solution: a little JavaScript (livereload-js) which could be included in your HTML. This little script connects to a LiveReload-Server and reloads the current page whenever the server tells it to.

Read more

Top