SecureScial & Memcached – never that easy!

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: securesocial.idLengthInBytes
    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: memcached.hashkeys
    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.hashkeys property 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.

Advertisements

3 thoughts on “SecureScial & Memcached – never that easy!

  1. Pingback: SecureSocial & Memcached | Dev's Pad
  2. Great write on SecureSocial and memcached – what do you mean by “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.”

    • Thanks!
      First of all – I don’t have exeprience with memcached, especially on a distributed systems, thus I admit that I may be completly wrong.

      I meant that both solutions have a different impact on a whole app.
      When you tune securesocial.idLengthInBytes, other parts of the application don’t see any difference, previously used keys will be still valid. It’s a client-side (client = securesocial) solution for too long keys problem.

      At the other hand, if you enable memcached.hashkeys mechanism, you will have a gap between keys used by an app and stored in memcached – not only for securesocial, but whole app. In this case you may have to invalidate (clear) whole cache.
      And the problem becomes bigger if you’re sharing single memcached instance between many applications, even that which don’t use securesocial/hashers – the invalidation will have an impact also on application that may even don’t use Play-framework or Scala at all.

      Such problem might never occur in 99% cases but I think that you should be aware of diference between tuning behaviour of a client and whole service, among of other aspects, like solutions’ performance.

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s