By Date: <-- -->
By Thread: <-- -->

dyndata privileges



Upon messing around with a login history logger, I bumped into a problem 
that affects most people: you can only enable submission of data to 
dynamicdata (directly or through being hooked in to other modules) if 
you grant read access on the dynamic object to those users.

This means that for example if you store your sitecontact responses in 
dynamic data, all users will have access to all the responses submitted 
by others. The same is the case for articles: as soon as an item is 
submitted, all of its hooked fields are avaiable for anyone to view 
(even if the article itself is only submitted and not published) at 
module=dynamicdata&func=view&objectid=<whateverid>

The only solution to fix this is to disable the dynamicdata view 
function either by a template override or by messing with the view 
function itself. Now altough this can be done, I think it is not 
advisable to force users to start their installation by hacking the 
system to get rid of a pretty serious security problem.

Two solutions might occur.

1. Get rid of the user view and display functions in dynamicdata 
alltogether. Most people will use <xar:view> template tag (not using the 
view function) or write their own functions that will take care of the 
displaying. The functions as they exist might remain with the module, so 
that people who do need them can use them if they want, after reading 
the security risks.

2. Alternatively, dyndata privileges can be rethought so that the view 
and display functions include a new level of privilege-checks and hide 
items that are stored and submittable but not meant to be shown.

In any case: people running sites using dyndata should follow solution 1 
manually unless they want all their data published indirectly through 
dyndata without knowing about it.


Tamas
_______________________________________________
Xaraya_devel mailing list
Xaraya_devel (at) xaraya.com
http://xaraya.com/mailman/listinfo/xaraya_devel