find_user, require_current_user, login_required

9 views
Skip to first unread message

GregL

unread,
Nov 2, 2009, 9:53:47 PM11/2/09
to CommunityEngine
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.

Jim Ruther Nill

unread,
Nov 2, 2009, 10:19:28 PM11/2/09
to communi...@googlegroups.com
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
--
"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

GregL

unread,
Nov 3, 2009, 8:14:57 PM11/3/09
to CommunityEngine
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.

Jim Ruther Nill

unread,
Nov 3, 2009, 8:30:06 PM11/3/09
to communi...@googlegroups.com
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.

GregL

unread,
Nov 3, 2009, 9:28:57 PM11/3/09
to CommunityEngine
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.

Bruno Bornsztein

unread,
Nov 3, 2009, 9:32:16 PM11/3/09
to communi...@googlegroups.com
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

GregL

unread,
Nov 3, 2009, 10:10:27 PM11/3/09
to CommunityEngine
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 <bruno.bornszt...@gmail.com>
wrote:

GregL

unread,
Nov 4, 2009, 9:09:18 AM11/4/09
to CommunityEngine
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!

Bruno Bornsztein

unread,
Nov 4, 2009, 9:14:13 AM11/4/09
to communi...@googlegroups.com
Cool. I wish Desert/Rails had a better ability to override filters
from plugins; maybe it's something we'll have to implement as part of
CE. There's a similar problem with validations on models; they aren't
easy to override in your application.

Thanks,
Bruno
Reply all
Reply to author
Forward
0 new messages