I would like to implement a GWT application where users log in and are assigned roles, as is typical in many web applications. Based on their role, they would be able to see and use different areas of the application.
The trouble when using GWT is, because the entire application is transmitted to the browser (deferred binding is the exception, but more on that later), even people who have no permission to view a certain part of the application have downloaded the (albeit obfuscated) JavaScript code. There was a good discussion about this pertaining to the case of wanting to create an "admin area" of an application: http://groups.google.com/group/google-web-toolkit/browse_thread/thread/2b32e4d4011076c/cd8553caf7aa6994?lnk=gst&q=role#cd8553caf7aa6994 The general consensus was that it's sufficient to protect the data and not the UI. This may be true, in that when a user authenticates, the server now knows that user's role, and each subsequent RPC made with a session ID associated with that user undergoes a role check. Users are denied if they try to execute RPC methods when they don't belong to all of the roles required to execute that method. However, it's still less than ideal for at least two reasons: 1) Even though users cannot execute, for example, administrative RPC methods, by reverse engineering the JavaScript they may still be able to read sensitive information regarding the format or nature of the available administrative requests. Careful developers may be able to avoid revealing such information, but it may not be easy to instruct every developer on the team on how to avoid revealing subtle but security-sensitive clues about the system. 2) Some users will download code that they will not necessarily execute, making the application needlessly larger. So there are a couple of possible solutions to this: 1) If you're only talking about a single role, like administrator, create a separate GWT application for administration and protect that on your web server. Yes, it might be less than ideal in that you can't easily share the same interface with the regular user application, but it should solve the problem. 2) One possibility that could generalize to more roles is to use deferred binding (http://code.google.com/webtoolkit/doc/1.6/ DevGuideCodingBasics.html#DevGuideDeferredBinding). Using replacement with deferred binding, entire code paths might be compiled out of the application for example by, in the user case, not including the administrative tabs. But then you'd have to figure out exactly which files in the war need to be protected (this might not be easy and when re-compiles occur if their name changes you'd have to do it again) and protect them on the web server at a file level. Also, if you have more than just a couple of roles you'd have an explosion in the amount of code that needs to be generated on a compile and on the size of the application stored on the server, because each role would be a new axis for deferred binding. I think this would be 2^R, where R is the number of roles. So if you've got 5 roles, you've got 32 versions of your code. If you multiply that for 5 browsers and 4 languages, now you're talking about 640 versions of your code. It starts to get impractical, doesn't it? Especially when the code in each version is largely duplicated. So has anyone thought of a better solution to this problem, or does anyone know if something is planned for a future GWT release? I didn't see this referred to in the Google I/O video on 2.0 (http:// code.google.com/events/io/sessions/GwtPreviewGoogleWebToolkit2.html). As far as I can tell, the new code splitting stuff is just for reducing the download size and startup time... --~--~---------~--~----~------------~-------~--~----~ 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 -~----------~----~----~----~------~----~------~--~---
