I have set up AuthLogic almost exactly as per the AuthLogic example app at http://github.com/binarylogic/authlogic_example.
After someone logs in as User, they can click on links that send them away into the system and away from the users controller. This is an incredibly noob question, but how can I access that User's ID and other attributes from anywhere else, such as an unrelated view or unrelated controller?
An example of what I'd like to do:
#matchings controller
#matching = Matching.find_by_user_id(user.id)
You can use current_user or #current_user. The function that returns current_user is defined in application controller.
...
private
def current_user_session
return #current_user_session if defined?(#current_user_session)
#current_user_session = UserSession.find
end
def current_user
return #current_user if defined?(#current_user)
#current_user = current_user_session && current_user_session.record
end
...
So, you can use:
#matching = Matching.find_by_user_id(current_user.id) or
#matching = Matching.find_by_user(current_user)
Related
I have authlogic running just fine in my app, but I am rolling my own roles (i am newer to rails and wanted to learn...)
So I have a User model, a Role Model, and a User Sessions model. User acts_as_authenticated.
In my application_controller
protect_from_forgery
helper_method :current_user, :is_admin, :is_group_coach, :is_group_leader
private
def current_user_session
return #current_user_session if defined?(#current_user_session)
#current_user_session = UserSession.find
end
def current_user
return #current_user if defined?(#current_user)
#current_user = current_user_session && current_user_session.record
end
def is_admin
current_user.role_id == 3
end
def is_group_coach
current_user.role_id == 2
end
def is_group_leader
current_user.role_id == 1
end
Then I am doing a simple if is_admin in a view...
but its returning undefined method `role_id' for nil:NilClass
I think its doing this because current_user is actually running off the UserSession model not User... How can I modify this to run as expected?
Your current_user_session method is probably incomplete on this code snippet as you can't call find without parameters, so I'm guessing there is a guard in there against a nil value or somewhere like that if the user is not logged in. And if there is the possibility for the user to not be logged in, your methods should account for that and only call methods on current_user if one is available.
Your methods should be like this:
def is_admin
current_user && current_user.role_id == 3
end
def is_group_coach
current_user && current_user.role_id == 2
end
def is_group_leader
current_user && current_user.role_id == 1
end
This will prevent the test from breaking is there is no user currently logged in on the website.
So I'm following the Rails Tutorial, and I've gotten to the portion where we want to sign a user in with a sign_in SessionHelper.
Question 1:
module SessionsHelper
def sign_in(user)
cookies.permanent.signed[:remember_token] = [user.id, user.salt]
current_user = user
end
def current_user=(user) #set current_user
#current_user = user
end
def current_user #get current_user
#current_user
end
What I'm having difficulty with is the part that reads:
The problem is that it utterly fails to solve our problem: with the code the user's signin status would be forgotten: as soon as the user went to another page.
I don't understand how this is true? I read on and understand the added code makes sure #current_user is never nil. But I'm not seeing how current_user would revert to nil if we just established it in 5th line.
Question 2:
The updated code reads as such:
module SessionsHelper
def sign_in(user) #in helper because used in view & controller
cookies.permanent.signed[:remember_token] = [user.id, user.salt]
current_user = user
end
def current_user=(user) #set current_user
#current_user = user
end
def current_user #get current_user
#current_user ||= user_from_remember_token #<-- short-circuit evaluation
end
private
def user_from_remember_token
User.authenticate_with_salt(*remember_token) #*=use [] instead of 2 vars
end
def remember_token
cookies.signed[:remember_token] || [nil, nil]
end
end
In the remember_token helper, why does it use cookies.signed[] instead of cookies.permanent.signed[] & why doesn't it use ||= operator we just learned about?
Question 3:
Why do we need to authenticate_with_salt? If I authenticate & sign_in can see the id & salt attributes from the user who was passed to it, why do we need to double_check it? What kind of situation would trigger a mixup?
Remember that instance variables like #current_user are only set for the duration of the request. The controller and view handler instances are created specifically for rendering once and once only.
It is often easy to presume that because you've set a variable somewhere that it will continue to work at some point in the future, but this is not the case. To preserve something between requests you need to store it somewhere, and the most convenient place is the session facility.
What's missing in this example is something along the lines of:
def current_user
#current_user ||= User.find_by_remember_token(cookies[:remember_token])
end
Generally it's a good idea to use the write accessor to map out the functionality of the sign_in method you've given as an example:
def current_user=(user)
cookies.permanent.signed[:remember_token] = [user.id, user.salt]
#current_user = user
end
It's odd that there is a specific "sign in" method when the act of assigning the current user should be the same thing by implication.
From a matter of style, though, it might be more meaningful to call these methods session_user as opposed to current_user for those situations when one user is viewing another. "Current" can mean "user I am currently viewing" or "user I am currently logged in as" depending on your perspective, which causes confusion. "Session" is more specific.
Update:
In response to your addendum, the reason for using cookies to read and cookies.permanent to assign is much the same as using flash.now to assign, and flash to read. The .permanent and .now parts are intended to be used when exercising the assignment operator.
I use authlogic to authenticate users. In my controllers I use current_user, defined (as documented) as follows:
def current_user_session
return #current_user_session if defined?(#current_user_session)
#current_user_session = UserSession.find
end
def current_user
return #current_user if defined?(#current_user)
#current_user = current_user_session && current_user_session.record
end
I also use declarative_authorization to manage the current user's permissions. All works fine in the normal runtime scenario, but when I create functional tests that use request statements like " get_with", current_user in the controller is nil. I looked through the declarative_authorization test helper code and found that in this scenario, the declarative_authorization gem actually stores the current user in Authorization.current_user (which in turn comes from Thread.current["current_user"]). So there seems to be quite a mixup of how a current user is handled in different scenario's.
My question: what is the appropriate way of finding the current_user in both the normal runtime and the test scenario?
You can define a before_filter like this in application_controller.
before_filter { |c| Authorization.current_user = c.current_user }
Angelus, you were right. I shouldn't be using get_with, post_with, etc. These just set the Authorization.current_user, session[:user] and session[:user_id] and these seem to be obsolete with authlogic. And for some reason, these even set UserSession to nil, which was causing the problem. So UserSession.create(users(:admin)), followed by a regular get, post, etc. is the way to go.
In my User model I have:
acts_as_authentic do |c|
c.perishable_token_valid_for = 30.minutes
end
In my Application Controller I have the standard boilerplate code:
def current_user_session
return #current_user_session if defined?(#current_user_session)
#current_user_session = UserSession.find
end
def current_user
return #current_user if defined?(#current_user)
#current_user = current_user_session && current_user_session.record
end
Now in my view I need to see if a user is logged in:
<% if current_user %>
Sign Out
<% else %>
Sign In
<% end %>
On every single request, current_user is being called, and that causes a SELECT call to be made to the database to find the user, then an UPDATE call that updates the last_request_at and perishable_token even though I set perishable_token_valid_for = 30.minutes.
Does anyone have a better way to see if a user is logged in without causing a SELECT and UPDATE on every single page of my app.
Does anyone know why the perishable token keeps updating even if I set it to be valid for 30 minutes???
perishable_token_valid_for isn't doing what you think it is. It's intended to work in tandem with find_using_perishable_token which is intended for things like account validation and resetting a forgotten password. The default timeout is 10 minutes.
The token is supposed to update on every request like it's doing. You can just remove the column if you don't want it. It's completely optional with authlogic.
If you really do want to keep the perishable token but update it completely by hand, you can do disable_perishable_token_maintenance = true
please help me to understand something. In Authlogic example in UsersController it's always used #current_user, so for instance:
def show
#user = #current_user
end
(taken from http://github.com/binarylogic/authlogic_example/blob/master/app/controllers/users_controller.rb)
Why is that? In my controllers I use just current_user instead of #current_user.
And besides - Authlogic works perfectly for me, but I don't see magic columns being populated (like last_login_at or last_login_ip). Should I initialize them somehow specifically besides just adding into migration?
UPD
After some investigation, I found that if there're only fields last_login_at and last_login_ip from "Magic fields", then they will not be populated. If I add a full set of magic fields, it is working perfectly.
UPD2
My concern regarding current_user is only about UsersController: why does it have #current_user and not current_user?
current_user is typically a method defined in app/controllers/application_controller.rb which sets the #current_user instance variable if it is not already defined -- here is an example:
def current_user_session
return #current_user_session if defined?(#current_user_session)
#current_user_session = UserSession.find
end
def current_user
return #current_user if defined?(#current_user)
#current_user = current_user_session && current_user_session.record
end
Re the "magic columns", these should be set by Authlogic automatically. For example, if your user sessions controller logs in a user:
#user_session = UserSession.new(params[:user_session])
#user_session.save
Authlogic should write the last_login_at and last_login_ip attributes for you. More info in the Authlogic docs under Module: Authlogic::Session::MagicColumns
As for last_login_at and last_login_ip, do you have current_login_at and current_login_ip fields in your table ? last_login_at and last_login_ip are set with the values of current_login_at and current_login_ip before they are reset.
I think the code from the example isn't a really good example.
You shouldn't use #current_user to set the #user variable. Because it won't work if the ApplicationController#current_user method isn't called before show action of the UserController. Basically they are both exactly the same after current_user is called once.
the User Controller should look like this
class UserController < ApplicationController
def show
#user = current_user
end
end
As for the Magic Columns I have no Idea why they don't work for you.