I’m fairly new to GWT (been using for about 8 months) and have just read the Vaadin book.
Our web applications are divided into modules (features). A typical user does not have access to all the modules. For example, we have an application where the interface is tabbed, each tab being a module, and a typical user will not see all the tabs.
We have started migrating these applications from JSP with Ext JS to GWT. Using JSP, the code for a module (tab) would never be loaded into the user’s web browser, which is what we want for security reasons. We do not want the user to even know that a module (tab) exists when they don’t have access to it. If the module (tab) is loaded into the user’s web browser and simply hidden, the user can still inspect the code loaded into the their web browser and determine that this other module exists.
With the introduction of GWT code splitting, we expect to split the GWT compiled code into modules so the code for a module (tab) will not be loaded into the user’s web browser if they don’t have access to it.
Reading about Vaadin, it seems that one can readily code split out a widgetset, but I believe this is a different than what I want, because a widget from a widgetset may be used in (shared by) multiple modules.
Am I misunderstanding? Is it readily possible to do what I want with Vaadin, which is code split out a module (feature) of my application?
The biggest difference between in GWT and Vaadin is that in Vaadin the user interface resides in the server-side memory. That makes it easier for you not to expose your UI code to anyone.
The full widgetset is loaded to client, but it only contains the core presentation logic of the UI widgets like a label or textfield. Otherwise your application UI is never sent to client unless it is visible.
So, in Vaadin if you just don’t make something visible to user, he/she has no way of knowing that a part of UI actually exists in the system at all.
(Note: I ignored the code splitting of a widgetset as well as built-in caching in the description above, but that does not change anything security-wise.)
Does this mean, that the GWT code for the hidden modules still exist on the server and can be requested with an HTTP request, the browser just doesn’t load these modules? If so, then your security would be based on so called “security by obscurity”, which means that you trust that the user doesn’t know (or is unable to guess) the URL for the hidden modules’ JavaScript code. If this is the case (I’m not familiar with GWT’s code splitting so I don’t know), I have to warn you that it is a very, very bad idea (from a security point of view).
Like Sami mentioned, with Vaadin, the widgetset only contains the presentation layer of an individual component - not the presentation layer of the application. This means that the application logic or “hidden presentation logic” is never exposed to the client and a malicious user would not be able to access the presentation logic of your hidden modules, not even with carefully crafted HTTP requests. Actually, since the widgetset only contains the client code of individual components, it means that multiple Vaadin applications could share the same widgetset, as non of the application specific code is ever exposed to the client.
Well, to understand our status better, we have started developing GWT modules that are being used in existing page-based applications that were developed using JSP and JavaScript. At this stage, when the user wants to access a GWT module he clicks a tab, which requests an entire new page from the server (page-based) that includes the GWT history
Now GWT presents a different challenge. Eventually, we will have entire applications developed with GWT (logically divided into features (what we call modules)), so we will no longer be using a page-based architecture. Using GWT without code splitting, the entire UI code for the application is loaded into the user’s browser (including all the modules (features)). Which means the UI code for modules (features) that the user does not have access to will be available for the user to hack if they view the JavaScript code that was loaded into their browser.
If we use GWT code splitting, we can split the UI code for each module into separate JS files, and secure those JS files by preventing unauthorized users from downloading them. The JS files not only have logic that we don’t want an unauthorized user to access, but also strings (terms) that are sensitive. For example, if a module has its own GWT Messages interface, then we do not want the JS code for that module’s Messages loaded into the user’s browser when the user does not have access to that module.
I’m trying to wrap my head around how this would work in a Vaadin application.
Just to clarify my and Kim’s point here for everyone else too:
GWT code splitting is good performance-wise, but introduces no extra security unless protected by some other mechanism. Application code in GWT is always loaded to the browser before it is executed.
In turn in Vaadin the client-side part is simply a
static set of widgets compiled with GWT. Your actual application implementation is never pushed to the browser.