Remote div's and session expirations

[Owen Berry <ow...@gmail.com>]

Just wondering what others do with regard to refreshing of remote
div's and session expirations (requiring the user to re-authenticate).
As an example, a page contains a tabbed panel, which contains remote
div's that refresh on show. If a user chooses one of these tabs, but
in the mean time their session has expired, the login screen now shows
up in the panel.

My current solution is for the login page to check, via Javascript,
that top.location.href is the login page. If it isn't, refresh the
main window, which will cause the redirect to the login screen. It
works, but it's a bit kludgey, and the user sees the activity.

Anybody have a good way of dealing with this?

Thanks,
Owen

---------------------------------------------------------------------
To unsubscribe, e-mail: user-unsubscribe@struts.apache.org
For additional commands, e-mail: user-help@struts.apache.org

Re: Remote div's and session expirations

[Jukka Välimaa <va...@gmail.com>]

All the names of our actions that call up ajax content to separate sections
of page follow a certain naming convention. We have a filter that recognizes
this pattern, and if session has expired, serves a short message that has a
link to login page instead of the login page itself.

On Wed, May 21, 2008 at 8:40 PM, Owen Berry <ow...@gmail.com> wrote:

> Just wondering what others do with regard to refreshing of remote
> div's and session expirations (requiring the user to re-authenticate).
> As an example, a page contains a tabbed panel, which contains remote
> div's that refresh on show. If a user chooses one of these tabs, but
> in the mean time their session has expired, the login screen now shows
> up in the panel.
>
> My current solution is for the login page to check, via Javascript,
> that top.location.href is the login page. If it isn't, refresh the
> main window, which will cause the redirect to the login screen. It
> works, but it's a bit kludgey, and the user sees the activity.
>
> Anybody have a good way of dealing with this?
>
> Thanks,
> Owen
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: user-unsubscribe@struts.apache.org
> For additional commands, e-mail: user-help@struts.apache.org
>
>