[
https://issues.apache.org/jira/browse/ISIS-1044?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14720255#comment-14720255
]
ASF subversion and git services commented on ISIS-1044:
-------------------------------------------------------
Commit af84e41ccbe5d286f3bf9cf2c50faf9447d227ed in isis's branch
refs/heads/ISIS-1044 from [~danhaywood]
[ https://git-wip-us.apache.org/repos/asf?p=isis.git;h=af84e41 ]
ISIS-1044: filtering changed so that it is "opt-in", only enabled from selected
callers.
It turns out that it's wrong to perform filtering all the time at the facet
(metamodel) level... there are other internal "trusted" callers of the
metamodel for which filtering should not be performed. Examples are the
auditing support, and creating XmlSnapshots.
As a first step to refactoring, have put a guard around the code via a
thread-local, and provided an API - InteractionUtils.withFiltering(Callable) -
which callers can use when they do want filtering.
Have then gone through the Wicket viewer (EntityModel, EntityCollectionModel,
ActionModel) and also the WrapperFactory (DomainObjectInvocationHandler) to
enable:
- In the case of the wicket viewer, it is enabled for property references,
collections, action results and also autocomplete, choices.
- For the wrapper factory, it is enabled provided that the execution mode is
NOT skipRules.
Note that the Restful Objects viewer currently has NOT been updated.
In addition, have simplified the configuration properties to a single property,
"isis.reflector.facet.filterVisibility".
~~~
All that said, I'm now realizing that even this isn't quite safe enough... the
thread-local stays in effect for the duration of the call to the getter or
action or autoComplete/choices method etc, and that in turn could call domain
services or flush the transaction which results in framework-level code (eg
auditing) then running while the thread-local is in effect. So next step is to
get rid of the thread-local just introduced, and simply filter in the caller
afterwards. I'll get there on this one, eventually...
> Table counts and gmap3/fullcalendar2 do not honour any vetoing, eg by
> subscribers or WithApplicationTenancy
> -----------------------------------------------------------------------------------------------------------
>
> Key: ISIS-1044
> URL: https://issues.apache.org/jira/browse/ISIS-1044
> Project: Isis
> Issue Type: Improvement
> Components: Core
> Affects Versions: viewer-wicket-1.7.0
> Reporter: Dan Haywood
> Assignee: Dan Haywood
> Priority: Minor
> Fix For: 1.10.0
>
>
> Suppose that the Isis addon security module is being used with application
> tenancy checking; this means that the Wicket table
> (CollectionContentsAsAjaxTable) will only show rows for those entities for
> which the user is authorized (the visibility has not been vetoed).
> However, the underlying EntityCollectionModel does contain those objects, and
> the size of that collection is what is shown in the "showing 1-5 of 15"
> totals etc rendered at the bottom of the table.
> So the question is: how to ensure that figure is correct?
> * One option is to eagerly check the visibility of every item (even those not
> on the current page).
> * Another option is to suppress the totals, somehow (would require additional
> metadata, along with a worse UI for users
> ~~~
> Related: the gmap3/fullcalendar2/excel Isis addons do not check for the
> object visibility, meaning that they expose information when they should not.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
