[Owasp-appsensor-project] Filter HashMaps and Thread Safety

John Melton jtmelton at gmail.com
Mon Aug 15 16:22:57 EDT 2011


Owen,
I think your implementation is a fine idea. Without seeing all your code,
I'll just make some generic comments.
- Not sure if you're duplicating functionality already included in
appsensor, but the intrusionrecord/intrusionstore classes do keep track of
intrusions on a per user basis.
- Looks like you're quartz idea is great - clean up the maps regularly. I'm
not a quartz user, but if the performance is good and you're taking care of
the thread synchronization issues, then it sounds good to me.
- Your expiration idea is a good one, and not being certain of your full
implementation, looks reasonable. We do timestamp the intrusions in
appsensor, so it's possible you could accomplish the same thing just by
comparing the current time to that on the intrusion - just a thought.

All in all, nice work. Please do let us know if you put up a post about your
implementation. We'd love to see it.
Thanks,
John

On Fri, Aug 5, 2011 at 7:27 PM, Owen Berger <owen.k.berger at gmail.com> wrote:

> I just checked the codebase, and you did change the maps in the filters to
> ConcurrentHashMaps. I was looking at an old post somewhere, and neglected to
> double-check for the latest version of the filter code, my  bad.
>
> I have implemented an AppSensorManager class that is a Singleton, and
> stores both HashMaps as ConcurrentHashMaps. The filters then call on the
> AppSensorManager when necessary to change or look up information in the
> maps.
>
> In order to clean the map, I gave each key/value pair an expiration, in the
> form of an object (value) which is mapped to the sessionID (key) :
>
> private static class ClientIpAndExpire {
>         private String clientIp;
>         private DateTime expiration;
>         private ClientIpAndExpire (String ip) {
>             this.clientIp = ip;
>             this.expiration = new DateTime().plusMinutes(30);
>         }
>     }
>
>  I then used Quartz to come in and clean the map at regular intervals,
> removing old sessionId/ClientIP mappings.
>
> Does this look like an okay implementation of those filters?  Please
> remember that I am an amateur developer and am interested in learning as
> much as possible, so any tweaks or flat-out problems that you see, please
> let me know about them.
>
> Thank you and enjoy your vacation.
>
> -Owen Berger
>
> p.s. I will put up a post about my use case in a couple of days.
>
>
> On Fri, Aug 5, 2011 at 5:39 AM, John Melton <jtmelton at gmail.com> wrote:
>
>> Owen,
>> I'm the lead dev, but am on vacation at the moment. I'll take care of
>> these when I get back next week sometime.
>> Thanks,
>> John
>>
>> On Thu, Aug 4, 2011 at 9:52 PM, Owen Berger <owen.k.berger at gmail.com>wrote:
>>
>>> This is my first time on the appsensor list, so please let me know if my
>>> questions have been asked before and I missed it.
>>>
>> Welcome - glad you're looking into it. If you want to [and are able] to
>> share your use case, please do - we're interested in gathering info about
>> how folks are using appsensor.
>>
>>>
>>> -What is the best way to implement a thread-safe version of the Static
>>> HashMap used in the User Agent and Client IP filters?
>>>
>> I updated the codebase recently to use concurrenthashmaps but I might have
>> missed these places. I'll look when I get back from vacation.
>>
>>>
>>> -Are the Maps thread-safe as is, e.g. as Static maps inside the filter,
>>> or would a singleton using a ConcurrentHashMap do the same or better job for
>>> a web application where state is needed?
>>>
>> These are not thread-safe as is as you mention. They were very simple
>> examples as you can see, so are not "production" quality. If you end up
>> making useful changes, please feel free to share back and we can improve
>> them.
>>
>>>
>>> -I would like to make the maps subject to a cleaner that removes all of
>>> the old map entries utilizing a Job in Quartz, so is that still possible in
>>> the filter if I use the Static HashMap?
>>>
>> I've thought a bit about your point of the "cleansing" routine. I don't
>> think it would work well in it's current incarnation, but you should be able
>> to move it out to a context style object, make it thread safe and then
>> access it from both the filter and your quartz job.
>>
>>>
>>> Thanks for any help or direction,
>>>
>>> -Owen
>>>
>>>
>>> _______________________________________________
>>> Owasp-appsensor-project mailing list
>>> Owasp-appsensor-project at lists.owasp.org
>>> https://lists.owasp.org/mailman/listinfo/owasp-appsensor-project
>>>
>>>
>>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: https://lists.owasp.org/pipermail/owasp-appsensor-project/attachments/20110815/b340166b/attachment.html 


More information about the Owasp-appsensor-project mailing list