Have you done something like this yourself? On May 26, 12:21 am, Sripathi Krishnan <[email protected]> wrote: > 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%2Bunsubs > > > > [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%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]. For more options, visit this group at http://groups.google.com/group/google-web-toolkit?hl=en.
