Extending the Contentbox RateLimiter.cfc

Happy new year everyone.
I am working on a solution for a contetnbox site where one user cannot access the site with cookies. As I looked through the ContentBox settings in the past I knew that the rate limiter might cause some problems here. As my fears have been confirmed by some testing I will now need to modifiy the rate limiter and implement some kind of exclusion logik.
Sice I have not edited the Contentbox internal modules in the past, I would like to share my thoughts here.

I would not like to set the numer of allowed requests higher than what is needed for this usecase as this is a magnitude higher than the current setting.

My first thought was to set a value in the session storage when the session is created, I would then let the rate limiter look up this key in the session storage and tell it to treat this as if a cookie was existend. However, since I’m not ready to add the required session ID to every call (e.g. for images, scripts), this would fail on pages where many of these calls would have to be made by the client.

My second idea was to set an ip whitelist. However I would need to remove the entrys when the session is closed or suspended.

The third idea that came to my mind is to extend the existing logik and targetData struct.
If I detected a valid call (likely by a session parameter as described in my first idea) than a flag in the targetData struct should indicate that calls from this IP are legit. When another call from the same IP is detected the limiter should not count this call towards the allowable limit.
However a second duration setting could prevent that the IP would be whitelisted indefnietly.
When the “lastAttempt” is older that the set allowed time the request should count towards the limit.

function limiter( count, lockDuration, allowDuration, event, settings) {
var realIP = settingService.getRealIP();
var allowSession = sessionStorage.getVar( "ignoreRateLimiterForSession", false );
if( firstTimeVisit ) {
targetData = { type = allowSession ? "ALLOW" : "LOCK", attempts = allowSession ? 0 : 1, lastAttempt = now( ) };
return;
}
//I am replacing the needed if/else logic with cases for readability
case targetData.type == "ALLOW" && targetData.lastAttempt > allowDuration && !allowSession:
    targetData.type = "LOCK";
    targetData.attempts = 1;
    targetData.lastAttempt = now( );
case targetData.type == "ALLOW" && allowSession:
   targetData.lastAttempt = now( );
case targetData.type == "LOCK" && allowSession:
    targetData.type = "ALLOW";
    targetData.attempts = 0;
    targetData.lastAttempt = now( );
case targetData.type == "LOCK" && targetData.lastAttempt > lockDuration && targetData.attempts > count
    //BLOCK REQUEST
case targetData.type == "LOCK" && targetData.lastAttempt > lockDuration
    targetData.attempts++;
    targetData.lastAttempt = now( );
default:
//reset struct if none matches

Do you think there is another solution?
One thing I have noticed while going through the code:
The rate limiter seems to keep the stored targetData indefinetly. If many different bots from different destinations would access a contentbox site only a few times or only once this would increase the memory usage as we do not clean up the “limitData” struct. Could this be a potential cause of memory leaks?