the following might sound somehow paranoid, but listen:
We´re using Vaadin 7 with a self-made login dialog. This means, that Vaadin is already “fully active” before the user even logged in. We just had a security assessment from an external advisor. He found out, that because the vaadin app is in fact already running, the browser sees the following:
He told us that this is a security issue, because an attacker already sees the exact vaadin version we´re using before he even managed to log in. He could use that information to find out (by using e.g. google) possible security issues in that version which he could then use to start his attack.
So the requirement is to hide that information at least until the user has successfully logged in.
Hi, this might be tricky. It’s possible to prevent sending the version info to the client by replacing the BootstrapHandler, but this is not enough as it’s also hardcoded into the widgetset. The client compares the versions and displays a warning notification if they don’t match. The same is done on the server side.
Now, IMHO, this check should not be done in production mode, but currently it is. The version number itself is set at build time, so building your own custom version might be the only feasible way of working around this issue right now. Or, of course, implementing the login part outside of Vaadin, which I think is actually a pretty common way to do it.
That’s what we do. We have the login/logoff pages as JSPs without using Vaadin, and on successful login, redirect to the Vaadin UI. The advantage for us was session management as Vaadin requires a session, whereas on logoff, the logoff page ensures any session has ended (and BACK won’t let you see the prior application page) and the login page only starts a session on a successful login (POST).