Hiding scoped beans from views

[rdelaplante]

Hi,

A while back a built a JSF 1.2/Facelets/Spring system that let me build different skins/themes for all of the screens. Each theme has its own unique HTML, CSS, images and language files, but they share the same managed beans, validators, etc. 

I'm thinking about building another system with similar theme/skin capabilities, but am concerned about users creating themes that have full access to anything and everything that is in WebBeans.  It's been a while since I read the WebBeans spec so I am not up to date on it.  I know when using Velocity or Freemarker I have complete control over what the views have access to.  I don't even have to expose entire domain models. I can feed the views exactly what I want.

Does anyone know if I'll be able to do this in CDI and JSF 2.0?

Thanks,
Ryan

[pmuir]

I don't entirely understand the use case. Could you explain more what feed the views means, and what FTL allows you to do, and how?

[rdelaplante]

Pete Muir wrote on Sep 13, 2009 21:05:


I don't entirely understand the use case. Could you explain more what feed the views means, and what FTL allows you to do, and how?

When using Velocity, I use the APIs to load a template file into a Template object (or whatever it's called), then use a setter on the object to feed it a collection of objects that will be made available to scripts inside the template.  I might even provide read only stripped down copies of domain objects to the template instead of JPA entities. Scripts inside the template do not have access to any object other than what was explicitly provided to it by my application.  If I allow users to upload their own templates for a particular screen or email, I don't have to worry about them getting access to every other managed bean used by the web application and using them to do bad things.

In JSF, if I were to allow users to upload their own facelets templates for use in some screens or emails, there seems to be nothing stopping them from accessing anything and everything they want using EL (JSF Managed Beans, Web Beans, etc)

[pmuir]

I see, you are essentially creating a sandbox by adding a level of indirection.

With the situation you've described, my first suggestion is to simply not expose those beans you don't want use to access to EL. I guess you may have other pages in the app that require access to other beans?

[rdelaplante]

Pete Muir wrote on Sep 23, 2009 20:58:


I see, you are essentially creating a sandbox by adding a level of indirection.

With the situation you've described, my first suggestion is to simply not expose those beans you don't want use to access to EL. I guess you may have other pages in the app that require access to other beans?

Yes, screens built into the application will need access to MBeans that should not be accessible by users creating templates for other things.   I think for some parts of the system this will be a risk the administrator will be in control of (install customized themes created by himself or his company).  In other parts of the program, I could use Velocity or Freemarker to preprocess some output then insert it into a parent facelet template.

Thanks,
Ryan

[pmuir]

Yeah, I don't feel this is something that CDI itself should support.

I would recommend doing this perhaps with a custom EL resolver that applies your restrictions? You would need to know where the EL resolution is coming from, which is tricky.

Another approach entirely is to write a validator, which knows which beans are allowed.