issue with Salesforce and memcache storageservice

[Marvin Addison]

>
> We're running into an issue where the session key being issued is too long
> for the spy memcache implementation:
>
> 11:53:07.995 - XXX.XXX.XXX.XXX - DEBUG
> [unimr.shib2.UniMrMemcachedStorageService:133] - storageService.get(
> replay,
> https://example.my.salesforce.com_2yXH_BiHmM6_STHvAyHiYsM8z6yLR4HP_lA94lj5IXktcoEq2dWTsKnS6iaJCKk1MPWSgcGpKraOAuPiOeMwNFQ2Rqdcy3exaDZSZAj8DodV7BnAt6ea8PJaEjEdblkhtsOQjMfvBDEBreKjFb7I3bIBKPPKdhpVhu3kdzZlagX7BTxDFY0s2B8lJsULn6jgfBhj9cq9epgOSIookTzaKlADAZfCFow)
> called.
> 11:53:08.012 - XXX.XXX.XXX.XXX - ERROR
> [edu.internet2.middleware.shibboleth.common.profile.ProfileRequestDispatcherServlet:88]
> - Error occurred while processing request
> java.lang.IllegalArgumentException: Key is too long (maxlen = 250)
>

Somewhat off-topic, but I wanted to mention that IdPv3 has explicit support
for StorageService keys over 250 bytes. At the time I was surprised to
learn that 250-byte keys are defined by the memcached protocol [1], so it's
a pretty well-defined limit in the service.


> Can the keys be reduced in length (via hashing?) before they're sent to
> the storage service?
>

That was the approach that I took with the v3 component. Maybe looking at
the approach there could help with backporting the feature?

M

[1] https://github.com/memcached/memcached/blob/master/doc/protocol.txt,
"Keys" section
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://shibboleth.net/pipermail/users/attachments/20150127/c9b78af6/attachment.html