You can clone with
HTTPS or Subversion.
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?
Quack, quack, quack. Use duck typing instead of hardcoding everything…
…, closes #1281.