> I haven't read up in detail on the new RequestFactory implementation except
> for the information I've read here on the group. I gather from what I've
> read then that RequestFactory is totally data specific and its only
> intention is to persist any data that has been changed on the client back to
> the server. It therefore seems, for example, that if it were required for
> security reasons, for instance, to validate that the request to the server
> is made with a valid session id and the session was still active that
> RequestFactory would not be the api to use and that instead the older
> RemoteService api would be the one to use, correct?
No.
The first thing the RequestFactoryServlet does is to (paraphrasing the
comment in the code) "check that user is logged in before
proceeding" (this is done by "getting" a UserInformation instance,
which has access to the servlet request through
RequestFactoryServlet.getThreadLocalRequest() so you're free to do
whatever checking you want; the actual implementation is given by the
userInfoClass servlet init parameter; see the Expenses sample for an
example using AppEngine's UserService), and return a 401 HTTP response
if it's not the case (which you can trap on the client-side).
On the client-side, RequestFactory uses by default a
DefaultRequestTransport, which you can extend (or even replace, I
think you could use WebSocket or Comet or whatever if you liked) to
send the "session id" in the request payload (for instance); similar
to the RpcRequestBuilder for GWT-RPC.
--
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-toolkit@googlegroups.com.
To unsubscribe from this group, send email to google-web-toolkit+unsubscribe@googlegroups.com.
For more options, visit this group at http://groups.google.com/group/google-web-toolkit?hl=en.
No comments:
Post a Comment