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