Re: [Radiant] Re: Using Devise as an authentication solution for end users with Radiant - updated
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
[Radiant] Re: Using Devise as an authentication solution for end users with Radiant - updated
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 -- Posted via http://www.ruby-forum.com/.
Re: [Radiant] Re: Using Devise as an authentication solution for end users with Radiant - updated
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
On Oct 27, 2010, at 12:10 AM, Hugo Villero wrote:
> 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:
>
> --
> 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"=>"hvill...@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
>
> --
> Posted via http://www.ruby-forum.com/.
[Radiant] Re: Using Devise as an authentication solution for end users with Radiant - updated
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:
--
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"=>"hvill...@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
--
Posted via http://www.ruby-forum.com/.
Re: [Radiant] Re: Using Devise as an authentication solution for end users with Radiant
Thx for the radiant_layout tip!
Sent from my iPhone
On Oct 17, 2010, at 12:05 PM, swartz wrote:
> 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 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
[Radiant] Re: Using Devise as an authentication solution for end users with Radiant
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 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.
