On 6 avr, 11:02, Ivan M <supertra...@gmail.com> wrote:
>
> Thank you, Thomas. I perform authentication against a rather slow LDAP
> server, so I can't afford querying this server for every GWT request.
> I'm considering tickets but I still don't know how to implement it. I
> understand I can use the following as the ticket, so I don't need to
> pass an extra parameter:
>
> getThreadLocalRequest().getSession().getId()
>
> I don't want the trouble of storing tickets and their access permits
> in the DDBB. Since I read there is one instance of the server running
> for all clients, I suppose I can store them in a data structure in the
> server. How can I detect that a session has been closed or expired, to
> delete the record from the structure?.

If you use HttpSession, don't bother storing things related to the
session in another storage than the session itself; it would be
counter-productive (except if what you store is actually shared
amongst sessions).

But what I said earlier still applies:
> > With an HttpSession, you let the server do this "verification" for you
> > (and associate data with this "session"), but be careful about CSRF,
> > as securing an app against CSRF needs client-server cooperation
> > (cookies and "tokens in URLs" aren't secure *at all*

This doc is very enlightnening wrt CSRF and how HttpSession's are
vulnerable "out of the box":
http://www.adambarth.com/papers/2008/barth-jackson-mitchell-b.pdf

As a simple session-less solution, I'd just store a "last access"
timestamp and run a job periodically (a simple timer+runnable would do
it) to delete expired "objects".
But there are a number of good "cache" implementations out there doing
it for you:
http://java-source.net/open-source/cache-solutions
http://www.vipan.com/htdocs/cachehelp.html

The advantage is that it allows a same ticket to be shared amongst
"sessions" (a browser and a "download manager" for instance) in some
circumstances (that *you* control; the cases where you don't want such
sharing being protected using anti-CSRF techniques).
And all of this without using cookies or rewritten URLs (except if you
want to, by doing it explicitly in your code).
--~--~---------~--~----~------------~-------~--~----~
You received this message because you are subscribed to the Google Groups 
"Google Web Toolkit" group.
To post to this group, send email to Google-Web-Toolkit@googlegroups.com
To unsubscribe from this group, send email to 
google-web-toolkit+unsubscr...@googlegroups.com
For more options, visit this group at 
http://groups.google.com/group/Google-Web-Toolkit?hl=en
-~----------~----~----~----~------~----~------~--~---

Reply via email to