widget level security


From the forum and add-ons i’m gathering that authorization security on widgets (e.g display a widget only if the user has a specific role) is handled mostly close to the code that creates the widget. So for example

if (hasRole("ROLE_ADMIN"))

This seems a bit ‘nineties’ where we had tons of IF statements in the JSP for conditional display. Would it not make sense for Vaadin to have standardized security hooks embedded somewhere on a higher level (AbstractComponent?) in the framework ? Otherwise I don’t see much other choice than to subclass every single widget and add our security routines by overriding isVisible() … or something similar. This seems suboptimal. A higher level hook like setSecurityDecision(<> or high level delegation to a security registry created by the user would be more useful. The security implications of a secured widget would be such that the widget is not visible (so not ‘rendered’ in vaadin speak) unless the user has the required credentials.

Any other ideas ?


In your example, wouldn’t you have other buttons that
added if the user isn’t in the role? I don’t see how adding these details at the widget level makes things any easier. But maybe I’m just not understanding your suggestion.

I’d suggest one of two things. Either have a different page (aka Vaadin Application or Window) for users who are logged in, or else move all the optional bits into one section of code. Vaadin is a lot easier to use in that respect compared to a JSP, because you can do something like:

if (hasRole("ROLE_ADMIN")) {
    // layouts already created and added previously
    // etc

Because you’re creating a Java graph of objects and not an ordered xhtml document, you can add pieces to layouts, containers, etc, in one place after they’ve been created and keep all your security logic in one block of code.



That sort of thing sounds hard to do. It’s not easy to add extra properties to all components and then handle some rules during painting. It might have to be coded in the core, probably in the AbstractComponent, as you say. It is possible to makes hooks in an extended terminal adapter. RepaintRequestListener is another possible hook that could be useful.

You could perhaps register components affected by authorization in a security manager and then handle possible hooks there.