ok. one way to do this - according to your guidelines: 1. do form-based auth from gwt establishing tomcat-created session. 2. somehow establish mapping from this session to creds on servlet. 3. on subsequent requests, servlet obtains creds via session/creds map. 4. servlet uses creds for preemptive basic auth to backend (over https).
is this what you were hinting at? step 2 is a little hazy. I think that, it probably requires 2 requests from gwt client code: 1. form-based auth sends creds to tomcat, establishes session. 2. login request issued to servlet on this new session, again sending uname/pw. 3. servlet maps creds to session id for later use (step 4 above). any further comments, suggestions, etc are appreciated. thanks. On May 26, 9:30 am, Jorel <[email protected]> wrote: > I need to solve the general case where the backend service may be on a > different tomcat or even a different server. > I agree that the user can authenticate once to the GWT servlet using > frame based auth, for example. > this would establish the session between client/gwt-servlet. > > Next, requests from the user that require the backend service to > complete would need to be forwarded. > Since I'm using HttpClient from the servlet to complete the backend > request, how is the auth done at this point (between gwt-servlet and > backend service)? > > On May 26, 9:19 am, Jorel <[email protected]> wrote: > > > > > 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.
