How to handle session timeout

[Dave]

95% of our RPC logic is stateless. The other 5% has inline security
checks against ACLs and roles to validate that a user can do a
particular action on particular data in our application. For example
if our GWT app was an online banking app we would want a customer to
only work on their particular account.

We are using HTTP form-based login currently to authenticate users. We
our hosting our GWT app on BEA 8.1

In our server side code the GWT RPC servlet delegates the call to an
EJB. Inside the EJB call we use getCallerPrincipal() to look up the
current user's user ID. We then use the user id in our security logic
lookup code. We're using Hibernate on the server side to access the
DB.

If a session has timed out, our security logic gets a userid of
'anonymous' causing our code to fail.

1) How can we know that a session has timed out other than checking
for a user ID of anonymous?
2) It seems that our RPC calls are not maintaining a session. How can
we maintain a consistent session if the user is actively making RPC
calls?

Thanks
Dave

[Sandy McArthur]

On 4/19/07, Dave <bo...@widomaker.com> wrote:
> 1) How can we know that a session has timed out other than checking
> for a user ID of anonymous?

Two ways I can think of:

1. In your RemoteServiceServlet check to see if the session valid and
throw a NotLoggedInException from your service methods. The client
code is then responsible for getting the user logged back in and
establishing that session again.

2. Include all credentials (user/pass) with each RPC request. This
probably won't work with container managed security but it means you
don't *need* any server side state to track authentication info. This
makes disconnected operations easier. (eg: a laptop with your app open
that is put to sleep at work and then woken up 3 hours later at home.)

I'm currently giving method #2 a go where I use a little session state
for caching and performance reasons but the sessions are set to expire
after 5 minutes because they aren't really needed. Just be sure that
every client request is made over HTTPS.

> 2) It seems that our RPC calls are not maintaining a session. How can
> we maintain a consistent session if the user is actively making RPC
> calls?

Session management should be real easy.

The only non-obvious trouble spot I've seen is when you make two RPC
calls at the same time that both establish a session can cause a race
to see which request's session survives.

What may be happening for you is that your 95% of RPC requests that
don't need a session aren't causing the container to keep the session
alive. I'd suspect a call to HttpServletRequest.getSession(), even if
the session is unused, would cause the session and cookie to be kept
current. Worst case, stuff a dummy value into the session on each
request such as a new Date indicating when the last request was made
to force the container to detect a change in the session data.

HTH

--
Sandy McArthur

"He who dares not offend cannot be honest."
- Thomas Paine

[Dave]

We really want this to work well with container managed security. GWT
uses
J2EE as part of it's stack so I'm hoping that there is a way to make a
GWT app
behave properly as part of an container-managed security solution.

We're moving to an SSO solution soon and that may help as well since
the
authentication will be done external to our J2EE server.

Dave

On Apr 19, 10:47 am, "Sandy McArthur" <sandy...@gmail.com> wrote:

[Sandy McArthur]

GWT's RPC uses Java Servlets, Java Servlets are a part of J2EE, but
saying GWT's RPC uses J2EE is a bit misleading because it implies more
than is really the case.

But yea, Container Managed Security is nice and it would be nice if
you could help GWT's RPC fail more gracefully if a RPC call failed
because the container wouldn't allow the servlet to be invoked but I'm
not sure how you'd do that.

On 4/19/07, Dave <bo...@widomaker.com> wrote:

[rb]

We are using ideas from Jason Essington

See thread:
http://groups.google.com/group/Google-Web-Toolkit/browse_thread/thread/5d05a23a814200a6

Create your own class the implements AsyncCallback that looks for an
authentication exception thrown by a RequestFilter. This will then
call a dialog box to allow the user to login again. Once they have a
valid login, the failed RPC calls get sent again as commands.

I am finishing up our implementation now and would be glad to send you
the code if you are interested.

[Edward]

I am interested, would you send me?

On Apr 20, 1:03 am, rb <rex.beir...@gmail.com> wrote:
> We are using ideas from Jason Essington
>

> See thread:http://groups.google.com/group/Google-Web-Toolkit/browse_thread/threa...

> > Dave- Hide quoted text -
>
> - Show quoted text -

[A.A.Va...@gmail.com]

Me too, if you please.

[rafaelt]

Can you sendo to me your code???

Thanks,

Rafael

On 19 abr, 14:03, rb <rex.beir...@gmail.com> wrote:
> We are using ideas from Jason Essington
>

> See thread:http://groups.google.com/group/Google-Web-Toolkit/browse_thread/threa...

>
> Create your own class the implements AsyncCallback that looks for an
> authentication exception thrown by a RequestFilter. This will then
> call a dialog box to allow the user to login again. Once they have a
> valid login, the failed RPC calls get sent again as commands.
>
> I am finishing up our implementation now and would be glad to send you
> the code if you are interested.
>
> On Apr 19, 10:01 am, Dave <b...@widomaker.com> wrote:
>
>
>
> > 95% of our RPC logic is stateless. The other 5% has inline security
> > checks against ACLs and roles to validate that a user can do a
> > particular action on particular data in our application. For example
> > if our GWT app was an online banking app we would want a customer to
> > only work on their particular account.
>
> > We are using HTTP form-based login currently to authenticate users. We
> > our hosting our GWT app on BEA 8.1
>
> > In our server side code the GWT RPC servlet delegates the call to an
> > EJB. Inside the EJB call we use getCallerPrincipal() to look up the
> > current user's user ID. We then use the user id in our security logic
> > lookup code. We're using Hibernate on the server side to access the
> > DB.
>

> > If asessionhas timed out, our security logic gets a userid of

> > 'anonymous' causing our code to fail.
>

> > 1) How can we know that asessionhas timed out other than checking

> > for a user ID of anonymous?

> > 2) It seems that our RPC calls are not maintaining asession. How can
> > we maintain a consistentsessionif the user is actively making RPC
> > calls?
>
> > Thanks
> > Dave- Ocultar texto entre aspas -
>
> - Mostrar texto entre aspas -