I wrote a authentication script and I’m calling it like this in every
class:
class Blah < ApplicationController
before_filter :auth
def auth
req_perm = Permission.find_by_name(“Permission Blah”)
access = AccessController.new()
if access.is_logged_in(session.session_id)
if
!access.get_current_user(session.session_id).role.permissions.include?
req_perm
redirect_to no_permission_url
end
else
redirect_to login_url
end
end
It works for the view pages but if an update or create is made then it
always redirects to the login_url. Acting like the user is not logged
in. But that’s wrong.
Did I miss something about the before_filer ? Does it work different on
update/create ?
But why is it acting different ? It always redirects to the login_url
after update/create.
I guess at some point it can’t get the session.session_id. Might that be
the problem ?
In my scaffolded update/create methods it redirects to the show page
after update. The update/create work btw. The data get saved. But
afterwards you see the login instead of the show page.
But why is it acting different ? It always redirects to the login_url
after update/create.
I guess at some point it can’t get the session.session_id. Might that be
the problem ?
In my scaffolded update/create methods it redirects to the show page
after update. The update/create work btw. The data get saved. But
afterwards you see the login instead of the show page.
Ok, I can see the problem now. The session.session_id is different
directly after the update/create when it redirects to the show page.
Question is: why ?
I guess I’m using the wrong session_id. I thought “session.session_id”
is something like the server generates and that’s always the same ?
When you store the session in the server the cookie stores a
session_id that is used as a key to retrieve the data on each request.
With cookie-based sessions session_id is not meaningful.
From your code looks like you are storing information in the server
based on the session_id. If I am correct that’s a bad practice. You’d
just store the information in the session itself, that’s its purpose:
session[:user_id] = user.id
and off the top of my head so that you see the idea:
before_filter :authenticate
def authenticate
current_user = nil
if session[:user_id]
current_user = User.find(session[:user_id]) rescue nil
end
redirect_to login_path unless current_user
end
It goes without saying that implementing authentication yourself is
hard to justify normally, it is normally better to pick some plugin.
Ok, so if I store something in the session like you described it
then a
hacker wouldn’t be able to change it by simply editing a cookie ?
I mean the cookie wouldn’t include plain information like:
“user_id = 123”
That’s the purpose of the right hand side of the cookie value, then
one you saw changed. That’s a digest of the data of the left hand side
computed by Rails. If the user tries to edit the data (which goes in
clear only encoded in Base64) Rails raises
CGI::Session::CookieStore::TamperedWithCookie and the request flow is
interrumped right away.
I don’t really want to use a plugin. I would actually like to
understand
as much as possible of what my application does
That’s good for learning, and normally bad for getting work done. When
you get confident with how things works you delegate as much as
possible. It is often the case that the author knows the problem to
solve better than you (“you” being generic) and has a good design and
good handling of corner cases or gotchas.
I changed the Session Store to ActiveRecord and if a user logs in
successfully then I store his or her UserID in session[:user_id]. To
check if he is logged in I just do if session[:user_id] as you said.
No it’s not, as long as you only store the user_id and not the user
object itself. There is also a plugin out there that can make the
cookiebased session more secure by encrypting the data instead just
base64’ing it.
Hi Peter,
well with my current implementation it all depends on that user_id in
the session. If you manipulate this is then you are another user. For my
understanding: what would a hacker have to do to change the user_id of
the session ? He would need to access my database - right ? Because the
session’s are stored there now …
That would be pretty save … I mean if someone has access to your
database then you have lost anyways haha …
(create the session table with ‘rake db:sessions:create’)
I mean if I stored login information then they are highly
confidential I
guess.
No it’s not, as long as you only store the user_id and not the user
object itself. There is also a plugin out there that can make the
cookiebased session more secure by encrypting the data instead just
base64’ing it.
