You don't necessarily need multiple web.xmls / war files. Your GWT RPC Servlets (proxy servlet, as you call it) can reside in the same war file as your back-end services; you just need to package it appropriately. If you do that, you have the same session across both the servlets.
--Sri On 26 May 2010 06:36, Jorel <[email protected]> wrote: > ok. I understand the disadvantages, primarily the avoidance of > keeping credentials on the client. > We were planning on using HTTPS, so passing creds in cleartext would > not have been an issue. > So, can you elaborate a bit more on standard session techniques? > I'm a little unclear on how to maintain a session across the proxy > servlet. > My understanding is that we would have an opportunity to have two > separate web.xml files, one for the gwt servlet (proxy) and one for > the backend services, each being a separate tomcat app. > The authentication could be done against the same auth module (i.e. > LDAP) but the GWT-RPC session would be a different session from the > proxy/backend-server session. > So, how does the proxy servlet 'link' the 2 sessions? > sorry if that sounds dumb, I'm not sure how to phrase it. > > > On May 25, 3:28 pm, Sripathi Krishnan <[email protected]> > wrote: > > Although it can be accomplished, please don't. > > > > *How it can be done?* > > > > 1. RPC async interface implements ServiceDefTarget. Using this > interface, > > you can set a custom RpcRequestBuilder > > 2. In your custom RpcRequestBuilder, override the doCreate() call > > super.doCreate() and get an instance of RequestBuilder > > 3. Once you get the instance of RequestBuilder - invoke the setUser() > and > > setPassword() methods > > 4. Alternatively, you may want to pass the username/password as header > > values. Call the setHeader() method on RequestBuilder to do so. > > > > *Why you shouldn't do it?* > > Its not secure, unless you are using HTTPS for all communication. Even if > > you are using https, you don't want to maintain the username and password > in > > javascript - it makes you vulnerable if you have a XSS vulnerabilities. > And > > finally, storing the users password in any retrievable form is wrong. > > Instead, you want to salt and hash passwords. Don't use encryption, > because > > that implies there is a way to recover the password. > > > > Just use standard session techniques. You can login the user once, and > then > > maintain a session on the server side. Your proxy servlet can then invoke > > the back-end service on behalf of the logged in user, since it has that > > information in session variables. > > > > --Sri > > > > On 26 May 2010 01:21, Jorel <[email protected]> wrote: > > > > > > > > > Hi. I have a GWT application running on tomcat that will be using GWT- > > > RPC to talk to a proxy (gwt servlet). On the proxy I plan on using > > > preemptive basic authentication to communicate with the backend > > > server, also running on tomcat. I have figured out how to send the > > > credentials 'preemptively' to the backend server. So, one approach to > > > make this work seamlessly from GWT client to backend server is to > > > somehow inject the username/password into the auth header from within > > > the GWT client. So, when the user logs into the application, their > > > username/password could be obtained and injected into the header. The > > > proxy server (GWT-RPC servlet) would obtain this information and pass > > > it through to the backend server. > > > > > I have the proxy/backend part working fine. I am about to start on > > > the part where my GWT application injects the username/password into > > > the header of all requests. > > > > > I'm not sure what the best approach is to accomplish this. Does > > > anyone have a good understanding of how this should be accomplished? > > > > > thanks. > > > jorel > > > > > -- > > > 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]<google-web-toolkit%[email protected]><google-web-toolkit%2Bunsubs > [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]<google-web-toolkit%[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.
