Expired session or disconnection should trigger reconnect / blocking code

[nathandunn]

so spring security core has an easy workaround for this . . . . shiro native also has support for this.

Hooking up a listener straight to web.xml might work as well.

[nathandunn]

https://github.com/apa64/try-shiro/blob/master/grails-app/conf/Config.groovy

[cmdcolin]

I like the idea of this SessionExpiredListener, but instead of forcing logout, I think it should try and "re-login" (like a heartbeat timer)!

The reason being is that if you force a logout, it destroys the remember me cookie.

[cmdcolin]

The main concern that I have is that when the sessions expire, the app continues to function in a half-broken state, so we need to just refresh the session or "listen" to the responses that the ajax calls are making so that we can just stop/refresh when it is in that half-broken state

[nathandunn]

@cmdcolin It shouldn't force a logout, however, I need to see how it interacts with the remember-me cookie. This is all in a branch, so we'll have to definitely review it. So the behavior we want is:

On session expire . . .

• if a remember-me cookie exists, use that to re-login .. if it fails notify, otherwise the user doesn't care . . . I think that it might do this automatically, but I am unsure (we tested this and it seems to be true)
• if no remember-me cookie, provide a popup in JBrowse asking to re-login / keep session open

I moved this to 2.0.1, because as you are surmising, it is non-trivial.

[nathandunn]

http://shiro-user.582556.n2.nabble.com/Listening-for-session-timeout-events-via-SessionManager-td5998503.html

What I'd like to do is keep track of who is logged on at any given time, so when a session starts I'll store a record (probably just in non-persistent memory since I don't care about retaining sessions between server restarts), and when the session ends or expires I want to remove that record. The record will probably just have a user alias (username) but it may have some other extra info too. (If there's a simpler way of doing this I'm open to suggestions.) It's a bit like the "who's online" feature you often see on web forums.

Will have to use "native" mode, which caused its only problems.

[nathandunn]

Next . . I think I my try the spring security. On the flip side I could do something like this:

http://stackoverflow.com/questions/3201991/auto-loyingg-off-once-the-session-expires

This actually has jQuery make a heartbeat check. This would have to go into the jbrowse section, however. That, and we could just use the stomp websocket library to do the same thing.

The problem is that we are doing this for jbrowse . . so we want to use dojo.connect to connect any mouse or click movement (within a certain time-frame?) to the websocket heartbeat function, but only when logged in (obviously). So . . .

def function = heartbeat(){
    this.client.send("/app/heartbeat", {}, JSON.stringify(this.username));
}
dojo.connect("everything","onclicked",heartbeat)
dojo.connect("everything","onkeypressed",heartbeat)

And on fail . . . we subscribe as well?

client.subscribe("/topic/hearbeat/" + this.username) ;

So .. . on spring pages . . .this is automatic so we don't have to worry about it, but if we wanted to we could use either solution (jQuery or websocket).

On GWT pages, they all use "permissionService", so they could all return a uniform error?

[nathandunn]

@cmdcolin How do I do this in dojo-land at the panel level:

dojo.connect("everything","onclicked",callHeartbeatFunction)

or conversely:

dojo.connect("alluserinterface","useraction",callHeartbeatFunction)

[monicacecilia]

I'm going to add a :+1: every time I want this to be ready. . . hehe. I think I've tried to "create" this bug again about 3 times this week. :)

[cmdcolin]

I think @nathandunn and I talked about this on a phonecall and it is fine in the case where the remember me cookie is set, which is good, but that without the remember cookie, it is still problematic

[cmdcolin]

Would definitely like this to get fixed sometime

2.0.2 sounds good but I keep running into it

[nathandunn]

The tricky part is setting up a shiro listener for timeouts:

https://github.com/vahidhedayati/grails-shiro-listener/blob/master/README.md

At some point, I'd thought of possibly switching out of Shiro and into using Spring Security (ouch) because the listeners are better integrated. We'll see.

[monicacecilia]

:+1: as promised (above).

[cmdcolin]

We have errors that happen in public jbrowse mode too, since jbrowse uses sessions, and of course we have sessions expiring here.

[nathandunn]

Can you provide more details of what is happening?

On Dec 1, 2015, at 2:25 PM, Colin Diesh notifications@github.com wrote:

We have errors that happen in public jbrowse mode too, since jbrowse uses sessions, and of course we have sessions expiring here.

— Reply to this email directly or view it on GitHub https://github.com/GMOD/Apollo/issues/493#issuecomment-161115995.

[cmdcolin]

It's pretty easy to reproduce with tomcat manager app

Simply open up a genome in the public jbrowse mode

Go to tomcat manager

Select expire session >= 0 minutes

Then go back to genome browser, try changing chromosomes, or doign a search, or opening new track, or scrolling around. All those things will fail since session is gone

Same thing happens after session expires naturally with a timeout, so if user is in jbrowse mode, leaves tab open for 30 min, goes back to it, things start failing like that

[monicacecilia]

:+1: yep - as promised. I want this. goooolly, I really wish this existed. :disappointed:

[monicacecilia]

:+1: yep... here we go again. will someone PLEASE fix this at some point of our lives? :)

[nathandunn]

From #714

It's pretty easy to reproduce with tomcat manager app

Simply open up a genome in the public jbrowse mode

Go to tomcat manager

Select expire session >= 0 minutes

Then go back to genome browser, try changing chromosomes, or doign a search, or opening new track, or scrolling around. All those things will fail since session is gone

Same thing happens after session expires naturally with a timeout, so if user is in jbrowse mode, leaves tab open for 30 min, goes back to it, things start failing like that

I had trouble reproducing it, but leaving it here as I think that the other is a duplicate.

[monicacecilia]

bah. I logged out one window and the other window doesn't know it. I keep conducting operations and none of them go through, but I also do not receive any errors.

[nathandunn]

That is not the desired behavior! I'll take a look.

[nathandunn]

Confirmed that the "logout" message is being sent to all "users" (and they all get the popup), but only the initiator is actually logged out.

[monicacecilia]

• Currently, if I have 2 windows open in the same browser and log out of one of them, I do not see a message in the other window. If instead I am in two different browsers and log out of one of the windows, the other browser gets an alert.

[nathandunn]

Yes. This is a bug. The alert should happen in both, but actually expiring the session only occurs in the first.

[nathandunn]

I've started a fix for it, but it needs more testing.

[nathandunn]

@monicacecilia This fix in #1191 will be in RC3.

[monicacecilia]

How long is it supposed to take for the warning to be triggered? Losing connectivity does trigger the warning box in approx. 30 seconds or so. Wondering if that is expected and correct. Thanks.

[nathandunn]

30 seconds is correct. The client calls home. Not as nice as a push, but I think better than what we have.

[nathandunn]

Also, a push (e.g., a session timeout) would not indicate server or internet failure, whereas this would.

[monicacecilia]

It works well.

[monicacecilia]

I can confirm that it works for

• [x] Two separate windows in same browser 💃
• [x] Two tabs in same browser 💃
• [x] Two separate windows in different browsers 💃

!!