devise incompatibilities with other gems based on warden

[Philipe Fatio]

Hey there, I'm developing a gem that brings easy GitHub authentication to rails.

It is called warden-github-rails and is built on top of warden-github which in turn is built on top of warden.

I've encountered some difficulties when using it in a rails app that also uses devise.

The problems I encountered which made it impossible to use my gem side by side with devise are:

1. Both gems add a Warden::Manager middleware which causes only the first instance to exist in a request.
   
2. Devise monkey patches Warden::SessionSerializer#serialize and #deserialize breaking the original user storage.
   

For (1), I've looked into hooking into the already defined middlewares and extend the existing Warden::Manager block to add my own warden configs.

This clearly isn't very nice and relies on accessing instance variables in Railties.

For (2), I'm not really sure what can be done. I saw that warden checks for a #{scope}_serialize and #{scope}_deserialize and call those if present, otherwise it call #serialize and #deserialize.

Now, I wanted to ask if it would be possible to circumvent these problems somehow or if it would be thinkable to add support to devise to be able to run side by side with other gems on top of warden.

Cheers,

Philipe  

[José Valim]

For (1), I've looked into hooking into the already defined middlewares and extend the existing Warden::Manager block to add my own warden configs.

In theory, warden-github would only provide a strategy and the application would be responsible to mount the manager with the required strategies. In Devise particular case, Devise assumes it should mount the manager into the application (as an application extension engine). If you are assuming the same role for warden-github-rails, I am aware that Warden in theory can work with many managers in this stack, not sure how well it works in practice.

 

For (2), I'm not really sure what can be done. I saw that warden checks for a #{scope}_serialize and #{scope}_deserialize and call those if present, otherwise it call #serialize and #deserialize.

Yes, Devise should rely on the scoped serialized versions. They are relatively new, we just need to improve Devise to do so.

[Philipe Fatio]

Thanks for answering, José.

For (1), I've looked into hooking into the already defined middlewares and extend the existing Warden::Manager block to add my own warden configs.

In theory, warden-github would only provide a strategy and the application would be responsible to mount the manager with the required strategies. In Devise particular case, Devise assumes it should mount the manager into the application (as an application extension engine). If you are assuming the same role for warden-github-rails, I am aware that Warden in theory can work with many managers in this stack, not sure how well it works in practice.

Well, from https://github.com/hassox/warden/blob/master/lib/warden/manager.rb#L30 it looks like multiple warden managers are not supported. The downstream manager just invokes the app without setting itself as the active manager.

I see a couple possibilities:

• Add some kind of config hook that is called when the middleware is instantiated. Then each warden user would have a chance to add configurations after initialization.
• Allow downstream warden managers to merge in their configs to the existing proxy (aka env[‚warden‘]). This would actually be quite strait forward.

Any thoughts? I’ll take a shot at the latter possibility.

 

For (2), I'm not really sure what can be done. I saw that warden checks for a #{scope}_serialize and #{scope}_deserialize and call those if present, otherwise it call #serialize and #deserialize.

Yes, Devise should rely on the scoped serialized versions. They are relatively new, we just need to improve Devise to do so.

OK, I’ll look into this and maybe make a pull request. Should I file an issue for that to have it on the radar?

[Jonathan Spooner]

I recently ran into your first problem when I added Devise to a project that uses rails-warden.  There are actually two middlewares in the stack RailsWarden::Manager and Warden::Manager however they both look at request.env['warden'].  

I know this post is old but what conclusion did you come to on this issue?

Thanks,

Jonathan