Hi,
I have just experienced some strange access things regarding annotations on a entity (blog, etc.).
User A creates a blog, setting access to friends only.
User B comments on that blog. Comment gets an access of friends only
User C wants to read comments, but is not friend with B, so he/she can only read the blog, not see comment given by User B. User C gives a comment, which then can only be read by User A and and him self, not B.
I can see from the code, that annotations allway inherit the access_id of the entity they belong to. That must give some issues when using anything else than public!
A fix could be to allways set annotations to public access, and then make sure they are only shown to those who have access to the entity they belong to.
Anyone has some input on this, or should it go to bug tracker?
info@elgg.org
Security issues should be reported to security@elgg.org!
©2014 the Elgg Foundation
Elgg is a registered trademark of Thematic Networks.
Cover image by RaĆ¼l Utrera is used under Creative Commons license.
Icons by Flaticon and FontAwesome.
- Kevin Jardine@kevin
Kevin Jardine - 0 likes
- slyhne@slyhne
slyhne - 0 likes
- E.@ppw-ebertram
E. - 0 likes
- manfred salomon@lisha
manfred salomon - 0 likes
- slyhne@slyhne
slyhne - 0 likes
- manfred salomon@lisha
manfred salomon - 0 likes
- manfred salomon@lisha
manfred salomon - 0 likes
You must log in to post replies.In my view the idea of allowing annotations and metadata to have access levels is a significant design flaw in Elgg. I believe that annotations and metadata should be accessible if and only if the user has access to the entity they are attached to. I believe that non-entity access levels were added so that profile fields can be metadata but still have independent access controls, but this makes the whole Elgg API more complex than it should be.
But water under the bridge.
In this case, I think that the problem could be solved by interpreting friends access for annotations and metadata as relative to the owner of the entity and not the owner of the annotation or metadata item. I'm surprised it was not done that way, and if not, it is probably a bug.
So it should probably go in the tracker.
Hi Kevin
I put the issue in tracker. Thx for your response.
Hi Kevin,
thanx for your post. In my opinion you are totally right.
In theorie the flexibility of access levels in elgg is fine, but in practice it is sometimes quite confusing or even makes no sense!
what is about the access_id of the river?
it's confusing for the user, wenn he sets an entity to 'privat' in the widget
and corresponding entries are still seen in the river . . .
it makes sense, then even new entities with new access-level are shown on the river
but the user expected, that the access-level in the river works like in the widget
for user it's a 'error' and touches his privacy when corresponding entries to an entity
are still seen in the river
i think the access_id in the river table is obsolete,
but i can imagine that it could be a peformance-problem to join to actual access_id of the entity,
so it could be a solution: when user changes the access-level of an entity, an update query runs over the river table (because this can also make performance-problems you could ask the user if he want to change the access-level for all new entries or change also the old entries)
As a very dirty workaround. In /engine/lib/views.php around line 766
This should only affect access to annotations if you have access to the entity they belong to.
@slyhne it's not dirty ;-)) for me, it's the 'interim-solution' till it's handled with a sql-query :-)
the approach is right, the entity the annotation belong to, is the master and triggers the access to the annotation
thanks a lot
@interestedmembers for elgg 1.8 search function 'elgg_view_entity_annotations' and change code like @slyhne shows above
an other approach:
look at page/components/list.php
elgg_view_list_item($item, $vars) displays the items of the activity/* pages
what do you think about?:
foreach . . . .
if ($item->access_id == get_the_accessID_of_the_entity-type_from_widget_settings_of_the_user(){
$html .= elgg_view_list_item($item, $vars);}
endif
this assumes that the user triggers the visibility of his data with the access permissions for the widget-content on his profil-page and i think, this what the user expects
so
if a entity is saved the access_id comes from the widget permission (e.g. thewire) or is explicit set in the form (e. g. Blog)
what do you think?