I was able to simply do it with def my_login_required login_required end
because CE's login_required is implemented in lib/ and so it's visible to my base_controller. Thanks! On Nov 3, 10:10 pm, GregL <[email protected]> wrote: > Oh! For some reason I thought Desert was just handling the models, and > the rest was from Rails' built-in engines support. I'm very glad to > know that because it will help me in future googling :) > > I will run with your idea to create my own login_required so I have my > own parallel universe for the filter. > > On Nov 3, 9:32 pm, Bruno Bornsztein <[email protected]> > wrote: > > > > > Yeah, unfortunately overriding filters is one of the weaknesses of > > Desert (remember, CE uses Desert, not Engines). What you really want > > to do is just add your own filter in your BaseController, so: > > > class BaseController < ApplicationController > > > before_filter :my_login_required > > > def my_login_required > > ... your logic here, try looking at the original login_required to > > see how it's done ... > > end > > > end > > > Good luck, > > Bruno > > > On Tue, Nov 3, 2009 at 8:28 PM, GregL <[email protected]> wrote: > > > > That works, thanks. > > > > Now my problem is that I need to do that for users, clippings, posts, > > > photos, ... everything. They are all written with before_filters that > > > list all the mutating actions in an :only list, so I have to gather > > > all those specific lists and copy them into my controllers, then edit > > > them. That's going to create so much fragility that I want to seek a > > > better solution if I can. > > > > What I don't understand, and have not found with Google, is a > > > definitive statement about how filters behave between engines and the > > > app. I want to override the filters, so it feels like saying > > > "before_filter :login_required" in my copy of base_controller.rb (or > > > users_controller.rb) ought to fire the filter before :show and all the > > > other methods not mentioned in CE's :only list, but somehow the fact > > > that CE uses :only makes that trump instead. > > > > On Nov 3, 8:30 pm, Jim Ruther Nill <[email protected]> wrote: > > >> Try this. > > > >> Copy the before_filter :login_required line in the users controller in > > >> the > > >> CE plugin. > > >> paste it in users_controller and add the show action. > > > >> before_filter :login_required, :only => [:edit, :edit_account, :update, > > >> :welcome_photo, :welcome_about, > > >> :welcome_invite, :return_admin, :assume, :featured, > > >> :toggle_featured, :edit_pro_details, :update_pro_details, :dashboard, > > >> :deactivate, > > >> :crop_profile_photo, :upload_profile_photo, :show] > > > >> that should keep anonymous users to browse user profiles. > > > >> On Wed, Nov 4, 2009 at 9:14 AM, GregL <[email protected]> wrote: > > > >> > Thank you Jim, that was very helpful. I want my site to be completely > > >> > hidden from non-logged-in users, so I needed to know which was the > > >> > appropriate before_filter for that. Sounds like login_required is the > > >> > best, though adding it to my override of base_controller did not stop > > >> > me from being able to see a user's profile ('/username', the show > > >> > action of the users controller), so I'm still debugging that. > > > >> > On Nov 2, 10:19 pm, Jim Ruther Nill <[email protected]> wrote: > > >> > > find_user: > > >> > > - finds the user whose login_slug is <APP_URL>/<login_slug> > > >> > > - used mostly in the users controller to determine to whom a certain > > >> > blog, > > >> > > photo, clipping, etc belongs to. > > > >> > > require_current_user > > >> > > - first finds user whose login_slug is <APP_URL>/<login_slug> and > > >> > compares > > >> > > it with current user > > >> > > - mostly used in actions that requires the current_users permission > > >> > (edit, > > >> > > update, create, new) > > > >> > > login_required > > >> > > - user needs to be logged in before performing a certain action like > > >> > > creating a comment. > > > >> > > the conditions > > > >> > > if logged_in? > > >> > > if current user > > > >> > > are basically the same. :D > > > >> > > On Tue, Nov 3, 2009 at 10:53 AM, GregL <[email protected]> wrote: > > > >> > > > Could someone help me understand the different use cases for these > > >> > > > methods: > > > >> > > > find_user > > >> > > > require_current_user > > >> > > > login_required > > > >> > > > For example, all three of those are used inside the > > >> > > > photos_controller > > >> > > > as before filters and I don't understand why. I want to make sure I > > >> > > > have consistent behavior between the built-in CE areas and my own > > >> > > > app's areas, so I need to understand the purpose of these to be > > >> > > > able > > >> > > > to use them correctly. > > > >> > > > And also, in some views like _header.html.haml, I see two similar- > > >> > > > looking conditions like: > > > >> > > > if logged_in? > > >> > > > if current_user > > > >> > > > I can read the code for these, but it would be super-helpful if > > >> > > > someone could give me the high-level idea. > > > >> > > -- > > >> > > "We do not believe in ourselves until someone reveals that deep > > >> > > inside us > > >> > is > > >> > > valuable, worth listening to, worthy of our trust, sacred to our > > >> > > touch." > > >> > - > > >> > > E. E. Cummings > > > >> -- > > >> "We do not believe in ourselves until someone reveals that deep inside > > >> us is > > >> valuable, worth listening to, worthy of our trust, sacred to our touch." > > >> - > > >> E. E. Cummings --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "CommunityEngine" group. To post to this group, send email to [email protected] To unsubscribe from this group, send email to [email protected] For more options, visit this group at http://groups.google.com/group/communityengine?hl=en -~----------~----~----~----~------~----~------~--~---
