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:
Rails mailing list
[email protected]
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
Hello Martin,
2006/6/22, Martin DeMello [email protected]:
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 !
On 6/22/06, Francois B. [email protected] wrote:
Hello Martin,
2006/6/22, Martin DeMello [email protected]:
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
On 6/23/06, Al Evans [email protected] wrote:
login option when a user is already logged in?
ooh - interesting idea. that does sound like the cleanest solution.
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
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”)
product.update_attribute(:name => “Mega-Cool-Master 2000ZX”)
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
end
end
product = Product.create(:name => “Fridge”)
product.update_attribute(:name => “Mega-Cool-Master 2000ZX”)
Thanks for your time and help in advance! 
Best regards
Peter
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
martin
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:
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 E. [email protected] 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
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:
This forum is not affiliated to the Ruby language, Ruby on Rails framework, nor any Ruby applications discussed here.
Sponsor our Newsletter | Privacy Policy | Terms of Service | Remote Ruby Jobs