Thanks. I don't believe there is a clustering issue as the application isn't running on a clustered environment, and its only one of two applications deployed on the server's Tomcat instance. Neither have anything to do with each other.
The application is also an internal one that's used by <25 users at a time, so its unlikely there's anything malicious going on. On Aug 12, 12:32 am, Juan Pablo Gardella <[email protected]> wrote: > I tell you because we have similar issue in the past (not with gwt) and is > relate to authentication and authorization mechanism. We do the > authentication with a servlet and don't put filters. > > Both authentication and authorization at now is made by filters. All > operations is made by filters in same threads (or not is there are > clusters). > > Sounds a concurrency problem. > > PD: Check if you can have session > fixation<http://en.wikipedia.org/wiki/Session_fixation> when > you use sessionId. > > 2011/8/11 [email protected] <[email protected]> > > > > > > > > > Authentication is done once at login. The user credentials are sent to > > the server using GWT-RPC, and the server authenticates using LDAP. > > Once authenticated, the user loads the full user object into the > > hashmap keyed by session IDs. Part of this user object contains a > > hashmap of permissions allowable by this user (loaded from a > > database). When a client calls a GWT-RPC, the checked session ID is > > used to retrieve the user object on the server side, and its hashmap > > of permissions is checked to see it contains the required permissions > > for using that GWT-RPC. > > > How does my mechanism of authentication/authorisation affect the > > scenario I described? > > > On Aug 11, 9:35 pm, Juan Pablo Gardella <[email protected]> > > wrote: > > > How manage authorization and authentication? > > > > 2011/8/11 [email protected] <[email protected]> > > > > > Hi all, > > > > > I have an application that's been in use for the last 6 months or so > > > > and will be going into production <2 months. I've now see two > > > > instances of the problem described below and I'm fairly lost on how it > > > > could possibly happen. > > > > > The client first needs to login. When the server authenticates the > > > > credentials sent by the client, the server returns a User object which > > > > has a subset of the user's properties (a 'light' user object), plus > > > > the session ID as retrieved on the server by calling > > > > getThreadLocalRequest().getSession().getId(). The server keeps a > > > > hashmap of session IDs against a fully populated user object (which > > > > includes their permissions properties amongst other things). > > > > > Whenever a client accesses a GWT-RPC that should be protected, one of > > > > the parameters of the RPC is the light user object that the client has > > > > received from the server. The server authenticates this by: > > > > 1) Using HttpServletRequest.isRequestedSessionIdValid() > > > > 2) Comparing the session ID sent by the client (as stored in the light > > > > user object) and the one stored by the server's hashmap, and the one > > > > sent in the RPC's getThreadLocalRequest().getSession.getId(). Any > > > > inconsistency between the three raises an exception. > > > > > Recently, the second occurrence of a weird error happened: > > > > > The client has a timer which fires one of these RPCs every 5 seconds > > > > to refresh a table. This works really really well - we're using > > > > SmartGWT to have a grid that loads new data without the need to > > > > flicker or refresh (new rows simply appear, or existing rows update > > > > their data every 5 seconds). > > > > > On this RPC's callback onFailure I just give a generic message with a > > > > caught.getMessage() appearing in a popup. > > > > > I've had two instances reported by two different users on two > > > > different computers now (but both Chrome) this page has shown a popup > > > > showing my generic error, but the contents of the error is actually an > > > > error page ****from another website****. Its almost as though GWT made > > > > the RPC call to the wrong server! (the user sent me a screenie, and > > > > surely in my popup there's a 403 error from the gov website) > > > > > This completely blows my mind. > > > > > Both instances the error was from a different website (one was a horse > > > > racing site, one a government site). I haven't been able to confirm > > > > yet whether the users were actually on those sites at any stage or > > > > whether there were cookies from those sites (also note I do not > > > > specifically use the Cookies class, and I can verify in Chrome that > > > > the JSESSIONID cookie is set with the correct domain and path). > > > > > I haven't been able to replicate this either. I'm open to any > > > > suggestions on how this could be possible. > > > > > -- > > > > You received this message because you are subscribed to the Google > > Groups > > > > "Google Web Toolkit" group. > > > > To post to this group, send email to > > [email protected]. > > > > To unsubscribe from this group, send email to > > > > [email protected]. > > > > For more options, visit this group at > > > >http://groups.google.com/group/google-web-toolkit?hl=en. > > > -- > > You received this message because you are subscribed to the Google Groups > > "Google Web Toolkit" group. > > To post to this group, send email to [email protected]. > > To unsubscribe from this group, send email to > > [email protected]. > > For more options, visit this group at > >http://groups.google.com/group/google-web-toolkit?hl=en. -- You received this message because you are subscribed to the Google Groups "Google Web Toolkit" group. To post to this group, send email to [email protected]. To unsubscribe from this group, send email to [email protected]. For more options, visit this group at http://groups.google.com/group/google-web-toolkit?hl=en.
