Hey Wes,
Glad you got it working.
I shall be attempting to re-integrate devise into an ongoing project
as I've attempted earlier.
Just a few comments:
Step4: It now makes sense. I was not careful at looking at what gets
called and from where. This is where I gave up on my early attempt.
Thank you!
Step5: You can use radiant_layout to use one of the layouts defined in
radiant cms for your extension. For that you need shared_layouts
extension. This cuts down on the having duplicated code for layout,
which, in my case, remains the same as the main site.
On Oct 16, 5:03 pm, Wes Gamble <we...@att.net> wrote:
> 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'm executing the line below in my custom application extension):
>
> #Use Devise to protect all Radiant-generated end-user content
> SiteController.class_eval do
> #Don't authenticate CSS or JS requests, as these will do redirects
> def devise_authentication
> authenticate_custom_user! unless params[:url] &&
> params[:url].is_a?(Array) && (params[:url].include?('css') ||
> params[:url].include?('js'))
> end
>
> prepend_before_filter :devise_authentication
> 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. 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).
>
> 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.
>
> 8) Unfortunately, the redirect on a sign_out does not redirect back to
> the log in page by default (I need to resolve this), so I had to do the
> following in my DeviseController:
>
> def after_sign_out_path_for(resource_or_scope)
> new_custom_user_session_path
> end
>
> 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 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.
