Hi marius, I have to admit that my statement was to hard. Webservice are intended to be accessed from different "distributed, scattered" site. I am still not sure whether this the case in your project.
When you access multiple REST sources, it is unlikely to connect them all at login time. When you defer a login for some data source you have to save the credentials to do so. GWT-RPC is more secure because. a) GWT-RPC always uses POST. This means a CSRF attack is no more easy (but not impossible as any attacks) b) GWT-RPC automatically add an header with sends the strong name back to the server which will be checked. So it takes more effort to attackers to supply this additional header, too. (X-GWT-Permutation) A problem with REST directly is mentioned in the GWT javadocs. webkit based browsers (safari) seams to have a bug when using other methods then GET or POST. When you can't guaranty that you never use other methods, you could not support safari. Access-Control-Allow-Origin: * I consider this as real bad (independly which protocol you are using). You give up SOP and open new attack vectors http://code.google.com/p/html5security/wiki/CrossOriginRequestSecurity At least use a concrete list of sites which is under your control. Stefan Bachert http://gwtworld.de On 11 Aug., 18:46, "marius.andreiana" <marius.andrei...@gmail.com> wrote: > Hi Stefan , > > I'm not sure I understand your point. > > Say we have api.site.com, with the back-end written in a non-Java > tech, which offers REST APIs over SSL such as > POST login > Body: data username, password > Response: auth token > > GET tweets > header: auth token > Body: none > Response: tweets > > api.site.com will return on all headers > Access-Control-Allow-Origin: * > so that the UI can be served from ui.com but still access the APIs > (same origin policy). There won't be anything else on api.site.com > besides stateless APIs (no cookies, no html files). [Is this secure?] > > User navigates to ui.com. The UI gets username & password, passes it > to api.site.com, then it will store auth token and use it on all > further requests (same as a cookie stories session id on other > systems). > > How is this less secure than GWT-RPC approach? > > On Aug 11, 10:23 am, Stefan Bachert <stefanbach...@yahoo.de> wrote: > > > Hi marius, > > > using REST, SOAP, JSON directly from the browser client is always > > insecure. > > This is because the browser client has to know the credentials. > > Either these services are not protected at all, or your credentials > > are likely to be stolen. > > > When you need a minimum of security and privacy, your gui browser > > client should only talk via GWT-RPC to a GWT-server under your > > control which gathers all data from REST, SOAP or JSON services. > > > Stefan Bacherthttp://gwtworld.de > > > On 10 Aug., 04:27, "marius.andreiana" <marius.andrei...@gmail.com> > > wrote: > > > > Hi, > > > > We're working on a large project, which has the back-end is written in > > > a non-Java technology, with REST APIs. We're looking for a framework > > > to replace the current UI. > > > > I did a brief analysis of using > > > GWT:https://docs.google.com/document/edit?id=16rQknO-r3ZqfMbuIl0R52OnFcWB... > > > > I'm looking to get this group's feedback before I present my findings > > > to the team. What do you think? > > > > Thanks, > > > Marius -- 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.
