Skip to content


Subversion checkout URL

You can clone with
Download ZIP


Warden::SessionSerializer requires a record #1281

mtodd opened this Issue · 9 comments

2 participants


With Devise loaded, I cannot also use non-Devise strategies with Warden to do separate, custom authentication for things that don't also serialize the way Devise expects.

For instance, I want to support API authentication using a custom strategy that doesn't actually authenticate a specific user so it'll only indicate success in general.

However, with the modifications to Warden::SessionSerializer, Warden is effectively broken for anything but Devise's uses.


We may be able to set up a session serializer specific to Devise instead of overwriting Warden's stock session serializer. I don't think it instantly solves this problem, but I think it's a better approach in general.



Yeah, just realized that after I posted the link.

Do you just want to be able to set it straight forward on the proxy? I'm still getting familiar with the Warden API so I don't necessarily know if the proxy is immediately accessible to be set on, etc. I wonder if it makes sense as a per-strategy thing, too.

I'd be happy to throw together a patch for Warden. Just looking for some more input from anyone with more familiarity.


That sounds about right.

So in the case where Devise would use a modified SessionSerializer, would the next step be to fix the modified SessionSerializer to not break for non-records or to just make it so Devise can use its own specialized SessionSerializer on a per-strategy basis?


Sounds good. Checking with @hassox to get an idea if this makes sense to go into warden. See: hassox/warden#28


After checking with @hassox, it seems that won't really work unless we change the serialization format to include which strategy should deserialize it. That could work, but he also provided a simple way to fix the Devise serialization/deserialization in order to support things like true.

This is a very specific solution, which I don't feel is exactly what we want here, but I think he might be on the right path. Here's a simple variation on his patch that might do the trick.

What do you think?


Hrm, I believe we fix this by using duck typing instead of explicitly checking the classes. On serialize, we could could call on the object:


That needs to return an array with n+1 elements and the first element must be the class name. On deserialization, we would get the class for the given class name and call:


This way, you would be able to make any object serializable into the session, without a need to hardcode something at all. What do you think?

@josevalim josevalim closed this in 7396c69
@adriandulic adriandulic referenced this issue from a commit
Commit has since been removed from the repository and is no longer available.
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Something went wrong with that request. Please try again.