Using authorization to stop RENDER action doesn't work with as expected with repeater components
I'm building a Wicket-based project that uses Wasp/Swarm for
authorization. I've connected it to Spring Security to use it as an
authentication backend, and I've also used Spring Security to perform
authentication and authorization on my middle tier Spring beans.
I have a secured web page with three panels in them (ListPanelA,
ListPanelB, ListPanelC), but I only want some of them to display for
different roles. Each panel inherits from SecurePanel and the page
inherits from SecureWebPage. The panels have repeater components in them
(DataView, which has inheritance hierarchy
Component-WebMarkupContainer-AbstractRepeater ...
-AbstractPageableView-DataViewBase-DataView).
i.e.
OverviewPage
--ListPanelA
DataView
--ListPanelB
DataView
--ListPanelC
DataView
The problem I am having is with setting component permissions on panels.
For the basic ROLE_STAFF there is no permissions on these panels, but I
have added a RENDER permission for certain users. When the page renders,
each panel still calls onBeforeRender() on each component in its
hierarchy even though the panel has no Component.RENDER authorization.
This is a problem because onBeforeRender() in AbstractRepeater still
calls AbstractRepeater.onPopulate(), which causes the pre-rendering
value loading to take place, even though later on the component is not
even rendered. In my case, I'm relying on onPopulate() not being called
so that it doesn't try to call the (secured) middle tier methods.
The relevant parts of my Swarm configuration is as follows:
grant principal
org.forge.smartdata.server.ui.security.SpringSecurityPrincipal
ROLE_STAFF
{
permission ${ComponentPermission}
org.forge.smartdata.server.ui.management.OverviewPage, render;
permission ${ComponentPermission}
org.forge.smartdata.server.ui.management.OverviewPage, enable;
...
};
grant principal
org.forge.smartdata.server.ui.security.SpringSecurityPrincipal
ROLE_RESEARCHER
{
...
permission ${ComponentPermission}
org.forge.smartdata.server.ui.management.ListPanelA, enable;
permission ${ComponentPermission}
org.forge.smartdata.server.ui.management.ListPanelB, enable;
};
grant principal
org.forge.smartdata.server.ui.security.SpringSecurityPrincipal
ROLE_REGISTRAR
{
...
permission ${ComponentPermission}
org.forge.smartdata.server.ui.management.ListPanelB, enable;
};
grant principal
org.forge.smartdata.server.ui.security.SpringSecurityPrincipal
ROLE_DEPLOYER
{
...
permission ${ComponentPermission}
org.forge.smartdata.server.ui.management.ListPanelC, enable;
};
In the case above, ROLE_DEPLOYER, ROLE_RESEARCHER and ROLE_REGISTRAR all
imply permission ROLE_STAFF. If I were, for example, to login as
ROLE_RESEARCHER, it should render ListPanelA and ListPanelB but not
ListPanelC. However, I am still getting the onPopulate() actions for the
ListPanelC solution.
I dug around and found out that Component.prepareRender() doesn't check
if rendering is authorized until after the beforeRender() process has
finished. However, this still seems to cause repeater components to try
and prepare themselves for rendering by populating their internal
hierarchies.
Is there a way to circumvent this cleanly without having to put security
checking code into my page or create a different page for each user?
Thanks
Chris
--
Christopher Armstrong
carmstrong ^^AT^ fastmail dOT com /Dot/ au
-
To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org
For additional commands, e-mail: users-h...@wicket.apache.org
Re: N-level CompoundPropertyModel
Hi Willis
The quickest solution to this one I've found is to use a normal
PropertyModel, which doesn't seem to drill down through the nested
models.
In your case
public class BigPage {
public BigPage(BigObject object) {
setModel(new CompoundPropertyModel(object))
add(new SmallComponent(smallObject, new PropertyModel(getModel(),
smallObject)));
}
}
It seems to be a bit of a hack, but it works well enough. It prevents
having to probe the BigObject by calling object.getSmallObject()
yourself. It would be useful for the situation where you have a
LoadableDetachableModel and don't want to instantiate it twice or load
it in the constructor; you would just be able to wrap them like above.
Anyone have a cleaner solution - I come across this a lot,
particularly when using panels. Is this something begging for a better
abstraction?
Regards
Chris
On 16/02/2009, at 3:19 AM, Willis Blackburn wrote:
Hello,
I have a situation that keeps coming up. All of my solutions have
seemed clumsy, which makes me think that there's a better way of
approaching this that I just haven't figured out. Can someone point
me in the right direction?
What I want is to have a Page that uses CompoundPropertyModel, and
then include a component on that page that also uses
CompoundPropertyModel. So roughly it looks like this:
public class BigObject {
public SmallObject get SmallObject() { ... }
}
public class SmallObject {
public String getName() { ... }
}
public class BigPage {
public BigPage(BigObject object) {
setModel(new CompoundPropertyModel(object));
add(new SmallComponent(smallObject));
}
}
public class SmallComponent {
public SmallComponent() {
add(new Label(name));
}
}
If I try to do just this, then I get an error because the label
that's part of SmallComponent finds the BigPage model and fails
because there's no property of BigObject called name.
So obviously SmallComponent needs some model:
public class SmallComponent {
public SmallComponent(IModel model) {
setModel(new CompoundPropertyModel(model));
add(new Label(name));
}
}
But what model to give it? I tried passing it new
ComponentPropertyModel(smallObject), which didn't work because
ComponentPropertyModel implements IComponentAssignedModel and thus
can't be directly wrapped in CompoundPropertyModel. Adding a call
to wrap() in the SmallComponent constructor fixed the problem, but
I'm not sure if I can just call wrap and carry on or if there will
be some unforeseen consequence of that down the road. Is there a
standard way of doing this?
Thanks,
Willis
-
To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org
For additional commands, e-mail: users-h...@wicket.apache.org
Christopher Armstrong
carmstr...@fastmail.com.au
-
To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org
For additional commands, e-mail: users-h...@wicket.apache.org
Re: Wicket at ApacheCon EU'09 in Amsterdam
Hi all I'm new to this list (and Wicket), and was interested in this discussion. On 12/02/2009, at 11:32 PM, Hoover, William wrote: Just out of curiosity... Are there any plans to push a JSR that Wicket could follow. I think there would be a lot more acceptance of Wicket if this was to happen :o) It might be interesting to examine this idea in the context of OSGi. OSGi is a standard for componentisation and packaging and component lifecycle management that has it roots in embedded devices, and incorporates a whole range of further standards related to this type of platform. It grew out of efforts that were mostly independent of Sun, and has continued to evolve as a standard in a separate organisation to the JSR process. It now has a JSR (277), but the OSGi specifications evolve separately of this original JSR. It has multiple implementations (Felix, Equinox, Knopflerfish, etc). Its flexibility in its design (extender bundles, manifest extensions, whiteboard model, etc assist this) has led to many addons that build upon it such as Spring DM, iPOJO, etc. In the next version of the specification many of these community ideas will be incorporated back into the main specifications. The Core OSGi specification doesn't add much to the language, but its Compedium specifications, which build upon the Core spec, provide everything from configuration management, device resolution, to user administration and logging. Sun were looking at using it in Java 7 in order to modularise the JVM, a similar goal to the Apache Harmony project IIRC. They have since dropped this goal and have revived JSR 294 for modularisation. OSGi continues to move along alone and gain its own popularity without the JSR/JCP process. Sun's attitude seems to be to just ignore OSGi (a form of NIH syndrome?). IMHO what this means for Wicket is: unless it provides a small base for lots of extra functionality to be built upon, its just going to get mired in the politics of the JSR/JCP process and not really achieve anything. It will probably end up being shunned as a competitor to JSF and left unresolved. It may be better for Wicket to look at managing its own APIs so there is less breakage between versions (note: I've only begun using Wicket recently so I'm not trying to suggest this is the case) and that versions are clearly delineated in terms of API compatibility between them. It could try and elevate the Wicket extensions to be more tightly managed within the Wicket project, and seek from time to time to incorporate these back in into the Wicket mainline. In this way, Wicket becomes standardised but still maintains the freedom to innovate more quickly. Wicket seems to be tightly modularised enough (or able to modularised) that using Wicket as a base to grow new and interesting functionality whilst maintaining a stable core seems feasible. Cheers Chris --- Christopher Armstrong carmstrong at fastmail com au. Christopher Armstrong carmstr...@fastmail.com.au - To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org For additional commands, e-mail: users-h...@wicket.apache.org
