Setting session to nil when window is closed

I have this app at work that has Administrators and Users as two types
of users. I know who is a of what type by setting session variables:
session[:admin] and session[:user] holding the id’s. The administrators
can go to any of the user pages as needed. When that happens the two
session variables - :admin and :user - get set. The issue is that
sometimes the admins dont “logout” of those user pages and the :user
session remain set - they simply close the form. Is there a way to set
those sessions to nil whenever that window is closed if they dont
logout? Thanks,

-S

On 29 Oct 2008, at 20:22, Shandy N. wrote:

logout? Thanks,

Not in a fool proof way. You could have a window’s onClose fire off an
ajax request, but obviously that won’t work if they have javascript
turned off, won’t work if they just turn off their computer or if
their broadband dies, might not work if they quit their browser etc…

Fred

Frederick C. wrote:

On 29 Oct 2008, at 20:22, Shandy N. wrote:

logout? Thanks,

Not in a fool proof way. You could have a window’s onClose fire off an
ajax request, but obviously that won’t work if they have javascript
turned off, won’t work if they just turn off their computer or if
their broadband dies, might not work if they quit their browser etc…

Fred

That’s what I am trying to do by saying:

onunload = "delete_cookie(‘user’);

The probablem is doesn’t seem to be working. When I say session[:user] =
“blah” is the name of that cookie “user”?

If anyone is interested by delete_cookie fuunction looks like:

function delete_cookie ( cookie_name )
{
var cookie_date = new Date ( ); // current date & time
cookie_date.setTime ( cookie_date.getTime() - 1 );
document.cookie = cookie_name += “=; expires=” +
cookie_date.toGMTString();
}

On 29 Oct 2008, at 21:12, Shandy N. wrote:

their broadband dies, might not work if they quit their browser
“blah” is the name of that cookie “user”?

No. There is a single cookie (the default name is something like
app_session where app is the name of the application). The associated
value is either a serialized ruby object containing the session (if
you are using the cookiestore) or just some completely opaque id that
rails can use to grab the session from the db/memcache/filesystem.
(You could have worked some of this out just by looking in your
browser’s settings - you can list all cookies stored by your browser)

Fred

Frederick C. wrote:

The associated
value is either a serialized ruby object containing the session (if
you are using the cookiestore) or just some completely opaque id that
rails can use to grab the session from the db/memcache/filesystem.
(You could have worked some of this out just by looking in your
browser’s settings - you can list all cookies stored by your browser)

Fred

I just upgraded to Rails 2.1.0. so I am using the cookiestore but I am
storing id’s in multiple session variables: session[:user],
session[:admin], session[:company_id]. I am trying to destroy the
session[:user] via a javaScript function.

I was under the impression that when I create a session[:user] =
@user.id that the cookie looked like:

‘user=12232; expires=Thu, 29 Oct 2008 20:47:11 UTC; path=/’

and that I could erase it through javaScript by saying:

delete_cookie( ‘user’ )

but Im not sure that when I create the session variable that the name is
actually ‘user’?

On 29 Oct 2008, at 22:01, Shandy N. wrote:

and that I could erase it through javaScript by saying:

delete_cookie( ‘user’ )

but Im not sure that when I create the session variable that the
name is
actually ‘user’?

You’re wrong. There is only one cookie. it contains a serialised ruby
object (a hash to be quite precise)

Fred

Frederick C. wrote:

You’re wrong. There is only one cookie. it contains a serialised ruby
object (a hash to be quite precise)

Fred

I think I figured it out. I did a remote_function in my layout

<% func = remote_function( :url => { :action => ‘set_session_nil’} )
-%>

"> .......

and then in the controller I just set session[:user] = nil.

Sorry if I wasn’t understand correctly Fred, but thanks for your help. I
learned a lot about sessions that I didn’t know and hopefully will be
better prepared the next time I have to do something new and unusual
with them.