Securesocial Login not working with Memcache in a play framework setup

[vishwasg1974]

I have a working app using SecureSocial login in a play framework setup - works nicely with EHCache in a single server setup. I am trying to distribute this app and was trying to use MemCache. Now Secure social login is not working.

I am pasting 2 debug messages from SecureSocial module 1 after the other. 1st message showing that the user is logged in and the 2nd showing that the user is not logged in.

07-10-2014 19:18:32 - [debug] application - [securesocial] user logged in
07-10-2014 19:18:33 - [debug] application - [securesocial] anonymous user trying to access : /Conversations?pgn=1
This is in a localhost setup and is for the same user. This is strange. Thoughts?

play.plugins config:

1500:com.typesafe.plugin.CommonsMailerPlugin
5000:com.github.mumoshu.play2.memcached.MemcachedPlugin
9994:securesocial.core.DefaultAuthenticatorStore
9995:securesocial.core.DefaultIdGenerator
9996:securesocial.core.providers.utils.DefaultPasswordValidator
9997:controllers.MyViews
9998:service.MyUserService
9999:securesocial.core.providers.utils.BCryptPasswordHasher
10001:securesocial.core.providers.FacebookProvider
10002:securesocial.core.providers.GoogleProvider

application.conf:

ehcacheplugin=disabled
memcached=enabled
memcached.host="127.0.0.1:11211"

[jaliss]

Do you see anything on the memcache logs?

[vishwasg1974]

MemCache logs for a login attempt. I do not understand this. Please have a look and comment.

21: going from conn_read to conn_parse_cmd
<21 set be704cca-ee31-4e2d-9b4e-82f90a79280d 0 300 36
21: going from conn_parse_cmd to conn_nread

NOT FOUND be704cca-ee31-4e2d-9b4e-82f90a79280d
21 STORED
21: going from conn_nread to conn_write
21: going from conn_write to conn_new_cmd
21: going from conn_new_cmd to conn_waiting
21: going from conn_waiting to conn_read
21: going from conn_read to conn_parse_cmd
<21 get be704cca-ee31-4e2d-9b4e-82f90a79280d
FOUND KEY be704cca-ee31-4e2d-9b4e-82f90a79280d
21 sending key be704cca-ee31-4e2d-9b4e-82f90a79280d
21 END
21: going from conn_parse_cmd to conn_mwrite
21: going from conn_mwrite to conn_new_cmd
21: going from conn_new_cmd to conn_waiting
21: going from conn_waiting to conn_read
21: going from conn_read to conn_parse_cmd
<21 set c56511b556ca1f8ac38adb468a1f55355c900132a00f6105fb44c934a99b0fc29e3c49c44255805daf95591cda5967869477a275f13ed9aee071bef68d214e1657aa5cdebcd8f7c84d1a3cb1ec83629a0f9dfde85a93f6557f9b5712738c76bcd07de53e81e80e373a37bc4fc2b1d023eab76c8d3efe8c71aadb399001 1 5999940 849
21: going from conn_parse_cmd to conn_nread
NOT FOUND c56511b556ca1f8ac38adb468a1f55355c900132a00f6105fb44c934a99b0fc29e3c49c44255805daf95591cda5967869477a275f13ed9aee071bef68d214e1657aa5cdebcd8f7c84d1a3cb1ec83629a0f9dfde85a93f6557f9b5712738c76bcd07de53e81e80e373a37bc4fc2b1d023eab76c8d3efe8c71aadb399001
21 STORED
21: going from conn_nread to conn_write
21: going from conn_write to conn_new_cmd
21: going from conn_new_cmd to conn_waiting
21: going from conn_waiting to conn_read
21: going from conn_read to conn_parse_cmd
<21 get c56511b556ca1f8ac38adb468a1f55355c900132a00f6105fb44c934a99b0fc29e3c49c44255805daf95591cda5967869477a275f13ed9aee071bef68d214e1657aa5cdebcd8f7c84d1a3cb1ec83629a0f9dfde85a93f6557f9b5712738c76bcd07de53e81e80e373a37bc4fc2b1d023eab76c8d3efe8c71aadb399001
FOUND KEY c56511b556ca1f8ac38adb468a1f55355c900132a00f6105fb44c934a99b0fc29e3c49c44255805daf95591cda5967869477a275f13ed9aee071bef68d214e1657aa5cdebcd8f7c84d1a3cb1ec83629a0f9dfde85a93f6557f9b5712738c76bcd07de53e81e80e373a37bc4fc2b1d023eab76c8d3efe8c71aadb399001 -nuked by expire
21 END
21: going from conn_parse_cmd to conn_mwrite
21: going from conn_mwrite to conn_new_cmd
21: going from conn_new_cmd to conn_waiting
21: going from conn_waiting to conn_read
21: going from conn_read to conn_parse_cmd
<21 get c56511b556ca1f8ac38adb468a1f55355c900132a00f6105fb44c934a99b0fc29e3c49c44255805daf95591cda5967869477a275f13ed9aee071bef68d214e1657aa5cdebcd8f7c84d1a3cb1ec83629a0f9dfde85a93f6557f9b5712738c76bcd07de53e81e80e373a37bc4fc2b1d023eab76c8d3efe8c71aadb399001
NOT FOUND c56511b556ca1f8ac38adb468a1f55355c900132a00f6105fb44c934a99b0fc29e3c49c44255805daf95591cda5967869477a275f13ed9aee071bef68d214e1657aa5cdebcd8f7c84d1a3cb1ec83629a0f9dfde85a93f6557f9b5712738c76bcd07de53e81e80e373a37bc4fc2b1d023eab76c8d3efe8c71aadb399001
21 END
21: going from conn_parse_cmd to conn_mwrite
21: going from conn_mwrite to conn_new_cmd
21: going from conn_new_cmd to conn_waiting
21: going from conn_waiting to conn_read

[jang1lee]

You might want to check if the key length is not over 255 when you use the Memcached. The maximum length of a key in Memcached is 255. If you look into the securesocial.core.authenticator.IdGenerator, the key length can be 256 (= 128 * 2). You need to override IdSizeInByte to be less than 128.

[vishwasg1974]

My current setting is:
#
# 125 bytes for keys
#
idLengthInBytes=125

[vishwasg1974]

Thoughts, please?

[jang1lee]

It seems that some of the keys are expired. Can you verify that the keys are still valid using the memcached console?

[jaliss]

@vishwasg1974 did you verify the keys are valid as @jang1lee suggested?

[vishwasg1974]

I have not verified this yet. Got tied up with few other things.

Is there any other way to use secure social in a distributed way? Maybe by storing the state in client side cookies?

Please suggest.

Thanks and best regards
Vishwas

Sent from my iPhone

On 11-Dec-2014, at 1:42 am, Jorge [email protected] wrote:

@vishwasg1974 did you verify the keys are valid as @jang1lee suggested?

—
Reply to this email directly or view it on GitHub.

[vishwasg1974]

Folks,

Is it possible to store the state in a client side cookie so i do not need a distributed cache for SecureSocial to work?

[mauu-alpha]

@vishwasg1974 I think i know what it is, i was having the same problem.
Can you please paste your cookie config from the securesocial.conf file ?

Originally when i was using ehcache i had in idleTimeoutInMinutes and absoluteTimeoutInMinutes really big numbers and everything was working fine, but when i changed to memcachedi was having the same problem that you describe, the keys were expiring too fast or at least thats what i thought.
Anyway finally i changed this two values idleTimeoutInMinutes and absoluteTimeoutInMinutes to 43200 and now its working.

Why this value? Its the maximum value that memcached supports (which is 30 days), as you can read in the doc:

Expiration times can be set from 0, meaning "never expire", to 30 days. Any time higher than 30 days is interpreted as a unix timestamp date. If you want to expire an object on january 1st of next year, this is how you do that.
For more info: https://code.google.com/p/memcached/wiki/NewProgramming#Expiration

Finally, taking into account this limitation with memcached, i would suggest an options to persist the credentials indefinitely or an option to set the expiration date rather than a time value