Stefan, while I agree that GWT-RPC inherently gives some XSRF protection, I don't think it should be relied upon. First of all, any service that performs an action in a REST architecture should use a method other than GET, such as POST, PUT or DELETE; therefore the argument of GWT-RPC running over POST is a moot point because the only thing available over GET will be data retrieval, which should still be concerning, but still satisfies your argument. Also, the safari problem of only supporting GET and POST was only present in Safari 1.x and there has been discussion within the GWT contributors to open up the constructor for RequestBuilder to all methods because less that 1% of users would be effected.
Secondly, security by obscurity is a poor and irresponsible design decision and should not be considered at all. Lastly, almost all Java app servers provide container managed security and this should fit the needs in 95% of all apps, so why develop your own? Just add annotations to your web.xml that sets security restrictions on certain URL paths for users in certain rules. When it gets too complex for that there is also a RolesAllowed annotation and you can inject the security context to gain access to the users roles and principal. I understand that the majority of GWT developers aren't J2EE devs, but so often people talk about GWT as if it was some sort of standalone product when it was designed to be modular and take advantage of an already mature Java enterprise environment. Container managed security can also be used for GWT-RPC; try it sometime you'll love it; although getting form login to work with GWT can sometimes take a little trickery as most app servers are based off of Tomcat and Tomcat treats the forwarding for form login differently depending on if you are using SSL or not(redirect vs request dispatch). I recommend just starting with basic authentication till you are comfortable enough to try getting form to work, it is simple but can cause problems with GWT. It sounds like Marius might not be running on a Java server, so this might not apply and a custom security solution may be necessary, but he seems to have this worked out already. I completely agree with you that opening the allow origin up is a very poor decision as far as security goes and if you absolutely must make cross-site requests a proxy servlet is the best option assuming JSONP can't be supported. One last point... Even though GWT-RPC has some small advantages over REST because it is based on REST, it is by far not the best solution for large projects. The main purpose of using REST is that it is platform independent as far as the client goes. With GWT-RPC only GWT can be used, but with REST anything can consume it, especially when you expose several different output media types like I do. For my services a client can request that I send the response back in 4 different forms: XML, JSON, JSONP and Java Serialization. This is very important because possible consumers of our services include Java, JS, C++ and C# clients. We could argue all day on which implementation is better and it truly comes down to the fact that it depends on the requirements of the project. For work projects I tend to use REST; for personal I use GWT-RPC because I know the client will always be GWT. On Aug 14, 4:01 am, Stefan Bachert <stefanbach...@yahoo.de> wrote: > 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 > vectorshttp://code.google.com/p/html5security/wiki/CrossOriginRequestSecurity > > At least use a concrete list of sites which is under your control. > > Stefan Bacherthttp://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.
