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 <sripathi.krish...@gmail.com>
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 <joel.re...@gmail.com> 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 google-web-tool...@googlegroups.com.
> > To unsubscribe from this group, send email to
> > google-web-toolkit+unsubscr...@googlegroups.com<google-web-toolkit%2Bunsubs 
> > cr...@googlegroups.com>
> > .
> > 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 google-web-tool...@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