Re: Problem and fix: filteredTreeNodes doesn't respect hasAccess()

* Dr. Frank Hoffmann <[email protected]> [080625 16:15]:
> Thanks for the code proposal.
> In fact the wording "accessible children" might be misunderstood; it should
> be "visible children".
> 
> Anyway, I would prefer to take some conditional hasAccess() into the
> presentation template - for example to show the objects the user will see,
> if he has the access.

Hmm. Are you sure about this?


Then, I would have a major cavet about DC.accessRights.Restricted as it
is described in
http://www.zms-publishing.com/support/content/e732/e736/e1620/e2430/.

The description says "Access to a content node is recursively secured"
and "no reading access does exist any longer for the corresponding
document resp. subsequent folder structures."


PROBLEM 1: Currently, when an anonymous reader tries to visit a folder
protected by DC.accessRights.Restricted, he gets a login panel asking
for authorization. When he cancels the login panel, he still gets
delivered the allegedly protected page, although he is not authorized
(cf. attached screenshot):
- Only the content column is protected, replaced by an error message.
- Even teasers defined on the protected page are visible
- The complete navigation structure is visible (e.g. documents,
  subfolder etc.)

PROBLEM 2: Secured pages show up in search results.

PROBLEM 3: Secured pages show up in the NewsIndex.

PROBLEM 4: Secured pages will show up in any third-party objects
that doesn't explicitely filter out such objects with hasAccess.


From my point of view, this behavior conflicts with the description of
DC.accessRights.Restricted. I would have expected that the content of
secured folders won't get out to anonymous users (never and nowhere).
Note: I would count teasers and title to the content.


With my patches, all of the above just felt in place, as I would have
expected. (Side effect: The protected folder doesn't show up in the
navigation any more. So you would have to make the login explicit.)


If, as you describe, the hasAccess() check was implemented in the
presentation layer, then each and any object / Special Object has to
take care of the protection on its own. As we can see above, even the
objects included in the ZMS core don't do that yet.

I would prefer instead to enforce the protection by default.
So that objects protected by DC.accessRights.Restricted aren't visible
at all if the user has no hasAccess().

If some code needed to access the protected objects in an anonymous
session, then maybe the API of filteredTreeNodes() et al could be
expanded with an optional attribute (e.g. showUnaccessible=None).


As it stands by now, I think DC.accessRights.Restricted is harmful, as
it implies more security then it does provide.



With regards,
    Gregor


-- 
Gregor Hoffleit <[email protected]>
Media Supervision Software Consulting GmbH
Georg-Friedrich-Haendel-Str. 13, 69214 Eppelheim/Heidelberg
Tel: +49 6221 705079-0  /  Fax: +49 6221 705079-80
Amtsgericht Mannheim, HRB 336821, Geschäftsführer Reinhard Kratzke
http://www.mediasupervision.de/