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 -~----------~----~----~----~------~----~------~--~---
