Few months ago I wrote about how to use securesocial and play2-memcached plugins together.
In the meantime, few things changed and combining SecureSocial with play2-memcached becomes really straightforward.
I want to show you how this new solution was born and how you can use it.
Fix for empty keys
I send a pull request to the play2-memcached repository containing a solution for the empty keys problem. I change plugin behaviour a bit by ignoring cache queries & commands for empty keys – In my opinion it’s better to exclude some values from caching instead of throwing an exception.
It’s reasonable especially while there is some kind of a “lack of key’s invariant” in the Play’s CacheAPI, which could be a one-way ticket to the world of pain if you decide to change the cache implementation.
Mumoshu (plugin maintainer) agreed with my point of view and merged my pull request.
Therefore if you’re using play2-memcached >=0.5.0-RC1 you don’t need to extend SecureSocial’s DefaultAuthenticatorStore anymore.
Fix for too long keys
There was yet another problem, but this time with another SecureSocial component,
IdGenerator, which produced UserIds bigger than 125 bytes (250 chars).
This problem can be solved in the following two ways:
- Using new securesocial configuration property:
This settings used with securesocial >=2.1.2 allows you to customize length of the UserId generated by DefaultIdGenerator. Set its value to 125 (minus size of the
memcached.namespace(in bytes!), if set to any) to avoid “IllegalStateException: key is too long” exceptions:
securesocial.idLengthInBytes = 125
This setting is also described at official documentation (see global settings section).
- Using new configuration parameter (currently available only in master snapshot) for play2-memcached:
This feature (proposed and implemented by s-a-y) for play2-memcached plugin allows you to using keys longest than 250 chars by hashing them before delegating your requests to the underlying implementation (spymemcached).
You can enable this hasher by setting
memcached.hashkeysproperty to one of the following supported hash algorithms:
MD2, MD5, SHA-1, SHA-256, SHA-384, SHA-512
For example, to start hashing keys using SHA-1, add the following property to your application’s configuration:
memcached.hashkeys = SHA-1
To disable hasher use “
off” (it is a default value).
Which solution to choose?
If you want to fix all kind of key-length issues (not only this one, related to SecureSocial plugin integration) in one place, by one-shot and you are able to deal with some performance overhead, you don’t share cache between apps/instances and it’s not that big deal to invalidate whole cache after enable hasher (or change its algorithm) – use hasher.
In all other cases choose the first solution.