[
https://issues.apache.org/jira/browse/WICKET-2089?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Dominik Drzewiecki updated WICKET-2089:
---------------------------------------
Attachment: annot-revised-and-working.patch
Yet another patch, sorry for being noisy here, but I am still learning
something new about wicket internals (apart from the fact that I screwed it at
the first take). Now it is both aligned to WICKET-2101 as well as well tested
and working. I can also provide a wicket-maven-archetype based webapp as a
proof of concept testbed for proposed
LinkedPageAnnotationsRoleAuthorizationStrategy.
Some random comments/thoughts:
- I intentionally omitted isInstantiationAuthorized(),,
- It is difficult (if not impossible) to write analogous
LinkedPageMetaDataRoleAuthorizationStrategy, as MetaData is attached to the
component, not to the class. I tried but gave up.
- How about considering putting proposed behavior into
AnnotationsRoleAuthorizationStrategy (possibly with a flag passed on the
constructor enabling this "deep checking") instead of providing new class?
> Perform authorization for links based on the page annotations they refer to.
> ----------------------------------------------------------------------------
>
> Key: WICKET-2089
> URL: https://issues.apache.org/jira/browse/WICKET-2089
> Project: Wicket
> Issue Type: New Feature
> Components: wicket, wicket-auth-roles
> Affects Versions: 1.4-RC2
> Reporter: Dominik Drzewiecki
> Priority: Minor
> Fix For: 1.4-RC3
>
> Attachments: annot-revised-and-working.patch
>
>
> It is a common case to hide links to the pages the user is not allowed to
> reach without a proper role. The proper annotations and strategies are
> already in place but one has to write her own component classes for them to
> be taken into account. While it is nothing unusual to write pages, panels or
> so (and providing authorization annotations on them) and let wicket decide
> whether to show or hide them, it is way less frequent to write Link
> implementations, but rather developers use already provided set of Link
> classes. Moreover, those custom Link implementations would provide no
> functionality over inherited classes, but merely act as a placeholder for the
> authorization annotations, which would be anyway duplicated from the pages
> they are referring to. I suggest extending
> AnnotationsRoleAuthorizationStrategy so that whenever the component to check
> authorization on is of PageLink, BookmarkablePageLink or their descendant
> type, the authorization should be performed first based on their own
> annotations and later on, on the authz annotations of the pages they are
> referring to. A patch following shortly.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
