Rails - Jun 2006 - invalidating a session on multiple login

How do I do the following: if a user is logged in, then opens another
browser tab and logs in again (either as himself or as someone else),
I want to invalidate the session in the first tab and throw up a
"logged in from another browser window" screen. RIght now,
user1''s
session silently becomes a duplicate user2 session instead (from what
I understand, sessions are bound to browser-specific cookies, so that
is understandable, but definitely not desirable).

martin

On Thursday, June 22, 2006, at 6:06 PM, Martin DeMello
wrote:
>How do I do the following: if a user is logged in, then opens another
>browser tab and logs in again (either as himself or as someone else),
>I want to invalidate the session in the first tab and throw up a
>"logged in from another browser window" screen. RIght now,
user1''s
>session silently becomes a duplicate user2 session instead (from what
>I understand, sessions are bound to browser-specific cookies, so that
>is understandable, but definitely not desirable).
>
>martin
>_______________________________________________
>Rails mailing list
>Rails@lists.rubyonrails.org
>http://lists.rubyonrails.org/mailman/listinfo/rails
If they are browsing from the same browser, they will be using the same  
session.  If they run a different browser, then it will create a new session.

_Kevin

-- 
Posted with http://DevLists.com.  Sign up and save your mailbox.

Hello Martin,

2006/6/22, Martin DeMello
<martindemello@gmail.com>:
> I want to invalidate the session in the first tab and throw up a
Create a new session by resetting the session prior to doing your
authentication.  session.reset should do it.  If you had stored
anything in the session, that will obviously be cleared.  Copy off
anything you might want to keep.

Bye !
-- 
Fran?ois Beausoleil
http://blog.teksol.info/

On 6/22/06, Francois Beausoleil <francois.beausoleil@gmail.com>
wrote:
> Hello Martin,
>
> 2006/6/22, Martin DeMello <martindemello@gmail.com>:
> > I want to invalidate the session in the first tab and throw up a
>
> Create a new session by resetting the session prior to doing your
> authentication.  session.reset should do it.  If you had stored
> anything in the session, that will obviously be cleared.  Copy off
> anything you might want to keep.
Doh - don''t know why I didn''t think of that! Thanks :)

martin

Martin DeMello wrote:
> How do I do the following: if a user is logged in, then opens another
> browser tab and logs in again (either as himself or as someone else),
> I want to invalidate the session in the first tab and throw up a
> "logged in from another browser window" screen. RIght now,
user1''s
> session silently becomes a duplicate user2 session instead (from what
> I understand, sessions are bound to browser-specific cookies, so that
> is understandable, but definitely not desirable).
Wouldn''t it solve your problem to show a "log out" button
instead of a
login option when a user is already logged in?

--Al Evans

-- 
Posted via http://www.ruby-forum.com/.

On 6/23/06, Al Evans <anejr@alevans.com> wrote:
> Martin DeMello wrote:
> > How do I do the following: if a user is logged in, then opens another
> > browser tab and logs in again (either as himself or as someone else),
> > I want to invalidate the session in the first tab and throw up a
> > "logged in from another browser window" screen. RIght now,
user1''s
> > session silently becomes a duplicate user2 session instead (from what
> > I understand, sessions are bound to browser-specific cookies, so that
> > is understandable, but definitely not desirable).
>
> Wouldn''t it solve your problem to show a "log out"
button instead of a
> login option when a user is already logged in?
ooh - interesting idea. that does sound like the cleanest solution. thanks!

martin

Okay, this is even harder than I thought. Consider the following use
case: user1 logs in. He opens a new tab and tries to log in again.
Either by making him click logout or transparently, I reset the
session, and log him in as user2. The previous tab will still be
changed to user2, since the session reset can''t affect the client side
- I''m beginning to think the only thing to do is store the logged in
user in javascript and do a timed ajax call to see if it matches the
session user and invalidate the page on the client side if not. Anyone
have a better idea?

martin

Hi guys,

when calling update_attribute on my model I wonder that the 
validate-method is not called.

class Product < ActiveRecord::Base
  validates_presence_of :name
  def validate
    # do some more or less sophisticated checks
  end
end

product = Product.create(:name => "Fridge")
# validate happens

product.update_attribute(:name => "Mega-Cool-Master 2000ZX")
# _no_ validate happens here :-(

Hi guys,

when calling update_attribute on my model I wonder that the 
validate-method is not called.

class Product < ActiveRecord::Base
 validates_presence_of :name
 def validate
   # do some more or less sophisticated checks
 end
end

product = Product.create(:name => "Fridge")
# validate happens

product.update_attribute(:name => "Mega-Cool-Master 2000ZX")
# _no_ validate happens here :-(


Thanks for your time and help in advance! :-)

Best regards
Peter

I would reconsider the gui design of your application as this kind of
login / logout - scenario is weird...

if you have different roles in your applications you should use a user 
<=> roles mapping
and extend the session credentials.

Martin DeMello schrieb:
> Okay, this is even harder than I thought. Consider the following use
> case: user1 logs in. He opens a new tab and tries to log in again.
> Either by making him click logout or transparently, I reset the
> session, and log him in as user2. The previous tab will still be
> changed to user2, since the session reset can''t affect the client
side
> - I''m beginning to think the only thing to do is store the logged
in
> user in javascript and do a timed ajax call to see if it matches the
> session user and invalidate the page on the client side if not. Anyone
> have a better idea?
>
> martin
> _______________________________________________
> Rails mailing list
> Rails@lists.rubyonrails.org
> http://lists.rubyonrails.org/mailman/listinfo/rails

I don''t see why it''s weird GUI-wise - it''s a standard
application with
all pages gated by a single user login. There aren''t any roles or
anything involved; it''s just that the data displayed on the page
depends on who the logged in user is. Logging in authenticates the
user against the db, returns a User, and fills it into session[:user].
Per-controller authentication simply checks that session[:user] is not
nil - that may be the design flaw, but if it is, I can''t see what else
I could do with a pure back-end operation.

To give a concrete example, let''s say that user Foo has surfed over to
http://myhost/user/preferences and is editing his preferences page.
Now he opens another browser tab and logs in as user Bar. I obligingly
 reset the session, logging Foo out. Now let''s say he goes back to the
first tab and hits save. It''ll post a preferences form to
/user/saveprefs, but now session[:user] is Bar, and Bar''s preferences
will get updated with the form data Foo was filling in. Short of
passing in a user id as a parameter to every controller action, or (as
I mentioned in the last post) having a periodic ajax call to check
that the user who opened the current page matches the session user, I
don''t see what to do design-wise to defend against this.

martin

On 6/23/06, Peter Ertl <peter.ertl@gmx.net> wrote:
> I would reconsider the gui design of your application as this kind of
> login / logout - scenario is weird...
>
> if you have different roles in your applications you should use a user
> <=> roles mapping
> and extend the session credentials.
>
> Martin DeMello schrieb:
> > Okay, this is even harder than I thought. Consider the following use
> > case: user1 logs in. He opens a new tab and tries to log in again.
> > Either by making him click logout or transparently, I reset the
> > session, and log him in as user2. The previous tab will still be
> > changed to user2, since the session reset can''t affect the
client side
> > - I''m beginning to think the only thing to do is store the
logged in
> > user in javascript and do a timed ajax call to see if it matches the
> > session user and invalidate the page on the client side if not. Anyone
> > have a better idea?
> >
> > martin
> > _______________________________________________
> > Rails mailing list
> > Rails@lists.rubyonrails.org
> > http://lists.rubyonrails.org/mailman/listinfo/rails
>
> _______________________________________________
> Rails mailing list
> Rails@lists.rubyonrails.org
> http://lists.rubyonrails.org/mailman/listinfo/rails
>

> o give a concrete example, let''s say that user Foo has surfed over
to
 > http://myhost/user/preferences and is editing his preferences page.
 > Now he opens another browser tab and logs in as user Bar.

Why should he log in as a different user? do you want foo to edit bar''s
preferences?
then foo should have administrative privileges for bar but not switch 
identity...


Martin DeMello schrieb:
> I don''t see why it''s weird GUI-wise - it''s a
standard application with
> all pages gated by a single user login. There aren''t any roles or
> anything involved; it''s just that the data displayed on the page
> depends on who the logged in user is. Logging in authenticates the
> user against the db, returns a User, and fills it into session[:user].
> Per-controller authentication simply checks that session[:user] is not
> nil - that may be the design flaw, but if it is, I can''t see what
else
> I could do with a pure back-end operation.
>
> To give a concrete example, let''s say that user Foo has surfed
over to
> http://myhost/user/preferences and is editing his preferences page.
> Now he opens another browser tab and logs in as user Bar. I obligingly
> reset the session, logging Foo out. Now let''s say he goes back to
the
> first tab and hits save. It''ll post a preferences form to
> /user/saveprefs, but now session[:user] is Bar, and Bar''s
preferences
> will get updated with the form data Foo was filling in. Short of
> passing in a user id as a parameter to every controller action, or (as
> I mentioned in the last post) having a periodic ajax call to check
> that the user who opened the current page matches the session user, I
> don''t see what to do design-wise to defend against this.
>
> martin
>
> On 6/23/06, Peter Ertl <peter.ertl@gmx.net> wrote:
>> I would reconsider the gui design of your application as this kind of
>> login / logout - scenario is weird...
>>
>> if you have different roles in your applications you should use a user
>> <=> roles mapping
>> and extend the session credentials.
>>
>> Martin DeMello schrieb:
>> > Okay, this is even harder than I thought. Consider the following
use
>> > case: user1 logs in. He opens a new tab and tries to log in again.
>> > Either by making him click logout or transparently, I reset the
>> > session, and log him in as user2. The previous tab will still be
>> > changed to user2, since the session reset can''t affect
the client side
>> > - I''m beginning to think the only thing to do is store
the logged in
>> > user in javascript and do a timed ajax call to see if it matches
the
>> > session user and invalidate the page on the client side if not.
Anyone
>> > have a better idea?
>> >
>> > martin
>> > _______________________________________________
>> > Rails mailing list
>> > Rails@lists.rubyonrails.org
>> > http://lists.rubyonrails.org/mailman/listinfo/rails
>>
>> _______________________________________________
>> Rails mailing list
>> Rails@lists.rubyonrails.org
>> http://lists.rubyonrails.org/mailman/listinfo/rails
>>
> _______________________________________________
> Rails mailing list
> Rails@lists.rubyonrails.org
> http://lists.rubyonrails.org/mailman/listinfo/rails

On 6/23/06, Peter Ertl <peter.ertl@gmx.net> wrote:
>  > o give a concrete example, let''s say that user Foo has
surfed over to
>  > http://myhost/user/preferences and is editing his preferences page.
>  > Now he opens another browser tab and logs in as user Bar.
>
> Why should he log in as a different user? do you want foo to edit
bar''s
> preferences?
> then foo should have administrative privileges for bar but not switch
> identity...
He might have two accounts on the system. Or he might have walked away
from the machine and his roommate might have logged in. Actually, I
picked the wrong example to demonstrate the problem - say, instead,
that a user has_many documents, which are listed on the screen, with
checkboxes next to them. Bar can now check a bunch of boxes and hit
delete; the app, trusting that, if Foo had the privileges to view the
documents, he has the privileges to delete them, goes ahead and does
so. To defend against that I''d need to put in a check for every action
on a document that document.user matches session.user (actually, now
that I mention it, I should probably do that anyway, in a spirit of
healthy paranoia, but what else have I missed?)

Gmail does the right thing here - if I log in with a different user in
the same browser, my earlier session automatically goes invalid on the
client side.

martin