Forum: Radiant CMS Using Devise as an authentication solution for end users with Radiant - updated

(This is an updated version of a previous post.  Update to point #3.
Point #8 has been removed.  I'll be adding a Wiki article on this as 
well.)

All,

I've spent some time getting Devise working as an authentication system
for my end users, and thought I would share how I got it to work.

1) Because Radiant already has a User model, you have to set up Devise
to use a different model for authentication.  So, you should choose a
model name, and use that when you install Devise per the directions.
For the purposes of the rest of this explanation, let's assume that the
model name is CustomUser.

2) Do all of your setup for Devise for CustomUser, including setting up
the "devise_for" route (devise_for :custom_user, etc.).  I set up my
Devise route in my custom extension's routes.rb file.

3) To protect all of the end-user content, you need to call the Devise
authenticate method somewhere as a before_filter on the SiteController.
I did the following:

    a) created a module named ContentManagement which gets included into
SiteController (see (c) below)

    b) inside ContentManagement, I have the following method:

         #Don't authenticate CSS or JS requests, as these will do 
redirects
         def radiant_page_request?
           ! (params[:url] && params[:url].is_a?(Array) &&
(params[:url].include?('css') || params[:url].include?('js')))
         end

     c) In the custom extension file, I then do:
     SiteController.class_eval do
       include ContentManagement
       prepend_before_filter {|controller| controller.instance_eval
{authenticate_custom_user! if radiant_page_request?}}
     end

4) Once you do this, Devise will be set up to be used to authenticate
against your end-user content.  But it won't work, because both Devise
and Radiant inject a method named "authenticate" directly into the
ApplicationController via module inclusion (luckily, they have different
method signatures, or I would have had a tough time figuring that out).

I attempted to force the segregation of these two authenticate methods
using nothing but fancy metaprogramming to try and change inheritance
hierarchies and what-have-you.  I don't think that is possible,
actually.  Ultimately, I decided that the solution with the least
customization (and thus, easiest to manage over time), would be to
statically bypass the ApplicationController provided by Radiant in
Devise.  So...

5) Create a new controller named DeviseController that looks like:

class DeviseController < ActionController::Base
   layout 'devise'
end

I put mine in my custom extension's app/controllers directory, but you
can put it anywhere as long as it is loaded before any of the Devise 
stuff.

Also, notice that I built a custom layout for Devise (devise.html.haml)
that looks like my Radiant-managed layout for end-user content.

Yes, that means that changes to the layout within Radiant must be
repeated in this layout file.  However, I couldn't figure out a good way
to share the layouts (even using file_based_layout, I would have had
significant duplication to deal with - I decided to go the simplest
route).  You can't use radiant_layout to share an existing Radiant
layout since the Devise views are not rendered via SiteController.

6) Put a copy of the Devise gem into RAILS_ROOT (or
RADIANT_ROOT)/vendor/gems

7) In vendor/gems/devise/app/controllers, change each of the five 5
Devise controller's class definitions so that they descend from
DeviseController, instead of ApplicationController, like so:

class ConfirmationsController < DeviseController

Note that each of the 5 controllers does:

   include Devise::Controllers::InternalHelpers

and this is where the conflicting "authenticate" method comes from.  But
now, because there's no more ApplicationController in the hierarchy,
there is no conflict.

CAVEATS:

It is very important that the route file that pulls in the Devise route
executes before you attempt to use any of the Devise "custom_user"
specific helpers.  The route configuration is what creates all of the
Devise helpers that are then included in various places.  If you cause
any helper files to be included before the Devise route is processed,
none of the "custom_user" helper methods will be available.

Wes

P. S.  It would be interesting to see if it made sense to use Devise for
all Radiant authentication (e.g. both end users and Radiant users), as
Devise has authentication for different scopes baked in from the start.

Thank you very much for that post, I've been looking for that solution
to long time,  I already did all those changes and now
/custom_users/sign_up is working, I'm able to register, but the
/custom_users/sign_in doesn't work,  I'm getting this error as soon as I
push sign_in button and the app is trying the authenticate process:

----------
Processing SessionsController#create (for 127.0.0.1 at 2010-10-27
01:07:50) [POST]
  Parameters: {"commit"=>"Sign in", "custom_user"=>{"remember_me"=>"0",
"password"=>"calabaza", "email"=>"hvillero@gmail.com"}}

ArgumentError (wrong number of arguments (1 for 0)):
  devise (1.0.8) [v] app/controllers/sessions_controller.rb:19:in
`authenticate'
  devise (1.0.8) [v] app/controllers/sessions_controller.rb:19:in
`create'
  warden (0.10.7) lib/warden/manager.rb:35:in `call'
  warden (0.10.7) lib/warden/manager.rb:35:in `call'
  warden (0.10.7) lib/warden/manager.rb:34:in `catch'
  warden (0.10.7) lib/warden/manager.rb:34:in `call'

---------

Do you have any idea about how to solve it? I will really appreciate any
idea about that

Thank you very much for that post

Did you segregate the Devise controllers away from the 
ApplicationController?

What you're seeing is the collision between the Devise authenticate 
method and the LoginSystem (Radiant) authentication method.

You need to "vendor" Devise and change it's controllers to descend from 
ActinController:Base instead of ApplicationController.

W

Sent from my iPhone

Hi,

Thanks for the response,

yes, I already segregate the Devise controllers, I made a copy of devise
gem at :
/trunk/vendor/gems/devise-1.0.8, and I already change those 5
controllers to something like:

class ConfirmationsController < DeviseController

on each one

And I think is using that device gem in vendor, because that [v] that
appears on the error lines:

  devise (1.0.8) [v] app/controllers/sessions_controller.rb:19:in
`authenticate'
  devise (1.0.8) [v] app/controllers/sessions_controller.rb:19:in
`create'

But still I'm getting the error, any other idea?

Thank you very much

And the DeviseController inherits from ActionController::Base, right?

What is the before_filter line that you're using to authenticate through
Devise?

Wes

That was the problem

Thank you very much Wes, it was because I didn't have :

   DeviseController inherits from ActionController::Base

that was:

     class DeviseController < ActionController

That should be :

      class DeviseController < ActionController::Base

Thank you very much for your help, now that is working very good,

Good.  If you look at ApplicationController, you'll see the very first
thing it does is include the Radiant LoginSystem library, and that's
what collides with Devise.

class ApplicationController < ActionController::Base
   include LoginSystem

Glad to hear it's working.

Wes

Hi,
thanks a lot for your post.

Did you have to run:
ruby script/generate devise_views
or did you manage to add the views to the load path?

Without those views inside the extension I am getting a "Template is
missing" when I submit the forgot password for example.

Ta,
enrico