LiftRules.noCometSessionCmd, LiftRules.noCometSessionPage, and LiftRules.redirectAjaxOnSessionLoss

90 views
Skip to first unread message

Antonio Salazar Cardozo

unread,
Jun 19, 2012, 11:38:59 PM6/19/12
to lif...@googlegroups.com
Currently, session loss can trigger one of two scenarios for comets and ajax.

At its base, if the current page makes an ajax request that isn't associated with a Lift session, LiftRules.redirectAjaxOnSessionLoss is checked. If it is true, the user is redirected to a hardcoded alternative of either the request referrer (if set) or / (otherwise). If redirectAjaxOnSessionLoss is false, a session lookup is made, a new session created, and the ajax request is handled (resulting in an empty JS response since the request parameters isn't associated with anything).

If the current page makes a comet requests that isn't associated with a Lift session, LiftRules.redirectAjaxOnSessionLoss is also checked. If true, the same as the above happens. If false, the session is looked up. If no comet actors are associated with the session (as is the case if the session was lost), then a redirect to LiftRules.noCometSessionPage (defaulting to /) is issued along with a clearing of lift_toWatch (which, if left set, could trigger a cascading reload in browsers like Firefox).

My suggestion is to unify the handling for these two situations into two or three settings. In particular:
 - LiftRules.redirectAsyncOnSessionLoss, a renaming of redirectAjaxOnSessionLoss (the latter would be deprecated and be a pass-through setting to redirectAjaxOn*). I believe this is better named, since it more clearly refers to both ajax and comet requests. Moreover, this will invoke either the comet or the ajax failure below depending on what type of request we receive.
 - liftAjax.sessionLost and liftComet.sessionLost in liftAjax.js and cometAjax.js, respectively. We invoke these instead of the hardcoded reactions that are currently in place. Both of them default to location.reload(). The server response in the comet session loss scenario will include lift_toWatch = {} to avoid the cascading reload from above.
 - Possibly LiftRules.noAjaxSessionCmd and LiftRules.noCometSessionCmd to set a default for liftAjax.sessionLost and liftComet.sessionLost. My preference would be to leave this to a JS-based override, but either way works.

In the above scenario, setting LiftRules.noCometSessionPage would turn into a call to LiftRules.noCometSessionCmd = JsCmds.RedirectTo(<passed value >), and noCometSessionPage itself would be deprecated.

Any thoughts on this approach to making session loss reactions more flexible?
Thanks,
Antonio

Andreas Joseph Krogh

unread,
Jun 20, 2012, 3:26:39 AM6/20/12
to lif...@googlegroups.com
+1 on making session loss reactions more flexible. For my own needs I'd
like to just keep staying on the same page. I often use Spring Security
with "remember me" so re-creating a session -> auto-login now redirects
the user to / which doesn't seem right and I get lots of complaints
about it.

--
Andreas Joseph Krogh<and...@officenet.no> - mob: +47 909 56 963
Senior Software Developer / CEO - OfficeNet AS - http://www.officenet.no
Public key: http://home.officenet.no/~andreak/public_key.asc

Antonio Salazar Cardozo

unread,
Jun 25, 2012, 7:41:27 PM6/25/12
to lif...@googlegroups.com
Issue opened and related code added at https://github.com/lift/framework/pull/1285 .
Reply all
Reply to author
Forward
0 new messages